I had a couple of different ideas initially:

– a 10 seconds to defuse the bomb game, (which was actually made by other jammers in several different versions)

– a memory game with 10 seconds to look at the solution (a bit boring)

– a light-cycle race in which you need to turn once every 10 seconds or loose

– a bomberman-like two-player game in which the walls grow every 10 seconds (I remembered that bomberman had that kind of death-mode in the end of timed levels)

– a shooter in which the enemy can only be seen briefly every 10 seconds or if he fires a weapon (would have required character animation)

– and the last idea, a dark labyrinth that the player has to navigate with only 10 seconds of light available.

Game Mechanics

In order to skip on character animation I decided to use the classic ball through a labyrinth approach. A normal labyrinth with walls could, however, be navigated by trial and error. To make sure the player actually needed to use light I removed the walls and put the labyrinth above a deep chasm (infinity). It needed to be clear from the beginning that if the player fell off he would die/be reset.

This basic concept was enough but lacked in actually interesting gameplay elements so I added power-ups that could be collected within the labyrinth: a shooting ability to remove obstacles in the path (2 bullets), a jump power and a speedup.

The light power had to be switched on and off like a flash light. In the beginning I added a delay between switching the light off and on again but that made it very difficult when a speedup was active so I reverted to the instant on/off version.

I created short levels, because naturally the player had to be able to finish them with using only 10 seconds of light. That did not mean the level itself had to be finished in 10 seconds, on the contrary, higher levels needed to force the player to switch off his light to conserve energy.

Look & feel:

The first prototype was running soon after. The first controller was physics (rigidbody) based because I thought interaction with the environment might become a feature later. That controller version proved very hard to steer, not impossible, but I fell off the labyrinth path so often that I decided to try a second controller based on the standard Unity FPS character controller. That one was much easier to control and was the controller I used for easy and normal mode later on. The rigidbody controller remained in the game for the hard (frustrating) game mode.

For the look I went with a very minimalistic, clean and prototype-like look. Strong contrasts between the black surroundings, the light grey platforms and the red player ball allow the user to quickly identify his situation with only using his light for a short time.

Interface

I chose a nice-looking free font from Google fonts and made some graphic icons that would signify light power, shooting power (bullets), jumping power, speedup time and level playtime. I didn’t want text or large interface elements distracting the player. The menu interfaces are simple boxes with text.

Music

Being a visually simple game, I knew I also needed sound and & or music. I opted for the latter and made some very weird tracks in NanoStudio. I would characterize the music as eerie, horror and speed. At least that’s what I was going for. I’m not a composer.

The Jam

I approach every game jam more relaxed than the last one. Knowing that I can definitely deliver a game of some sort within a day makes it easier to concentrate on special new features like the interface elements and the music this time. I actually developed the game in about 16 hours on two days while watching series, reading and playing games in between. No all-night programming sessions this time. The entry period was a bit close again, due to my infinitely slow internet connection that took over an hour to upload all the different platform versions (Web, PC, Mac, Linux). Overall, the jam was great fun once again, I learned a few things about Unity and a lot about making music.

Finding the game concept

A 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. The 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. To 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

I 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. To 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 potato

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 sound

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

Finally, 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.

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. The 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

Having 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).

Christmas jump features a sentient present that wants to get to the other present waiting on top of the mountain to join in in joyful celebration.

It has the classic features of collecting gold coins and stars that both count towards the player’s score as well as hearts (lives) and save points. Additionally, there are physical features like platforms breaking when the player falls onto them from a certain height.

The game is fully playable, but I am still implementing minor improvements for the interface and user controls.

Illuminum was the first large game project I started. Initially, I wanted to make a story-centric Adventure but I soon had to realize that my skills were inadequate for that huge a task. I scaled the game down in order to quickly get user feedback from testers and implemented a dynamic cube distribution. The main goal was now to collect coloured cubes in a dark environment. To motivate players, I created an online highscore and a website. This step was a first visible success. People started playing and tried to best each other. Observing them gave me an excellent opportunity to find bugs and design problems.

At the university’s end of semester exhibition I realized how high the bar still was for non-gamers to start playing when they had to sit down and use mouse & keyboard. As a consequence I implemented support for the Xbox Controller, thus removing a critical technological barrier for some players. That brought a non-trivial amount of problems, like controlling the menu, which was previously accessed via mouse.

Illuminum is currently in arrested development. I hope it will be released on good behaviour someday soon so I can finally finish this potentially great game.

