The 38th Ludum Dare has come and gone and I was lucky enough to finish a project for it. The theme for the jam this time was “Small worlds.” To catch people up, Ludum Dare is a game jam that takes place every 4 months (I made a mistake last postmortem, saying it was every 3 months). The community decides on a theme before the jam that everyone will follow. The participants then choose whether or not to participate in the ‘jam” or the “compo.” A compo is where one person makes all of the assets of the game within 48 hours. A jam allows people to team up and use assets that were prepared beforehand like art, music, or code.
If you’re interested in participating, check out their rules.
Like last time, I entered in the compo. My game is called “Small world, Giant steps” and was made in Clickteam Fusion 2.5. It can be played here, you don’t even need to download anything! Small world, Giant steps is an endless runner where you control a giant navigating his way through a village. The goal of the game is to get as far as you can while avoiding the destruction of the village.
Going into this project, I knew that I wanted to make a simple game. The last two games that I have made for this has been heavy in mechanics. However, each suffers in the same way; lack of clarity and polish. The last game time I entered, I made TROTW which was supposed to be an action puzzle game. Prior to TROTW was a tower defense game called Ludem’s Tomb. In that game, you were charged with making a tomb that could ward off grave robbers with traps. With previous failings in mind, I decided to go with a simple gameplay and concept.
9 PM Day 0: Coming up with a concept
The way that I like to do these game jams is to not make any code before I make a plan on paper. I’ll brainstorm concepts on paper and extrapolate from there. I started off writing down what I could possibly do with this theme. Originally, I had thought to do a Metroid-like game where the entire world consisted of a few platforming levels. Maybe the levels would loop on them selfs and navigation/platforming was the way to beat the game.
Mike, The other half of Designophiles, suggested a game where you play as an ameba. Although I didn’t go with the original concept, it got me thinking differently about the theme. It got me thinking that the physical world doesn’t necessarily have to be small, but everything in the world is. If you were controlling a large object, everything in the world would seem smaller. This is the concept that I decided to go forward with, you would be a giant, trying to navigate a town without causing too much destruction.
The game would consist of you balancing a marker on a balance beam with the arrow keys while pressing the appropriate letter key to make the giant progress. The letter is chosen at random. I put a hitbox under the giant’s foot. If there was a person in the hitbox while the giant took a step then they would be crushed and the player would be punished in some way. Because the controls were simple enough, I decided to make things a little more interesting for the player. In order to make the giant take a step, you need to press a randomly chosen key. This turned out to have the opposite effect, but we’ll get into that soon enough.
I concluded the night by laying out the structure of the coded events and made some filler assets.
8AM Day 1: Let’s get to programmin’
This day was dedicated to getting the basics of the game down. I would start with the balancing mechanic and the consequences of going too far one way or the other. This would cause you to fall down either forward or backward depending on which side of the balance bar you overshot. Then, I added the smaller people and hitboxes so there would be something to avoid stepping on. Lastly, I added houses and Inns. The purpose of these were an additional punishment to falling down, as well as adding something that would contribute towards your score. Crushing a building would result in the spawning of more villagers. Looking back I should have also had some positive aspect to avoiding buildings and people. The only thing that ended up contributing positivity to the score were steps taken and time played.
By the end of the day, I had the basics of the game down. It wasn’t pretty, and there was no real score or goal, but the bulk of the programming was out of the way.
11:30 PM Day 1: First Testing
I had presented the game to a few friends, Mike included. The consensus was that the game was frustratingly hard. It was not fun to control the balance with two arrow keys while simultaneously pressing one of the random 26 letter keys on the keyboard. I was very apprehensive about changing this, however. I had wanted the game to be reminiscent of Bennett Foddy’s games, where part of the fun was overcoming odd control schemes. One game, in particular, GIRP, uses all of the letter keys as well as the mouse to control a climber’s ascent. I decided to collect more opinions before I progressed and called it for the night.
10:00 AM Day 2: Second Testing
I decided, after getting some sleep and clearing my head, to cut down on a number of buttons the player would have to press in order to take a step. I reduced the inputs to q, w, e, r, a, s, d, and f. I then got another group of people to try out the game; this time people I didn’t know from a forum. Other than complaints about the art aspects (which I was changing in the meantime) they also came to the same conclusion that it was frustrating to control. I further lowered the controls scheme to q, w, e, and r, as those were all on one line. Players could now assign a letter to one of their four fingers and not need to look down at the keyboard. This change, along with the change in art assets, seemed to do the trick. People were playing and reportedly enjoying the game now.
One comment that I received, which I took note of, was about the nature of endless runners. They said that what they liked about endless runners was that their controls are typically easy to pick up. The challenge comes from dodging oncoming obstacles, or clearing gaps.
4:00 PM Day 2: Submitting the game:
It was around this time where I had the game basically done. There were a few bug fixes, but It was ready to be played. Family plans pulled me away from programming any further, so I submitted the game as it was.
- It’s finished! Which is always a plus
- It can be played in the browser
- It’s simpler than previous games I made, which was the goal
- It has non-placeholder art.
- No real goal
- Control scheme could have had more polish or done a different way
- No music or sound effects
WAS IT A SUCCESS?
As I have said before, and I will say every time, game jams are a good learning tool. If you came away from it with some sort lesson than its a good thing. I think Small World, Giant Steps was a success. The game is fun (from what people have told me) and it’s clear on how to play.
That being said, the controls need a bit more polish or a complete rework. I feel that this is the weakest part. If the controls were more simple, and the challenge came from the environment in the game, than it would be a more enjoyable.
WHAT ARE YOU GOING TO DO BETTER NEXT TIME?
Simple is definitely the way to go for now. I found myself being able to focus on other parts other than gameplay mechanics or data entry. In the future, I may make a more complicated game, but probably when I get better at coding or time management.
WHAT WILL BECOME OF SMALL WORLD, GIANT STEPS?
Probably nothing. If anything maybe I’ll make a follow-up game with better controls, but I don’t see me going back to add anything.
Part of the fun of awkward controls come from the satisfaction in mastering them. I feel like one of the things that Small World, Giant Steps is lacking is that it’s not that satisfying to progress. After a point, the difficulty plateaus, and there are no more challenges to overcome. If the controls involved some sort of physics, or the player was rewarded for constantly moving, then maybe that would help. But I feel there are currently no intensive for the player to come back and learn the controls.