Game editor for platformer - post mortem

About 2.5 years ago, we conceived a simple project - a platformer with certain properties: hardcore, as dynamic as possible, without firing. The platform is iOS, since we work only with it - and Android at that time was not yet a serious alternative. Super Meat Boy, which had not yet been released at that time, was chosen as the standard.
Since the platformer is not a game where you can do with the great power of the generator’s randomness, you needed a full-fledged, powerful and convenient level editor.





Thus the story begins


This business was conceived as a simple “project for a month,” since not very much was believed in the success of the genre on mobile platforms. As we did, the topic is a separate large article - but this article is specifically devoted to the “evolution” of the editor, so I will not dwell on other details. The main thing that happened so that we liked the basic prototype so much that it was decided to “add features”. And then it turned out that it took 10 times more to create levels than we thought a priori, and the project quietly turned into the most ambitious unfinished building that ever left our modest team (the two of us - a programmer and an artist) - the game took small two years.

During this time, the game has changed a bit:


Meet the Editor


So, the editor. I came up with a level editor right on the iPad - for two reasons. Firstly, my “engine” does not support other platforms except iOS. That is, to make an editor on a PC, you would either have to port the entire “engine” and the whole game — which you didn’t want, or write an editor separately from the game, without the ability to play right away — which you didn’t want either.

The second reason is that it seemed like a very cool opportunity to create levels anywhere - in the subway, in nature, in a cafe, in the bath ... just lying on the couch after all! And this is true, although it turned out to be difficult with nature - the screen is very glare, and with an anti-glare film it is just very blind. Plus, you can immediately play just as intended on the target device - which is impossible in the case of a PC.


He said - let's go!


I made the first version of the editor pretty quickly - in a few days. The story did not preserve its appearance, but it does not practically differ from the current one - an editor for internal use, and what is the point of making beautiful things that the player will not see?
The final version with an additional menu open looks like this:



Ideology was simple - it all started with object number zero, which was added with a special button. After that, cloning took place until the end — new objects were no longer added. First, the old one was copied, then the sprite index was selected for it, and the object was put in the right place. Despite primitivism, the circuit worked well. It’s funny, but for 2 years we chose the sprite index “by touch” - using the slider, which simply scrolled through all the sprites in a row:



It would seem - terribly inconvenient. But since in most cases the objects were not added again - but those that were already on the screen were copied, it turned out that this was not a problem. In the end, I got tired, and I did a “normal” dialog for choosing a sprite, but this did not add much speed.



What (else) went right


Although post-mortem themes are usually written for the games themselves, and not for the editors, the traditional section seems logical to me. So, finds:

  1. One of the first things encoded was the following thing - the ability to duplicate the current object in any of four directions. On the one hand, this may seem obvious - but the usefulness of this was not immediately recognized - it seemed wasteful to spend space on the screen for as many as four buttons that do the same thing. Moreover, if you click on any of the duplicate buttons, and without letting go of it on the screen, the object begins to move to the supposedly right place with a rhinestone.
    There was even a fifth similar button - it copied the object without saving the parameters, setting default values.
    This “feature” provided a convenient way to arrange repeating objects, in particular tiles.

  2. The second convenient thing was the ability to delete objects with a simple tap in a certain corner of the screen - in our case, in the upper left. Initially, there was a “basket” in which it was necessary to place objects with drag & drop, but it turned out that the objects needed to be deleted permanently - and the dragendrop was no longer fast and convenient for this. It turned out that after a certain time we developed a certain grip on the device - the iPad was held with the left hand so that the thumb fell exactly on the virtual basket, while the right hand controlled the selection of objects for subsequent removal. It became so natural that excess objects were removed in a matter of moments.

  3. Double tap to switch to the selection mode of the object (s); when released, the object was fixed and the editor switched to the movement mode, which was terminated either by repeated double tap or by switching to the mode of moving around the map. This allowed, firstly, to see the object that we are moving without covering it with a finger, and secondly, to reduce the likelihood of accidental movement.

Perhaps the brilliant insights on this end, and the extensive list of what was called “learned in a hard way” begins. There is no forest visible behind the trees, the project didn’t want to end, and we got into that same eternal cycle, familiar from the article on Starcraft - the game was “a month before the release” all the time. And since there was a “month” left until the release, I did not want to spend time improving the editor, which cost dozens, hundreds of wasted hours.