Want to know more? Visit the Illuminum website.

This project was started by three of my fellow students in March 2012 but for various reasons never came to lift off properly. I joined the team in October 2012, when one team member had to leave for his practical semester.

One of the first things I did was writing down brief character descriptions upon which we then based our visual character design. Here’s two of them:

Doctor Invisible
Doctor Invisible was one of the leading neuro-psychologists. One day, during a session with an extremely irritating patient he found out how he could become invisible by concentrating really hard. He usually uses this ability to avoid his wife at home.
Age: 72
Special Abilities: Can become invisible for short periods of time. Lately this hasn’t been working that well, possibly due to his wife’s new vacuum cleaner. His wife finds that to be a good thing, Doc Invisible doesn’t.

Fartman
Fartman is one of the few super heroes whose abilities manifested themselves only at a high age. A complication during a colonoscopy operation gave him his ‘special gift’. His colleagues at the office were happy to throw him an early retirement party. No Mexican food was served.
Age: 64
Abilites: His internal blowback system enables him to ‘jump’ extremely high. This works best after dinner at the taco bar on the corner.

The Robot
The Robot was built as a fighting machine by the military in the 1920s with an advanced A.I. it soon developed a conscience, left the military and successfully sued his ex-employers. The Robot now lives in San Francisco and enjoys watching dolphins. The military started developing ‘semi-intelligent’ drones and robots that don’t think that much.
Age: 89
Special Abilities: His steel body protects the robot from most attacks. However, time has left its marks, and the ‘guaranteed stainless steel’ by a Chinese quality manufacturer has started to rust.

 

Each of our team now set about creating one actual characters. I did the robot. What I tried to achieve here was a 20s feeling. The robot’s strength is obvious,but it still has a kind of utilitarian beauty.

No point & click though, the game will be purely keyboard / controller controlled for PC, Mac  & Linux, maybe with mobile support at some point.

All the dangers and  challenges of daily student life need to be overcome. Pesky professors, annoying students, office chair races.

Gain health by drinking coffee & soft drinks, eating chocolate and pizza, but beware, if you drink too much coffee bad things might start to happen.

Stephan will provide the pixel game art while I will do the programming (probably C#) in Unity.

When we asked our fellow students to collect wrappers, I quickly got the idea that the best contributor should get a reward. A race? Maybe a horse race with bets? Soon the idea for a pixel style race was born but making it as a video game meant it would take too long and build a technological barrier for the participants. So I made pixel graphics of horses and a race track, added some achievements and intermediary goals and finally printed them out, put them on a wall and declared the contest for open.

The result was astonishing. After an initial slow start in the first couple of days, people started taking the race far more serious than expected. Some started collecting wrappers to get the bonuses for bringing in 5 wrappers at once and after only a week, the first racer had already contributed 10 wrappers and scored the first achievement – she got a feather in her jockey’s cap.

The game is still evolving. I’m going to adding dice throws for random bonuses whenever a player contributes a wrapper so people don’t hoard them to bring them in at once. There are many more possibilities to make the game more fun for everybody and game variants like ‘catch the rabbit’ may be the way to go for round 2. I’m looking forward to see what happens.

The Ritter Race rules
1) declare a race track. The track needs an arbitrary number of fields, our track has 78 fields, created by the bricks on the wall. The number of fields should depend on the number of players and their grade of addiction to chocolate. You don’t need to use a wall as the race track but it’s probably most fun.
2) Create player tokens. You can use our pixel race horses, but anything will do, really. Make them funny.
3) Create achievements for reaching intermediary goals and set a reward for the winner.
4) Make sure everybody has ample access to chocolate, buy a couple of bars and resell them if your local vending machine doesn’t have enough in stock.
5) Make a list of players and their horse names to track progress.
6) Ready. Set. Go.

Growing with the challenge is something every good game designer should be able to do. The 7day FPS challenge seemed like a good opportunity to test my game design skills and I promptly enrolled, without knowing if I would have to do it all alone or if I would find a team. Two days after the challenge had started I managed to convince my fellow students Maren and Malte to embark with me on that journey into the unknown.

It was quickly apparent that we couldn’t go for anything realistic on that limited time frame and thus we agreed on a black & white western shooter.

We learned a lot from the challenge. Concentrating all your knowledge into one project that needs to be finished quickly, working under extreme pressure and surviving without much sleep being some things, most importantly the essence of good teamwork.

More info on the game website.