At the end of last year, I wrote about taking part in Ludum Dare, the biggest game jam. If you missed that post, now is a good time to follow the link and read it. This time I want to tell you about my second time entering the jam.
It was my second jam, but everyone else's number 32, held on April 17–20. Participants voted for the theme An Unconventional Weapon. To be honest, I did not like it. I believe games should move away from solving problems through violence, if only for variety. But it was what it was.
Before reading further, I recommend looking at the game on the Ludum Dare website so you better understand what I am talking about. The site also has instructions for running Unity WebPlayer games if you have the latest version of Chrome.


PLAY

The main difference for me this Ludum Dare was timing. First, I was—and still am—in California. The competition therefore began at 6 p.m. on Friday and ended at 6 p.m. on Sunday: only one full day and parts of two others. In Moscow time, by contrast, you can code flat out all weekend. Second, work kept me busy until late Friday evening and ate up several hours on Saturday.
So my first decision was to minimize content. Building a large world full of unique content was not an option. If the game depended on content, I would face an enormous risk of finishing the jam with a half-made game. I even considered a game whose entire content fitted on one screen, like EYEZMAZE games. But I could not picture anything compelling, so I abandoned that idea.
Another challenge was choosing a visual style that would stand out. I am neither an artist nor a modeler with a range of techniques. I can either manipulate photographs in Photoshop or make low-poly art, at which I had barely improved since the previous Ludum Dare. The film “Sin City: A Dame to Kill For” came to the rescue. A black-and-white palette with rare splashes of color sounded manageable and relatively distinctive.
The game theme remained the main challenge. I had no ideas ready for games involving weapons. Remember, I was considering the jam theme late at night after a difficult workday. My head was bursting and good ideas would not come. After struggling, I decided to put the theme aside, make the game I simply wanted to play, and figure out the jam theme along the way.
Fortunately, the vision for such a game had been brewing for a long time. Sometimes I want a simple game with minimal controls, where my spinal cord makes all the decisions and my brain gets a rest. Something where you go wheee, speeding around obstacles—but in a casual way. That last part is the problem with other games in this genre.
So I spent the first evening creating the basic mechanic. A cube standing in for a plane flies over terrain in a fixed direction, and the player moves it along the other two axes with the arrow keys.


I began the second day by completely rewriting movement. First, I separated the camera and plane into different objects. Previously, the plane had been a child of the camera: the camera flew forward while the plane moved relative to it. It was a viable idea with one serious drawback. When the plane approached the edge of the screen, the camera itself began moving at the same speed instead. The plane kept moving sideways unchanged, but visually it seemed to slow down, since the plane moves faster across the screen than the camera moves through the level.
I decided not to be clever: let the plane fly freely within the level and have the camera follow its coordinates without being its child, so it would not inherit tilting. Playing would be unpleasant if the camera shook around like the plane.
The second reason to change movement was the need to add Unity's built-in physics. Colliding with obstacles is a central gameplay element, so it should be handled better than simply deducting HP and passing through the model. Adding physics required switching from directly controlling the plane's position to controlling its rigid body's velocity. Applying forces might have been more correct, but I could not get the controls right when I tried. And the first rule of Ludum Dare, and development under time pressure generally, is: if it does not work and you do not know how to fix it, do not do it.
Once the basic mechanic was ready, I faced the content question. As I wrote earlier, time was short, and building the level by hand seemed risky—especially with gameplay requiring a very long level. So I decided to generate it. First, I made a terrain section and automatically duplicated it to reach the required length. Then I made several obstacle models and repeated them every N meters, randomizing the model, scale, rotation and position relative to the starting point.
Later, I made this system more sophisticated by changing placement rules according to distance from the start. This allowed the surroundings to change as the player progressed: initially more difficulty through increased scale, then new elements. There were also almost empty stretches at the beginning for learning, and at the end to prepare the player for the finale.
I also added a second terrain layer: a large low-poly model duplicated just like the first terrain. It does not affect gameplay, but adds depth to the image.
Only the basic terrain:

Together with the second terrain:

