I took part in Ludum Dare for the fourth time. Although I am not happy with the resulting game, I am happy with what I learned while making it. After all, the main reason to enter LD is the unique experience you cannot get in any other circumstances.

As usual, I suggest first looking at the result on the Ludum Dare page, and then I will explain how it was made.


(A link to the standalone version for those who appreciate it)
This was probably the hardest time: no time to prepare, an inspiring and exhausting DevGAMM Minsk the day before, half the first day spent traveling, and health issues in the background. This was the first lesson I learned—again. Preparation is half the victory. Consequently, no preparation is half the defeat.
In an ideal world, I should have set aside time to try out lighting ideas, practice low-poly art, figure out texturing, and get somewhere with music. We all know our weaknesses that need work before the competition begins.
Actually, I did prepare a little. Strangely enough, I had not touched platformers since 2009. I decided to return to them and even did a little prototyping. Although Unity defaults to making platformers with an orthographic camera, I wanted to see how one would look with a normal perspective camera. The goal was simple: convey depth in the image.

That is the fate of prototypes: they look terrible, and nothing makes sense.

It turned out that the basics of a platformer are easy to put together. Place colliders, attach a rigidbody to the character, assign buttons to set velocity in the required direction—and you can already play at moving between platforms. There is, of course, much more work and many pitfalls ahead, but the first step is much easier than, say, making a strategy game.
This time I was happy with the competition theme. Two-button controls are exactly what you want when making games for mobile devices. Lots of buttons, no tactile feedback and a small screen are a nightmare for a game based on reactions. That is another reason why player skill is minimized on mobile devices. But say the game has two buttons, the right and left halves of the screen, and the situation immediately improves.
Still, the idea of two-button controls has been with me for a long time. First, Ilya Chubarov and I worked on a small pet project about a car controlled by two buttons. Unfortunately, we abandoned it for more important things. But it showed me that a game can be fun and have sufficiently deep gameplay with controls reduced to two buttons.
Then, at DevGAMM in Minsk in 2014, someone showed me a platformer prototype on a device where the character moved using two buttons. It looked promising. The platformer's complexity remained while the controls became simpler.
Finally, the simple Pako — Car Chase Simulator showed that two buttons are quite enough to make a skill-based game.

Combining a platformer with two-button controls excited me. How many good platformers do you know on tablets? It is an interesting challenge.
Moving left and right using two buttons is obvious. But how do you handle vertical movement and interaction with objects? I really disliked the idea that pressing both buttons together would produce a result unrelated to pressing each separately. A button for moving left should not suddenly become a button for jumping, shooting or interacting with objects. I will not justify that here; I simply believe it is wrong.
So I solved it differently. Gravity handles downward movement. Special objects lift the player when they are within range. Interacting with objects simply requires standing still. If the player wants to activate a terminal, they walk up and stop; if not, they walk past. Naturally, this needs feedback showing that interaction has begun and how much longer they must wait for a result. I solved that with a simple progress bar appearing beside the character.
The next lesson was understanding when to switch from prototyping to production. Building a small scene to test gameplay elements was a good idea. Building the entire level from default boxes was a bad one. Simple boxes sped up level assembly a little, but made them impossible to replace easily with a proper model. At some point, I should have deleted all the cubes and started editing the level as a mesh in Blender. At least that would have avoided seams and allowed proper materials. It would also have given me more freedom to play with geometry and make every corner unique. Unfortunately, that idea came too late.


For real programmers, object-oriented programming is routine, but I am gradually getting into it. In my first LD I had just 2–3 scripts controlling the whole scene. This time there were 11: one per game entity. It makes level assembly much easier when adding or removing an element does not immediately require propping things up in three scripts.
Oh, I almost forgot: this Ludum Dare had a double theme. Two options received the same number of votes. One was “Two buttons control”; the other was “Growing.”
Surprisingly, all the themes have negative scores. We chose the lesser evil.

Since I wanted to make a platformer, growing a plant—the first association that came to mind—did not fit. Of course, the rules allowed picking just one theme, but that would be too simple and uninteresting.
Eventually, I came up with a game where an astronaut runs around a ship activating compartments, thereby “growing” the level. I stuck with it for a while, until the bare mechanics had to become a narrative: create the astronaut, give them a story, show the spaceship, convey an atmosphere. Then I realized I could not manage it. I cannot draw astronauts, I had no story ready to tell, and the level was too abstract.
That was when I decided: forget it, I will make something simpler. The entire level is a Christmas tree the player has supposedly grown. That also explains the lighting: festive lights, New Year, and all that.


Of course, I did not account for WebGL lighting being much simpler than what I saw in the editor. Still, I must admit that WebGL builds in recent Unity versions are vastly better than they were when I built my Ludum Dare #32 game. The build is now many times smaller and runs much more reliably. If you gave up on this technology at some point, now is a good time to give it another chance.
At the previous LD, I badly misjudged the title by using a single word taken from the competition theme. This time, to be safe, I chose a unique name. But I can honestly say it did not help. If the game does not look delicious, nobody will mention it anywhere: no let's plays, no links. That will teach me not to postpone the visuals.
I should not have postponed playtesting either. I became so absorbed in development that I only started testing after submitting the game. Not the smartest decision for puzzles, where players can easily think, “I do not know what to do; closing the game is easier than figuring it out.” Fortunately, many players managed. But I know that simplifying a few things could have made the game friendlier.

To sum up:
1. Prepare in the areas where you are weak.
2. Rest beforehand so that you are in good shape.
3. Do not spend too long working with placeholders, or replacing them with proper art will become a problem.
4. Do not postpone the story either. If its key elements are not built into the level's foundations, the plot will not stick later.
5. Even one short playtest can show you how to improve a game significantly.
P.S. And do not forget that a game can be judged in the Humor category.