Ludum Dare 26 – post mortemLudum Dare 26 – a post-mortem

cubecatcher_ld48_1GAM

cubecatcher_ld48_1GAM Momentan ist dieser Artikel leider nur auf Englisch verfügbar.
cubecatcher_ld48_1GAMLudum Dare, the world’s most prominent game jam, took place from Saturday 27th to Monday 29th of May. While the 48 hour compo runs the first 48 hours and only allows one person (who has to do everything himself) to work on a game, the jam, running the full 72 hours, allows teams to work together on an entry and it’s rules are far more relaxed, allowing foreign content (like music).

My last LD experience in December didn’t quite go as planned, but was still lots of fun. This time I had even less time than the meagre 48 hours given to compo participants. I had played Volleyball all Saturday and was too tired to even switch on my computer in the evening. Sunday morning I slept in, woke at 11 a.m., had breakfast and only then took a peek at the Ludum Dare theme: minimalism.

Finding the game concept

devscreen_0A minimalistic game seemed possible to do, especially with lots of experience gained since the last LD through making games for One Game A Month (#1GAM). so I started brainstorming. Soon the basic visual concept was clear: 2D & cubes. Using physics was intended at first, but later was dismissed, because the game worked fine without, minimalism was the theme and physics are always a hassle to work with.

devscreen_1The first gameplay idea was to have a ‘player cube’ that the player would use to collect other cubes of the same size only. If the player cube collided with a larger cube, that cube would split up into smaller parts. Smaller cubes would simply be destroyed on impact with the player cube. I wanted to make this concept more dynamic, so the thought was to make all cubes grow in size in random intervals. This way, cubes that were the right size would become impossible to pick up and would have to be split up again. At the same time, smaller cubes would grow to the right size. The cubes would move randomly and colliding cubes were supposed to merge into larger cubes.

devscreen_2To add some complexity, I then added colours. Only cubes of a specific colour could be picked up. The correct colour would be indicated by the interface which would change randomly. The interface itself needed to be simple and clear to read but at the same time very flashy so the player would notice its changing colours immediately.

Time for a break. In my case this was a couple of hours during which I did some non-game related work.

Prototyping the game, and changing it

devscreen_5I built a prototype in Unity3D and found that discerning the correct cube size was very difficult. That’s why I tabled the cube splitting concept and used the different cube sizes to indicate differently score values.Picking up a cube of any size would now not split it but randomly spawn 0-5 new cubes of random size. This also removed the last physics elements the game had. Any cube pickup of the right colour would score points, the wrong colour would subtract them. Since picking up small cubes is more difficult they got the highest value. Logical, but a bit counter-intuitive, since bigger is usually considered better.

Giving the player a purpose

The game’s goal was still unclear at this point, I simply had a random cube distribution, a cube pickup, and a scoring system. But what was the goal? Why would the player keep playing? He wouldn’t. At some point the screen would simply be full of coloured cubes making it impossible to discern right from wrong and the player would have to give up.

cubecatcher_interfaceTo remedy this situation, I introduced a target score and a countdown timer. Countdowns give the player a sense of urgency,  a drive to reach the target score in time. To make the game more interesting to continue, I added a level system that increases difficulty with each time the player wins a level and continues. Difficulty is governed by time, target score and the frequency of colour changes..

Adding the potatopotato

I love Easter eggs and hidden features in games and my game wasn’t very funny so far. That’s why I joined the Official Potato Challenge by the fabulous McFunkypants (creator of #1GAM) and added a random potato feature. The potato is a super scoring (50 points) item that flies through the screen. Its worth was later reduced to 25 points because it was too overpowered.

Adding soundnanostudio_making_game_sounds

A soundless game is half as fun as a game with great music. Sword & Sworcery would have been pretty boring without it’s fabulous music, no matter how great the graphic style is.

Sadly at this point I didn’t have much time left, so I had to content with making simple pickup sounds for the cubes. A ‘ding’ for a correct pickup and a ‘dong’ for an incorrect one as well as a special potato pickup sound and level win and loss sounds (those last two, by the way, didn’t work properly in the compo entry version). I used the free Software NanoStudio for this.

Adding a start & end screen

cubecatcher_endscreenFinally, I added a startup and an end screen. The start screen got an intro text with explanations of the game & controls, the end screen features the statistics (points scored, cubes picked up, time played etc.) as well as instructions on how to continue and quit. There are two different texts, depending on whether you won or lost a level.

cubecatcher_screen1

Post-compo: Fixing bugs & making improvements

The rating & comment system of Ludum Dare is a great thing, because you quickly get feedback from other game developers. They brought attention to some minor bugs and many said that they found the immediate colour switch annoying or irritating. They wanted a short warning before the change so I added a feature that makes the GUI flash briefly before a change. Initially I didn’t want any warning because I found it funny how you steered towards a blue cube and right when you reached it the colour changed to green, but getting input from other people changed my mind.

devscreen_6The other major improvement was mainly intended for the mobile version (see next paragraph), but also helps on the desktop / web versions. Originally, the player could leave the fixed camera field of view and move outside of it. With keyboard control, this isn’t a problem, because the controls are quite accurate and the player never gets to be very fast. On mobile devices, using the tilt acceleration of the device for controlling the player cube, it would shoot out of the screen too easily. So I added a boundary (created dynamically for different screen sizes) that resets the player on the other side of the screen.

Porting the game to mobile

unity2mobileHaving finished the game, I realized that it would perfectly fit mobile devices, and also be fairly easy to port. Only the player controls would have to be changed from keys to a tilt-acceleration control.The main problem was that I only have a Unity 3.5 mobile license and had made the game in Unity 4. You can’t just open a Unity 4 project in 3.5 – the engine has changed too much for that to work. But some things can be simply copied & pasted: assets like sound, textures and models as well as the scripts. Scenes can be imported but not opened, GUISkins, materials and prefabs crash the editor immediately.

Since my game mainly consists of scripts and only 2 prefabs, 2 GUI Skins and 3 materials, remaking these and the 3 scenes wasn’t too hard. That’s the advantage of programming as much as possible and using very few non-dynamic game objects.

I then added the Input.acceleration commands and built the game to test on my nexus 10.
Here’s a first look:

The game ran smoothly, but I noticed the above mentioned problem of the player cube falling outside the camera field of view. The second problem was the text size since mobile doesn’t allow dynamic font resizing that I had used in the web/desktop versions. Thirdly, allowing the device orientation to turn the game automatically is really annoying when playing a tilt-controlled game. I fixed that by allowing auto-rotation only in the start and end screen and fixing rotation as soon as the player enters the game.

The game that could have been

In retrospect the first concept with the splitting cubes could have been reworked in a different direction that would have played out fine. The problem of the user discerning different cube sizes quickly could have been removed by making different shapes. A cube would split into triangles, the triangles could split into circles and additionally, each type could have been colour coded, too (which would remove the colour-matching element, of course). I think I’m going to make that game sometime soon. ;)

Another way of making cube sizes more clear would have been to add a dimension. 3D cube size might be easier to discern than 2D cubes.

Where to go from here

What is the future of this game? What can it become and what could it become? Here are some ideas: online (global) highscore & music. An endless level system, implemented via a function that simply takes the difficulty up a notch each time a level is won and the player continues (currently that’s a fixed function for 5 difficulty levels).

Final words

The jam was great fun! Thanks to all who organized it and participated & special thanks to everyone who rates my game ;)

Play it now

Here’s the LD game page: http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=18208

The game can be played in both compo (v1.0) and post-compo versions here: http://david-arndt.de/cubecatcher/ (the game source can also be downloaded there).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>