So I’ve been meddling around with the first level for Vanguard using the standard Room Editor in Game Maker. In many cases, GM’s facilities for level editing are adequate. Those who venture off the beaten path once laid out by Mark Overmars’ standard platform tutorial will start getting annoyed by GM’s level editing quirks and limitations. Today I’ll discuss three of the larger issues I’ve come across that bug me in this respect. I work with GM 6.1, but as far as I can tell, these issues have not yet been dealt with in GM7.

One vision

First of all, the fact that you cannot zoom in or out in the Room Editor, both in the room as in the tile view. In Vanguard, my normal block size is 64x64. Basically I’m using a factor 2 blown up sprite-set and tile-set to circumvent the resize-blur effect when setting the game at full screen. The latter may be due to my video card, but I know many people have this issue (I’ve heard it’s Geforce related). Even with my 22â€? widescreen I can only see a small portion of both the room and the tileset. If I could zoom out just by a factor 2 (preferably more) this would greatly speed up the creation process.

Sometimes you want to use very low grid settings (i.e. lower than 8) for precision placement. At this point the screen content becomes almost invisible due to the high amount of gridlines. If one could simply zoom in a bit, one could actually see what one is doing.

Tile dementia

Another peeve of mine is the way tiles are loaded in the game. Often, I make a tileset and add elements (trees, machinery, decorations etc.) to it later on during the level creation process (i.e. I could really use a tile for X on that spot) or I noticed I forgot to add a certain base tile of the terrain. I edit the tile file and then the fun starts…

When you want to reload an image file in an existing tiled background you are punished. GM namely forgets it was a tile background plus all the settings you used for it. So you have to load, reselect ‘Use as tile set’, reselect ‘Transparency’ (in most cases) and (unless you use 16x16 tiles at 0,0 off-set) fill in all the dimensional values for the tiles. Why would anyone want to lose all their settings when they reload in an existing resource?

Creative disorder

The third point I’d like to discuss takes us back to the Room Editor. One of the more potent tools that are available in the editor, is the ability to add individual object creation code. This is really great, but the design choice made when this bit of code will be executed within the Creation hierarchy of the object is troublesome. This unique code is executed before all other creation code of the object.

The way I see it, how sooner code is executed, how more generic it is and how less specific. For instance, if you make an enemy you will often make a parent object with a lot of basic settings set, so you won’t need to do this for each child object. Therefore, you will execute the inherited parent code first followed by any additional code.

Say all enemies of a certain type start out walking randomly, either left or right. Now, there is this one enemy you want to start walking out left for some reason. Then it would be useful if the additional bit of unique code you enter in the Room Editor would end up executed at the very last, as it will otherwise be overwritten by the other code (making it random again).

In the least case, it should have been possible to choose when to execute this code, just like you are used to in the object editor. This could have been achieved by adding a ‘room code’ action in the object editor, which can be placed only once per object and only in the create event. This would be read to determine when room code must be executed. If absent, room code can still be executed first.

The way to circumvent the problem as it is, is by using a lot of variable_local_exists() in the parent or child objects, but it works very counter-intuitive.