While I mentioned something to the effect of maps and arrays earlier, I looked even more into it and realized that I didn't know how to do what you did unless you like read in stuff from a file or had some exotic type of data structure (the registered version has data structures, but made it seem like you couldn't do a list of lists or anything). Anyway, I also figured out that the simple backgrounds I mentioned as a drawback to tile use can use more than the tile_get_background function to figure out what the tile is from, but also you can use tile_get_left and tile_get_top to figure out where on the tilesheet your tile is from.
If I am thinking about that right, all the simple objects I had for things like ice, holes, level transitions, and some of the stuff Niek had like water and shore, things like grass and swamp - I can probably reduce the number of instances by a !@#$% ton. I rewrote that tile checking code into an improved function that I think I can use to further reduce the complexity of my later collision_line checks for parObstacle objects (since simple walls are just tiles, there are less possibilities the collision_line checks will have to do, and with instance deactivation as well, there really isn't going to be all that much to do). Well it mostly hinges on tile_layer_find and reducing its complexity but I think I will have done that as much as possible, as well as reducing the complexities of other things.
Also sorry about going a little off-topic in terms of what I am coding rather than talking specifically about your project. Although I took your statements about reducing the number of wall objects as a challenge; speaking of though, I can see your method working really well in a dungeon. The sprites and level design are awesome; even switching from Minish Cap to FSA Link was cool because it fit the style better.