Ludum Dare is a competition where developers create a game over one weekend based on the given theme. This was our first time participating and had no idea what to expect. We weren’t prepared for the brutal amount of work that would ensue within such a limited time frame…
The theme for Ludum Dare 28 was “You Only Get One”, which was disappointing because it’s so broad and generic. Almost every game has some element of “only getting one”. Such as you only get one life, or one weapon, or one power up, one way out, etc. It was actually harder for us to focus and come up with ideas when there were endless possibilities. On top of that, we were experimenting with a different brainstorming and creative process.
The Creative Process
Instead of referencing genres or listing ideas we thought were “cool”, we focused on identifying the emotions the player would feel and the overall experience. From a long list of emotions we ended up with despair and hope. Not very original was it? That’s why we decided to add in “politeness”, even though we questioned if it was really an emotion. Politeness was unusual, but we wanted to try something different. Also, we were recently inspired by a cafe that listed lower prices for polite customers.
At this stage we were tossing out ideas and game elements that could help us evoke these emotions: dialog, puzzle, time pressure, color and the absence of, etc. We had no clue at this point on how it would connect with the theme. The first night was tough because we had spent hours brainstorming but couldn’t visualize anything worthwhile, unique, or even playable.
We started focusing on colors and eventually sketched a rough grid with each cell assigned a color. The player would start at one end of the grid and need to reach the opposite end to win. For spice and despair, the grid would be littered with danger spots (i.e. mines) that kill the player instantly. To stay with the theme, the player could only see tiles/cells of one selected color at any given time. There would also be special cells where the player would have a dialog and choose to reveal a different color. If the player selected “polite” dialog options, they would have a more favorable outcome.
After we agreed to move forward with this concept, we came up with a prototype using spreadsheets. By flipping between sheets we could see how the grid would look like with different colors hidden. We spent the next few hours specifying how the grid would be created: grid size, number of dialog nodes, danger spots, etc. We also wanted it to be randomly generated for replay-ability.
First Playable Version
Since this was our first time participating in Ludum Dare, we had no idea what level of polish was expected. Programming was split into at least three phases: 1) proof of concept/core development, 2) visual polishing, feel of the game, and 3) debugging. We decided to use Unity because of it’s versatile tools, rapid prototyping capabilities, easy multi-platform deployment, and highly capable C# powering it all. The biggest programmatic challenge within the given timeframe was the procedural grid population with updatable parameters, such as: grid size, randomization ratios, safe zones and node distribution.
A playable prototype was made within the first 10 hours of coding, which incorporated all the initial game design concepts. We expected at least 5 minute gameplay sessions when we planned the game. However, sessions were more like 5 seconds. We realized the player was going into a minefield completely defenseless. To make matters worse, the angle of the camera made it confusing to move around. Simple actions like up, down, left, right, weren’t intuitive.
We were halfway through the competition and we haven’t even attempted to conceptualize the story or dialog. Also, it became clear that “politeness” just didn’t fit as we could barely hash out the main gameplay. The only way to make this game fun was to empower the player. So we decided to create special abilities. We knew time was going to be tight…
To address the most important issue, movement around the grid, we adjusted the camera angle and sacrificed the angled aesthetic. Next on the list was empowering the player. Although we could have easily reduced the amount of danger spots, we felt that removing the conflict would have made the game bland. We identified the reasons why this game was difficult: the player didn’t know where the danger was, they had no protection when landing on a mine, and there was time pressure. We began developing four special abilities (one per grid cell color) to counteract these forces and wrote up a backstory to tie it all together.
It wasn’t easy planning out new abilities. The two simplest ones, revealing tiles and protection where straight forward and worked wonderfully. The other two were half baked and not as practical. Also, the abilities system proved to be our second biggest programming challenge. It needed to be versatile enough to allow the same logic to be applied to a variety of the abilities: activation mechanic, duration, and cooldown.
In terms of polish, the game transformed into a much more enjoyable and better looking version with perspective 3D camera, animations, and some effects. We wanted to continue improving the abilities, but we ran out of time and had to wrap up what we had thus far. Although, tweaking never stopped right up until the submission deadline.
Even though our creation is essentially a “glorified minesweeper variant’, we are very happy with the game. We are continuing to work on it and making it the best it can be. Hopefully in the next Ludum Dare we can take our ideas further and execute unexplored concepts.
What went wrong:
- The game was really challenging because we didn’t have enough gameplay elements to empower the player. We could have identified this sooner and planned accordingly.
- It was more based on luck than skill. It didn’t feel like you can improve skill and overcome the challenge.
- We aimed for 5 minute game session, it averaged 30-45 seconds.
- The introduction story was conceptualized after the core mechanics. It was trying to provide purpose via a “spiritual elements” concept, which was too abstract for such a literal game.
- There was no tutorial or instructions. We just tossed the player into deep waters without teaching them how to swim.
What went right:
- Polish. The game had logo, sound, artwork, and there were no bugs.
- Although difficult, the game was generally fun.
- The visual design was minimalistic, colorful, and most importantly, something we produced within our skill and time limitations.
- We experimented with a new creative process and the result was not too shabby. We plan to keep refining our approach.
- Easily published for Web, Windows, and OSX using Unity. We wanted the game available to as many people as possible.
Play the Game – Official Ludum Dare Submission!
Update – new and improved version!
After spending a few more days, we were able to improve the abilities and refine a bunch of other mechanics. Check it out on Kongregate:
Keep in mind that the updated version is not our submission to Ludum Dare, because the additions were after the deadline. Enjoy!