What went wrong, very very wrong.



  1. Undo. There is still no Undo in the editor. Almost not - one move operation is returned - and that’s it. It seemed not so important, but it seemed to take a long time to implement - to create a common pool for each operation, dynamically allocate megabytes of memory to save large-scale changes ... And initially, the absence of Undo was compensated by the lack of number 2, which is described below. As a result, many hours (in the long run) were spent on restoring objects accidentally hooked with a large, clumsy finger. Or to delete a dozen objects randomly duplicated “past”. This problem did not attract attention to itself, since it did not arise very often, but looking back, I regret to admit that the absence of this operation spent many times more than it would take to implement it.

  2. Mass highlight. Yes, objects could not be allocated more than one at a time. It did not seem important, it seemed difficult to implement - the same problem as in the first case. In fact, this led to the fact that there was no copy / paste in the game until the final stage, which means that each of the order of 50,000 objects in the game was set manually, at its own unique point, except when they were copied to a nearby cell using those same duplication teams. The profit here is the greater uniqueness of the levels - since it was impossible to copy whole pieces of the level, everything was created anew each time. But as a drawback - a clear waste of time, and at times.

  3. Animation of objects. All parameters were set using the sliders, although there were still some “helpers”. As a result, if it was necessary for the animation to fire according to the trigger from a certain distance - and end exactly where needed, and not a pixel further, it took 20-30 iterations to manually adjust the parameters. As a result, most of the levels cannot boast of cunning or interesting animation, and the levels are mostly static.
    The logical and simple solution now seems to be simply moving the object in the editor, with automatic calculation of the desired speed, but at that time such a simple thought did not occur.

  4. Accuracy. Perhaps the biggest scourge was the following problem - insufficient accuracy of moving objects - it was impossible to move the object to the desired point - because of the touchscreen and fingers as an input device. To “solve” this problem, two things were implemented - the grid (snap to grid), and the inability to move the object to an odd pixel (that is, in fact, a grid with cell size = 2).
    This partially solved the problem, but unfortunately some of the objects were of the “wrong” size and did not fit into the grid, in addition, sometimes you could forget to turn on the grid in advance, and a whole bunch of objects turned out to be past this very grid - and as a result, you either had to fix the position of the objects to the grid with “pens”, or “hammer” on the grid and play the fun game “hit the pixel with your finger in both coordinates from just the 15th time”.
    The correct decision, which took more than a year, turned out to be a simple fix of five lines - which, by pressing a certain button, reduced the speed of moving objects several times.

  5. Hotkeys. It
    turned out that the most common operations are: - rotation of the object
    - change of orientation (flip) along the x and y axes
    - disabling collisions
    - change of zIndex (drawing order, which was set manually)

    For them, one to three tapas were required. It was necessary to select an object, and then call up the parameter editing panel, which was often closed, since it closed a decent part of the screen, and accordingly directly switch the object. It took a lot of time, but it was not possible to place these operations as separate buttons - they did not fit on the screen, the place ran out on all sides, and I did not want to do the second row - this would reduce the scope. To solve this problem, it was decided to “fasten” the external keyboard. An adapter for a USB keyboard was purchased (in the best Shtirlits tradition called Camera Connection Kit), and spent several aimless nights trying to get it to work. It turned out with the help of a “hack” - an invisible text form with a size of 1 pixel. And then it turned out that working simultaneously with the iPad and external keyboard is inconvenient. A third hand is needed - one holds the device, the other manipulates objects, the third presses the buttons.
    “Feature” remained unclaimed.

  6. The interface as a whole. It did not seem important or necessary, but the interface, not much interfering with the whole, greatly lost in potential and extensibility. At the moment, starting a new editor from scratch, the first thing I would take care of the following things:

    • Convenient drop-down menus for selecting a release command.
    • Panels crawling out of the screen on a “swipe”, similar to how the “Notifications” panel on iOS is called up.
    • Scrolling through a set of buttons - so that you can select the operations you need right now, and thus accommodate more “quick access” commands.
    • Multitouch for frequent commands like flip, rotate, scale, zoom. An attempt was made by me at the very beginning of the work, but I did not give enough time to it - unsatisfactory results were obtained and the work was postponed until better times that never arrived - but in vain.


In the end.


In the end, we released the game, and it all ended well. Well, almost - sales haven’t really worked out yet, but we are working on it. While we can only modestly boast an incredibly high average rating on Google Play - 4.9 units, that is, the fact that people do not like the game, but like it very, very, very much.
The idea of ​​creating an editor inside the game and exclusively for the ipad is debatable, but it was not the worst.


Also popular now: