Ludum Dare is a popular game jam, hosted on the website http://ludumdare.com/compo/ every three months. These game jams are events that take place over the course of 48 hours. Contestants are given a theme, which is chosen via a week-long voting session prior to the competition. Anyone can suggest a theme, and at the end of the week, the most popular one is revealed at 9 PM EST. The participants work by themselves and must make all assets for the game within those 48 hours. There is a secondary competition called the compo, which allow for people to work together, and use assets prepared in advance. For more information about the rules, you can check out their rules page. Who’d’ve guessed that?
This is the 37th Ludum Dare, and my third completed one. The theme, chosen by the community, was “one room” and my submission can be found here! It is a top-down action puzzle game where you control a wizard, hastily combing his room for reagents to stop a demon from entering his realm.
Game jams are a blast. I’ve only just started doing them recently as a hobby, but I’m taking steps to do them regularly. I still have some bad habits to tame and some tricks to learn. This article, along with future writings on this subject, is to catalog my growth as a designer in practice. Either that or clear the air or questionable decisions so I don’t look like a complete hack. Mostly learning though.
Without further ado, let’s dive into TROTW. Fun fact; the name TROTW is an acronym for “the room of the wizard.” Clever, I know.
Right away, I knew I wanted to do something with a wizard’s study. I enjoy the aesthetic of a wizard’s room: piles of books, drawers overflowing with magical components, ancient alchemical equipment, and powerful magical artifacts. The end result would be a stripped down version of this, much to my chagrin, but we’ll talk about that later. In this article, we will follow the sequence of events that went into making the game. We will also talk about how the event went overall, what I would have done differently, what went right, wrong, and finally whether the game was successful.
9 PM day 0; What can you do in a wizard’s room?
Well, I had a couple ideas for what I could do gameplay wise. The first thought that I had was a room escape game. The player would have to search in books for clues to riddles in order to escape his room. This, along with the other games that were brainstormed that night, shared a common theme of searching a wizard’s study or laboratory. I felt that when you are limited to one room there should be things to explore, a philosophy that would later bite me in the ass.
My mind eventually ran to a tower defense game. Originally, the game would take place in a library, and you would rearrange bookcases to alter the path of baddies. You would also pull spells from the bookcases, making the bookshelves both an obstacle and an inventory for spells. I felt that would be a little too much, though, as I didn’t want to deal with pathfinding. I still wanted the element of searching through a room to find the answers to a puzzle. This idea would eventually turn into the game I made. The baddie would act as a timer, more than an actual dangerous entity. The player would need to find the weakness of this enemy, and gather the necessary materials to kill it. The player would find the weakness of the enemy by examining its shape, and looking it up in books on a bookshelf.
We had the concept.
~10 PM day 0; Temporary assets and on paper diagrams.
I find that spending some time off of the computer and writing ideas on paper helps in the long run. I am able to budget time, although budgeting time effectively is still something that I need work on. I ended the night around 12 AM after I had made plans, the layout of the room, and temporary assets.
8 AM day 1; Let’s get started.
This is when I started the work day. By then I was sufficiently caffeinated and ready to code. I would eventually work until 1 AM the next day, taking a couple breaks in between for lunch and dinner. It is worth noting that if you plan on doing a Ludum Dare, you should clear that weekend. I make sure to abandon all contact with the outside world, to not be disturbed.
What took the bulk of my time during the day was how the player picked things off shelves. The way that it worked mechanically was the player had an invisible object that would be in front of them in the direction they moved. When the player walks into a table, they are stopped but the invisible object overlaps the table. This is how the game knows what ingredient list to display at the bottom.
By the end of the day, the player could move, pick up items off of shelves, drop items from their inventory, had a familiar that would hold the monster in place for as long as it had HP, and had a randomly generated demon to fight.
The demon has three parts, a head, body, and legs. All of the parts had a pattern to determine weaknesses and strengths, which were on a scale of -2 to 2. Monster heads would generate one weakness and two strengths, giving them a -1 or +1 respectively. The body would add +1 to three different elements, and -1 from three other elements. The legs then would invert three resistances, multiplying them by -1, turning resistances into weaknesses and vice versa.
6 AM day 2; Let’s get stopped.
…Day 2 was not as productive as day 1.
I had thought, that there were few gameplay mechanics to go over, and the day would consist of mostly of data entry, like giving names to the plants. This turned out not to be the case, as there were some problems with monster generation, beam particles, and ingredient combining. After those distractions were dealt with, I had started to create an array editor. I did this in order to create a text array that would contain descriptions for picked up items. Half way through creating this, however…
~ 12 PM day 2; Testing
I had asked my girlfriend to play the game to test it out. She agreed and sat down. I told her the basic controls of the game and where to find information in the game. I didn’t tell her which items made which spell or the weakness of any given monster. She was not able to find the monster’s weakness in time.
There were some things I took note of when she was playing. First, she would click on the tables instead of walk up to them. Clicking on tables didn’t have a function, but if the player naturally has that instinct, to click on the table to ‘open’ it up, then it’s worth looking into. I wouldn’t end up having enough time to look into that feature.
Second, when she had the spell ready to use, she would try to activate it directly on the enemy, instead of bringing the spells to the table. This would be something that I would need to point out in the tutorial. The way that the mechanic was intended to work, was the player would take three spells to a conjurer’s table and it would shoot a beam that had the elemental properties of the spells.
At this point, I began to worry that my game wasn’t transparent enough and that the player would have no idea how to play. This was a huge problem with the last game I did for Ludum Dare. In that game, you would lay down a twisting corridor with traps to stop grave robbers. It ended up not being clear and players complained of not knowing how to play.
~12 PM day 2; I gotta fix this.
My solution was to add a way to stall the monster. Since mushrooms mechanically did not interact with other plants as much, I decided that the player should be able to revive the familiar with mushrooms. But that mechanic wouldn’t be completed until…
~3 PM day 2; I still haven’t finished data entering.
For the next three hours, I would fumble with data entries and tutorials to make the game clearer. Data entries were basically the names of flowers, and descriptions of combinations. By 6 o’clock I had completely burnt out and decided to submit the game as is.
- I liked how the generation of the monster turned out.
- I felt that the handling of the resources was done well.
- The concept was solid.
- I finished it.
- I didn’t add any music or final art into the game.
- The game is not as clear as I want it to be.
- The controls could use more polish.
- There is no real point to playing. You get a score, but it’s not that meaningful.
- Not enough testing. There are probably horrible bugs and misspellings.
- Lot’s of unplanned fixes and data entry left me burnt out
WAS IT A SUCCESS?
Learning is always my goal when it comes to game jams. Being able to practice programming is always a benefit in my mind, and in that sense, it was a success. I also feel like it is a unique concept so I’m giving myself points for that.
Is it a successful game? No. It does not adequately tell the player how to play the game, and not enough time was spent on balance and polish. I feel that if I were to continue to improve upon this game, I would need to first focus on clarity.
WHAT ARE YOU GOING TO DO BETTER NEXT TIME?
Next time I plan on easing up on the mechanics. The last two games were heavy in mechanics and lacked gameplay clarity. I overestimated what I could handle, and in the end suffered because of ambition. I also plan on budgeting my time better the next game jam in order to avoid burnout. I would like to take a shot at a platformer or a hack and slash game for the next entry. This may change when the theme is chosen, but the focus of my next jam should be simplicity.
WHAT WILL BECOME OF TROTW?
I’m not sure. If I put more polish into the controls, added music, and added art assets I can see this being a full game. One thing to consider, however, is how much work the player will be willing to put into learning the systems. As of now, the player matches plants based off of words, and the recipes are also given to the player as written directions. If I were to put more work into it, I would add accompanying pictures to the plants. This wouldn’t be limited to plants, monster entries and recipes would have some visuals too. Perhaps I could add a rulebook, similar to how Papers Please has a rulebook that searched in game.
Like with any other skill, game design is something that needs to be practiced to be perfected. Ludum Dare, along with any other game jam, is an incredibly valuable tool to test yourself. These are the marathons for game design. You are given the challenge to make a game within a theme over a short period of time. This forces you to think critically about what you should include in your game. You must choose which gameplay elements are core to your entry, and what can be cut for the sake of time. All in the hopes that you made something enjoyable in the end.