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 only work with it - and Android at that time was not yet a serious alternative. For the standard was chosen not yet released at that time Super Meat Boy.
Since the platformer is not a game where you can get by with the great power of the generator rand, a full-fledged, powerful and convenient level editor was needed.
')
This matter was conceived as a simple “project for a month,” since the success of the genre on mobile platforms was not very likely to be believed. As we did, the topic of 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 turned out so that we liked the basic prototype so much that it was decided to “add features”. And then it turned out that the creation of levels takes 10 times longer than it seemed to us a priori, and the project imperceptibly resulted in the most ambitious long-term construction that ever left our modest team (we are two - a programmer and an artist) - the game took small two years.
During this time the game has changed a little bit:
So, editor. I came up with a level editor right on the iPad - for two reasons. First of all, my “engine” does not support other platforms except iOS. That is, to make an editor on a PC, one would have to either port the entire “engine” and the whole game - which one did not want, or write the editor separately from the game, without the ability to play at once - which one did not want either.
The second reason is that it seemed like a great opportunity to create levels anywhere - in the subway, in nature, in a cafe, in a bath ... but just lying on the sofa after all! And this is true, although it turned out to be difficult with nature - the screen glares strongly, and with an anti-glare film it just goes blind. Plus, you can immediately play exactly as intended on the target device - which is impossible in the case of a PC.
I did the first version of the editor pretty quickly - in a few days. The history did not preserve its appearance, but it practically does not differ from the current one - the editor is for internal use, and what is the point of making beauty that the player will not see?
The final version with the additional menu open looks like this:
The ideology was simple - it all started with the object number zero, which was added by a special button. After that, cloning to a victorious end took place - new objects were no longer added. At first the old one was copied, then the sprite index was selected for it, and the object was put in the right place. Despite the primitivism, the scheme worked well. It's funny, but for 2 years we chose the index of the sprite “to the touch” - with the help of a slider, in which all the sprites in a row were just scrolling:
It would seem - terribly uncomfortable. But since in most cases the objects were not added again - and those that were already on the screen were copied, it turned out that this was not a problem. In the end, I was bored, and I made a “normal” dialogue for choosing a sprite, but it didn’t add much speed.
Although postmortems are usually written for the games themselves, and not for editors, the traditional rubric seems logical to me. So, finds:
Perhaps this ends with brilliant insights, and an extensive list of what was called “learned in a hard way” began. There are no forests behind the trees, the project did not want to end, and we got into that same eternal cycle, familiar from the Starcraft article - the game was all the time “a month before the release”. And since the “month” remained before the release, I didn’t want to waste time on improving the editor, which cost dozens and hundreds of wasted hours.
What went wrong, very very wrong.
In the end.
In the end, we released the game, and it all ended well. Well, almost - with sales has not quite turned out, but we are working on it. So far 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 they like it 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.
Since the platformer is not a game where you can get by with the great power of the generator rand, a full-fledged, powerful and convenient level editor was needed.
')
Thus the story begins
This matter was conceived as a simple “project for a month,” since the success of the genre on mobile platforms was not very likely to be believed. As we did, the topic of 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 turned out so that we liked the basic prototype so much that it was decided to “add features”. And then it turned out that the creation of levels takes 10 times longer than it seemed to us a priori, and the project imperceptibly resulted in the most ambitious long-term construction that ever left our modest team (we are two - a programmer and an artist) - the game took small two years.
During this time the game has changed a little bit:
Meet the Editor
So, editor. I came up with a level editor right on the iPad - for two reasons. First of all, my “engine” does not support other platforms except iOS. That is, to make an editor on a PC, one would have to either port the entire “engine” and the whole game - which one did not want, or write the editor separately from the game, without the ability to play at once - which one did not want either.
The second reason is that it seemed like a great opportunity to create levels anywhere - in the subway, in nature, in a cafe, in a bath ... but just lying on the sofa after all! And this is true, although it turned out to be difficult with nature - the screen glares strongly, and with an anti-glare film it just goes blind. Plus, you can immediately play exactly as intended on the target device - which is impossible in the case of a PC.
He said - let's go!
I did the first version of the editor pretty quickly - in a few days. The history did not preserve its appearance, but it practically does not differ from the current one - the editor is for internal use, and what is the point of making beauty that the player will not see?
The final version with the additional menu open looks like this:
The ideology was simple - it all started with the object number zero, which was added by a special button. After that, cloning to a victorious end took place - new objects were no longer added. At first the old one was copied, then the sprite index was selected for it, and the object was put in the right place. Despite the primitivism, the scheme worked well. It's funny, but for 2 years we chose the index of the sprite “to the touch” - with the help of a slider, in which all the sprites in a row were just scrolling:
It would seem - terribly uncomfortable. But since in most cases the objects were not added again - and those that were already on the screen were copied, it turned out that this was not a problem. In the end, I was bored, and I made a “normal” dialogue for choosing a sprite, but it didn’t add much speed.
What (else) went right
Although postmortems are usually written for the games themselves, and not for editors, the traditional rubric seems logical to me. So, finds:
- One of the first things encoded was the following thing - the ability to duplicate the current object to any of the four sides. On the one hand, this may seem obvious - but the usefulness of this was not immediately realized - it seemed wasteful to waste screen space on as many as four buttons that do the same thing. Moreover, if you click on any of the duplicate buttons, and without releasing to drive it across the screen, the object immediately began moving to the intended location.
There was even a fifth similar button - it copied the object without saving the parameters, setting default values.
This "feature" gave a convenient way to arrange repeating objects, in particular, tiles. - The second handy thing was the ability to delete objects using 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 put objects by drag & drop, but it turned out that objects must be permanently deleted - and dragandrop is not enough for this to be quick and convenient. It turned out that after a certain time we had developed a certain grip of the device - the iPad kept its left hand in such a way that the thumb was right on the virtual basket, while the right hand controlled the selection of objects for subsequent deletion. It became so natural that the extra objects were removed in a matter of moments.
- Double tap to go to the selection mode of the object (s), after releasing the object was fixed and the editor switched to the move mode, which was stopped either by repeated double tap or switching to the move mode on the map. This made it possible, firstly, to see the object that we move, without covering it with a finger, and secondly, to reduce the likelihood of accidental movement.
Perhaps this ends with brilliant insights, and an extensive list of what was called “learned in a hard way” began. There are no forests behind the trees, the project did not want to end, and we got into that same eternal cycle, familiar from the Starcraft article - the game was all the time “a month before the release”. And since the “month” remained before the release, I didn’t want to waste time on improving the editor, which cost dozens and hundreds of wasted hours.
What went wrong, very very wrong.
- Undo. In the editor, and still no Undo. Almost not - one move operation returns - that's all. It seemed not so important, but it seemed that it would take a long time to implement a common pool for each operation, dynamically allocate megabytes of memory to preserve large-scale changes ... And initially, the absence of Undo was compensated by deficiency number 2, which is described below. As a result, many hours (in general) were spent on the restoration of objects accidentally hooked by a big, clumsy finger. Or to delete a dozen objects accidentally duplicated “by”. This problem did not attract attention to itself, since it didn’t happen quite often, but when I looked back, I regret to admit that the absence of this operation would have spent many times more time than its implementation would take.
- Mass selection. Yes, it was impossible to select objects 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 in the game before the final stage there was no copy / paste, which means that each of the order of 50,000 objects in the game was put by hand, to its unique point - except when they were copied to a nearby cell using those same commands duplication. Profit here is the greater uniqueness of the levels - since it was impossible to copy the whole pieces of the level, everything was created anew each time. But as a drawback - a clear waste of time, and at times.
- Animation of objects. All parameters were set with the help of sliders, although some “helpers” still were. As a result, if it was necessary for the trigger to trigger an animation from a certain distance - and ended exactly where needed, and not a pixel further, it would take 20-30 iterations to manually adjust the parameters. As a result, most of the levels cannot boast sly or interesting animations, and the levels are mostly static.
A logical and simple solution now seems to be a simple movement of an object in the editor, with automatic calculation of the desired speed, but at that time such a simple thought had not occurred. - Accuracy. Perhaps the biggest scourge was the next problem — the 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 — a snap (so-called) grid, and the impossibility of moving an object to an odd pixel (that is, in fact, a grid with a cell size = 2).
This partially solved the problem, but unfortunately some objects were of the “wrong” size, and did not join the grid, moreover, sometimes you could forget to turn on the grid in advance, and a whole bunch of objects turned out to be past that grid itself - and as a result you had to either fix the position of objects to the grid with “handles”, or “score” on the grid and play a fun game “hit the pixel with your finger in both coordinates from only 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. - Hotkeys. It turned out that the most frequent operations are:
- turn the object
- change of orientation (flip) along the x and y axes
- disabling collisions
- change zIndex (drawing order, which was set manually)
For them, it took from one to three tapas. It was necessary to select an object, and then call the parameter editing panel, which was often closed, as it covered a decent part of the screen, and accordingly switch the object directly. It took a lot of time to do this, but it didn’t work to place these operations as separate buttons - they didn’t fit on the screen, the place ran out from all sides, and I didn’t want to do the second row - this would reduce the scope. To solve this problem, it was decided to “screw” the external keyboard. An adapter for the USB keyboard was bought (in the best traditions of Stierlitz called the Camera Connection Kit), and several wasted nights were spent trying to make it work. It turned out with the help of “hack” - an invisible text form of 1 pixel. And it turned out that working at the same time with the iPad and external keyboard is inconvenient. You need a third hand - one holds the device, the other manipulates objects, the third presses the buttons.
"Feature" remained unclaimed. - The interface as a whole. It did not seem important or necessary, but the interface, not much disturbing as a whole, was losing much potential and extensibility. At the moment I, starting a new editor from scratch, first of all would take care of the following things:
- Convenient drop-down menus to select release commands.
- Panels coming out from behind the screen on “svaypu”, just like the panel called “Notifications” on iOS.
- Cyclic scrolling of a set of buttons - so that you can select the operations you need specifically now, and thus accommodate more “quick access“ commands.
- Multitouch for frequent commands such as flip, rotate, scale, zoom. I tried to do it at the very beginning of my work, but I didn’t spend enough time on it - unsatisfactory results were obtained and the work was postponed until better times, which never came - but in vain.
In the end.
In the end, we released the game, and it all ended well. Well, almost - with sales has not quite turned out, but we are working on it. So far 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 they like it 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.
Source: https://habr.com/ru/post/178487/
All Articles