To give gameplay meaning, I added three things: 1) a progress bar showing the remaining distance; 2) points, earned increasingly quickly as you advance; 3) upgrades you can buy with those points between flights.
Developing my previous game, Fill The Bar—or rather, cleaning up my own bugs—taught me to work with progression. First, how to save and load player progress. Second, bonuses should increase values additively rather than multiplicatively, so the numbers do not shoot into space. Third, upgrade prices should, conversely, grow multiplicatively, so the player cannot shoot into space with endless upgrades; progression should slow at some point, but not drastically. If you managed to earn enough for an upgrade once, you can do it twice more for the next one. Real balancing is more complicated, of course, but that is sufficient as a rough explanation.
Since points buy useful upgrades, they are a reward. A reward is good when it goes hand in hand with risk, tempting players to take greater risks for greater rewards. Here, the risk is obvious: the lower you fly, the more dangerous it is. So I added a simple multiplier for points earned at low altitude. Such flights also look better.
That ended the second day of development. I had a game with fully functioning core gameplay: you could reach the end, dodge obstacles, earn points and buy upgrades.
The final morning began with the realization that core gameplay does not work without a long-term goal. You will not play unless you know why you should. If only I had worked out the theme at the start, I could have derived goals, narrative, presentation and everything else from it. But it was too late, no narrative came to mind, and I had to find a way out.
Once again, I used the technique of combining existing puzzle pieces into a design solution. The pieces were:
1) I had to address “An Unconventional Weapon.”
2) I did not want a game about using weapons.
3) There had to be a surprise that left the player astonished.
4) Something had to stand at the end of the route—a goal of sorts.
5) That something had to be mysterious, making players curious to discover what it was.
Each piece became part of the picture:
1) Establish “Weapon” immediately. Call the game “Bomb Bringer.” Show a couple of bombs in the main menu. Hang a bomb under the plane, but do not let it be used anywhere. Only at the end will players discover how the bomb works and what makes it unconventional.
2) Of course, it is not a real bomb and must not destroy anything. Do the opposite: make it bring something to life. A tree, for example.
3) Yes, the player's task is to drop the “bomb” beneath a tree so it comes alive and fills with color. Exactly what a black-and-white world needs.
4) Put the tree at the end of the route.
5) Since the tree begins dead and leafless, its shape can be aggressive and incomprehensible, supporting the original idea that we are flying with a bomb to blow up some unknown thing.
Now a puzzle. The level needs to be about 30 kilometers long. We must see the tree at the start and reach it at the end. A draw distance greater than 1–4 km hurts performance. If the tree is noticeably large at the start, a single polygon will fill several game screens at the end. Drawing it in the background tells players the object is not real and cannot truly be approached. What should I do? Think for a couple of minutes before reading on.
Without the tree:

With the tree:

The trick is attaching the object to the camera at a large but reasonable distance. When the camera moves sideways, every object moves while the tree stays put, and the brain interprets it as very distant. I also grow the tree between two preset scales according to the distance the player has flown, using my favorite function, Mathf.Lerp.
Now I had to decide what happens when the player arrives. For convenience, I split that moment into a separate scene. Connecting everything at the game's scale would have been too difficult. In the new scene, I cheated again with the relative sizes of the tree and plane.
Place the tree and some terrain. Place the plane and animate it flying around the tree. Then place the camera and animate that flying around the tree too. Doing it as one animation would be good, but I do not know how. So I synchronized camera and plane by repeatedly running the game.
The finishing touch: change the colors. You cannot change material color through animation, so I wrote code. Along the way, I discovered that material color changes made during play persist afterward. After testing, all the graphics suddenly became colorful. More supporting code was needed to force materials back to specified shades of gray.
What else was left? Ah yes, make the main menu look fancy from the very beginning. I built a small looping canyon and used the same animation to send the plane flying around it. I attached a camera to the plane, but prevented tilting—or rather, corrected it every frame. A little debugging and it was ready. Hanging the bombs underneath made it look delicious.
The last task was music. I had postponed it until the end because it is really not my thing. I did not like the method I used last time. I wanted something more intuitive: tap with a finger wherever inspiration leads, and done. A finger means a phone screen, so I went looking for what it could offer.
After trying several apps found through “music composition,” I discovered 
Fingertip Maestro
. I liked the demo's results, but had to pay to unlock proper instruments.

Watch the video on the original platform


In practice, it was not that simple. Moving my finger produced something that seemed fine. But then I had to email it, convert it to another format, connect it to the game, and realize it was cacophony rather than music. After several iterations, I managed a compromise with my sense of beauty. Besides, time was running out.
Done. Build, upload, test. It turned out WebGL had a bug: the final scene displayed correctly for half a second, then a blue screen appeared and only disappeared at the very end. Other versions were fine. I searched for the cause without success. That color was not used anywhere in my game. Apparently it was some system screen hinting at an error. Unfortunately, quick debugging was impossible. A WebGL build took about 10–15 minutes, then uploading took another 20–30 because the server was in Russia and I was in the USA. Eventually, I swapped the WebPlayer and WebGL versions. After all, running the WebPlayer version is not so difficult: instructions appear above every game on the Ludum Dare website.
Finally, you can watch the same process in an accelerated video accompanied by the game's music, including unused tracks.

Watch the video on the original platform


To finish, I want to sum up—or rather, point out where I was wrong and what should be improved:
1) Without upgrades, flight speed is too slow to feel exciting. Alternatively, let speed grow without a limit.
2) There are no sounds at all. I could at least have added clicks and impacts.
3) The jam theme needs to be apparent immediately, or many people will not understand and will vote it down.
4) Narrative, story, characters and so on—I wanted to add them, but could not manage it.
5) More varied obstacles. I wanted turret variants that shot at the player, but completely ran out of time.
6) The game ended up with no humor at all, so I had to opt out of that category. Humor is good and helps a game spread.
7) It is a miracle my music does not make people sick. I need a more reliable way of making it.
8) I spent more time on the final scene than I should have on something many people will never see.