In this post, I will share with you guys some details about the game’s development and my final thoughts on the project. It ended up becoming quite a long text, but at least it’s good to have the process documented before I forget how it went. Please skip to the final parts if you want to see a summarized list of what went right and what went wrong. There is also a timelapse video featuring everything I mention here, in case you’re interested.
First of all, I need to say this was my first Ludum Dare and the experience was very enjoyable. I had already taken part of 2 game jams in the past, so I had a slight idea of what 48 hours meant in terms of development, and had already worked on game projects of my own, though I hardly ever finish them. I am a designer and I don’t know any programming language besides Processing, which I feel very comfortable to use (the reason why I chose to work with it instead of Scirra Construct, which was also an option). Since I knew there was a chance I’d make a platformer game, I decided to announce before the competition started that I would probably use some classes from one of my old games.
Second, I live in Brazil, so the competition started on Friday, at 10:00PM for me. Take that in mind when reading the time marks!
And last, I strongly suggest that you play the game before reading this, because I’d like everyone who plays it to have the experience of finding out what they have to do on their own. In other words, this post will contain SPOILERS.
Tools used
Language: Processing (java)
Map editor: Tiled
Graphics: Photoshop
Sound: Intended to use Bfxr and Famitracker, but ended up not having time to implement.
Development summary
Brainstorming and research (Fri, 10:10PM to Fri, 11:00PM)
I admit I was really lucky that the game idea came so quickly and naturally, unlike my other experiences in jams (according to my timelapse video, which I will post here later, I had the window resizing idea in the first 4 minutes of competition). For those who haven’t played it, my game’s core mechanic is that the character can expand the game world by literally pushing the limits of the application window. At first I was kind of disappointed by the unveiling of the theme, since “Tiny World” wasn’t one of my favorite finalists, but went straight to brainstorming right away. I basically first thought of the theme “tiny world” as a person’s private world, and then thought about social reclusion, which led me to the hikikomori (social recluse) cases in Japan. A long time ago, in a “Peter Molydeux”-like vibe, I had already imagined how cool it would be if the game window position was part of the mechanics, but never really thought of how would a game like that be. When I started imagining a game set inside a hikikomori bedroom, the idea of finding a way out in the least likely way came to my mind, and pushing the limits of the screen was one of the first things I thought of.
The first thing I did then was transforming the time limit I had stablished for the brainstorm (2 hours) in a time limit for a research phase in which I would check on the internet if it was possible to make window resizing using Processing or not. And if not, go back to brainstorming. After a successful test of window resizing, I decided to stick with the idea.
Still during this research phase, I found an interesting chart for web developers showing the most common screen resolutions, and decided that in the game window shouldn’t pass 1024×600 pixels (which is the window size at the final moments of the final game). Though the game wouldn’t be accessible by netbook users, it was guaranteed that more than 80% of users would be able to play, and this number should be even bigger if you only consider only the gaming community. The good thing is that, due to that screen size limit, I had no option but to make a short game. In other words, what was fortunate about the window size mechanic choice was that it solved two problems at the same time: It was not just a charming core-mechanic, but also a way of restraining me from taking too much time to make an unnecessarily long level design. When I had all the information I needed, which happened way earlier than I had planned, I started development properly speaking.
Early Development (Fri, 11:00PM to Sat, 12:40PM)
Throughout the 48 hours I kept an open all-purpose txt file that somehow served as a game design document. This text file was not very well-organized, but I don’t think they need to be when we’re talking about quick one-man projects. It contained:
- Important notes and numbers (like the starting and final screen sizes);
- A checklist of what I had to do, in order of importance (THIS WAS VERY IMPORTANT);
- All ideas for gameplay and story that came to my mind;
- Urgent matters (either big concept flaws that I couldn’t forget that existed, like “how does the player find out that he has to push the window limits?” or things I had to ask friends, like “can this bug be even fixed?”);
- Ideas for the game’s name.
At the start of the development, I could only make the window grow to the right or down, because of how java’s frame.resize() method worked. This led me to start drafting a stage where the starting room was located on the top-left corner of the map instead of the center, so I could try to visualize the gameplay and imagine what mechanics would have been neat. Due to the expanding and continuous nature of the map, I thought metroidvania-style elements like non-linear exploration and gradual acquirement of new actions would fit well, so I also starting writing down a few a actions that could help unveiling new parts of the map (ground pound, double jump, jet pack, etc).
First draft for the game world, with the starting room in the corner
Back then, I had already started working on an preliminary sketches for the main character’s sprite, and for technical reasons, I decided to turn the neckbearded human hikikomori into a snail, which would be easier to draw and animate, and fit the “recluse” and “tiny world” themes. As a result, I found it would be cool if the game world was actually the inside that snail’s shell. The problem was that, with the first room located on the top-left corner, I found it was a huge loss for the game’s concept that I wouldn’t be able to make a helix-based level design starting from the center. At this moment, I started losing my interest in the project, because in my head, the game experience would be way better if I could make the game area grow towards all 4 directions. On top of that, the constant window resizing would result on the player constantly having to move the window around using the mouse, which didn’t sound much desirable to me.
After insisting a little bit more on finding a solution for that, I finally found a way of forcing a window to be positioned always in the center of the screen, and that also made it possible for the window to expand to the left and upwards. On the other hand, by this time I realized there would be a huge chance that the mechanic wouldn’t work on other OS’s besides Windows, due how different OS’s might deal with window sizes. Either way, I decided to take the risk.
Up until this moment I had only worked on programming the basic mechanics and was kind of frustrated that it had taken so much time, after all, 1/4 of the competition had already passed and I still had no idea of what the map would look like and had hardly any piece of artwork. But I sent the first working prototype for a few friends to test, and their reaction to the window-resizing mechanic was so positive that from this point I started feeling motivated again, and worked more seriously on the project from this point.
Development: Game design (Sat, 12:41 PM, Sat, 8:30 PM)
With the level design back to being a spiraling maze of reclusion (wow, I liked the sound of that!), I decided for a while removing the metroidvania influences and making a 100% linear gameplay centered on simple platform jumping and enemy avoiding. Something like a snail-speed super meat boy with checkpoints and a good variety of hazards. That’s because I thought that it wouldn’t make sense to make a short, single screen game with metroidvania characteristics, since there would be not enough space to do backtracking, and the experience would be too short for the player to acquire items and new significant actions that changed gameplay.
The ideas I had for the game so far were the following:
- Starts off in a room with videogames, stacked pizza boxes and a computer.
- The character would ocasionally say things like “let’s see what’s on TV”, “I feel like playing videogames” or “I wonder what’s for dinner”, through a speech bubble.
- The player can interact with all those objects using the “down” key, which makes the snail use them or talk about the object.
- This misguides the player, who thinks he’s playing an adventure game. But this game is quite boring since it feels pointless.
- Only when the player tries leaving the room through pushing the window border away, the game suddenly transforms into an action platformer.
- From this point on, there would be 2 or more enemy types and other environmental hazards, like spikes and springs.
Thus reinforcing the concept of escaping from a monotonous recluse life.
After talking to a friend, though, I got the feedback that the window-resizing mechanic was neat but not enough to make the game fun. I somehow got convinced back that a metroidvania-style level design with a little backtracking could enrich the game more than a regular platformer and would fit well with the “expanding” mechanic. Since I’ve been in a really big vibe for this genre lately, I decided to give it a shot. After all, I found the “ground pound” ability a good solution for the downwards window expansion, and I didn’t find it a good idea for the player to start off with it right in the first room, so the idea of gradually acquiring more actions suddenly seemed very adequate for the game.
I then reviewed my list and made a final choice of which actions the player would acquire throughout the gameplay: ground-pounding, double-jumping and sprinting. Except for ground-pounding, none of them would need specific animation frames.
So when I got tired of coding, at around 1:00PM, I started working on the final character sprites. The snail, which was originally yellow and 1 tile (16 pixels) high, became way bigger (which affected level design a lot) and also blue, so details like the glasses and beard could be more easily understood.
From this point on, I spent a long time working on the game mechanics, because I didn’t want to start working on the level design before “feeling” how the game played and knowing all speeds, jumping distances, and enemy behaviour. This only happened by around 6:00PM.
I spent the following period finally working on the level design properly speaking, using as a guideline the following concepts:
- The level is has a spiral pattern-At one or more points, the player would have to go back to a previously visited room so he could reach a place he couldn’t before.
- Make all 3 abilities useful throughout the whole game, and not only in specific situations;
- Leave some spaces for for secret collectibles in case I have time to include some in the game;
- Rising difficulty
In 40 minutes of work I had almost 80% of the map done. Most of it is very similar to what you see in the final version of the game. By 8:30PM I had to stop working, only to return at midnight. At the moment I left, my checklist looked like this, in priority order:
- Damage & knockback (programming)
- Items (programming)
- Game Over & restart (programming)
- Items (art)
- Game Ending (art & programming)
- Title Screen (art & coming up with a name for the game)
- Tileset (art)
- Sound
- Checkpoint (programming)
- Fixing enemy behavior
- Furniture in the starting room.
I also listed a few animations like “adding dust clouds for when the snail is dashing” but realistically thinking I didn’t believe there would have time to implement that sort of polish.
Development – Final day, 22 hours remain (Sun, 0:00AM to Sun, 8:00PM)
I started working on each of the items in the list in the order they appear, and tried to do them quickly (for example, didn’t spend much time thinking on what appearance would be appropriate for each item and sticked with whatever was easiest to draw).
At around 5:30AM, I could say I finally had a fully playable version of the game, though there were still a few bugs here and there. Since I felt more relaxed, I even worked a little bit on a few non-essencial mechanics that were neat but not top-priority, like the checkpoint. At that time, I was already halfway through that checklist and started working on the title screen and ending screen art. I came up with the name “Recluse” because, even though I had more interesting name suggestions, this was the only one that fit the tiny title screen.
The ending screen art took almost 3 hours to make (wow) and I made it using illustrator since I had lost my tablet. After it was done I imported the curves into photoshop and stroked them with the pencil to make it pixelized. I thought the drawing would look way worse, so the final result kind of exceeded my expectations, even though it still looks like some sort of old educational game. But since it was not essencial for the game, I figured I shouldn’t spend any more time in it. It also took a lot of time to program the scripted animation, but both art and programming were done, at 2:20PM, I sent the first fully playable version of the game to friends to test, even though there was still no terrain tileset.
I researched references for the tileset and worked on it for around 3 hours, though I didn’t like the result, which kind of hurt my eyes. Feedback from friends pointed out that the game was too hard and that the dash ability wasn’t very noticeable, so I had to prioritize making a dust animation to indicate more clearly that the sprint was activated.
Comparison between the terrain tiles at this point and in the final version of the game
Even though I was still unhappy with the tileset and there was no sound in the game or furniture in the main character’s room, I decided to upload a fully playable version to the LD website 2 hours before the time limit (actually a friend pressed me into doing it, but I think it was one of the best things I did in the whole project). This was important because I found out what kinds of trouble could happen while exporting the game application and uploading the game.
Development – Final sprint! (Sun, 8:00PM to Sun, 10:00PM)
I had 2 hours to improve whatever I could in the game, so I decided to give up on the sound (the files were all already on the game folder, but I couldn’t find out why they weren’t working – after the competition ended, though, I found out it was just a missing line in the code) and include the bedroom objects, even though there wouldn’t be time to interact with them, I found them extremely important to characterize the snail as a social recluse and justify the game’s theme. When I finished doing that, I worked until the very last moment in a new tileset – which I liked a lot. In other words, I sacrificed sound in order to give the game better graphics, something I didn’t regret.
TL;DR:
What went right:
- Good project dimensioning.
- The game’s “expanding” mechanic implied that the game couldn’t be too long, at least not bigger than most computer screens. This helped me not overworking on the level design.
- Only started working properly on the “true” level design after I could feel all the player’s actions (jumping, double-jumping, sprinting, ground pound) and be sure they would be in the final version of the game.
- Showed the game to trustworthy friends while developing, who gave me good feedback and motivation.
- Had the idea really early, and found out how to implement window-resizing mechanics pretty quickly, too.
- The spiral level design fit the “recluse snail” theme like a glove.
- I really liked the final sprites and the tileset, they look different from my previous works, in a good way.
What went Wrong:
- Didn’t prepare myself beforehand. Found out during the competition I had lost my drawing tablet’s pen, so I had to make all the graphics using the mouse. Also, I spent MANY hours trying to fix bugs from the platforming code I used as a source (it was kind of hard-coded and it took a long time to adapt to a re-usable generic platformer). I could have done that before the competition and saved time.
- Had to cut down the double jump’s height midway through the development due to a bug. This made me have to redesign some parts of the map. Fortunately, though, the game is very short and that wasn’t too much of a hassle. If it was a big game, this mistake could have costed a lot.
- Lost some really cool graphics in a power outage, and part of the game documentation.
- Even though I think the game matched the theme very well, I could have made a better use of the expanding screen as a game mechanic, instead of just an aesthetic gimmick. For example, a friend found out a very interesting way of picking up one of the secrets, which involved not pushing one of the walls to its limit on purpose so you could stand on it later and reach a certain platform; I wish I had thought of that kind of use for the mechanic.
- Some things like the second jump height and the dash speed are lower than I planned because of bugs in my platformer “engine” and level design issues. I think both should be increased to make the mechanics better.
- I should have followed suggestions from friends and made the game easier.
- Enemy placement was kind of random and their movement pattern is weird and not very predictable.
- I didn’t really have a pallete, so I used colors kind of randomly.
Tips for future participants:
- Fall in love with your game idea. A project made enthusiastically is better than a project made by self-imposed obligation.
- Fall in love with an alternative idea before working on your main one. I didn’t do that, but that was risky. If you don’t, you won’t be able to give up on the first idea and still feel motivated, if needed.
- In my personal opinion, it’s better to make a game that’s close to your capabilities and spend the rest of the time polishing it than starting off a great game concept and cutting features that composed what the overall game experience was planned to be.
- Always have a quick way of transfering files from one computer to another beforehand. Even if you don’t plan on using more than one computer.
- Have a priority to-do list.
- Try to find solutions that solve more than one problem.
- If you’re taking part of LD for the first time, upload a preliminary version of the game BEFORE the time limit.
10
This entry was posted
on Wednesday, May 2nd, 2012 at 2:44 am and is filed under LD #23.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
