Making of: Bullet Rain
http://ludumdare.com/compo/ludum-dare-32/?action=preview&uid=53115
In this post I’ll tell the story of a game, by telling the story of how it was made. The story is told from the perspective of the programmer. Please play the game before reading this, then you understand this text better.
Preparations
Two weeks ago a couple of friends of mine participated in a local gamejam. The team worked really well, even though our game was littered in bugs, and so we decided to participate in Ludum Dare. As the coder, I spent the last two weeks testing out frameworks, languages, building basic prototype games in multiple frameworks.
I had a couple of criteria for choosing:
1. It had to be in an easy-to-use language. C, C++, Haskell etc. are then out of the picture.
2. It has to have an active community
3. It has to have tiled integration out of the box.
One framework really stood apart from the rest: Love2D. The language (Lua) might be universally hated among programmers, but it does the job brilliantly. To me love2d combines the power of a lightweight, but feature-rich engine without the boring administration parts of programming.
Meanwhile, our music guy (Peter) worked on getting his guitar to connect to his computer and our art guy (Tim) worked on his skills. We also got a new teammember: Marijn.
First two days.
The first 6 hours of this jam were spent sleeping, we’re from Europe. After that, we started by brainstorming. Early on, the idea for an attack queue was oppered, which was really liked. Originally, the game was to be an RPG, with 3 slots being refilled from a pile. You’d get new attacks by killing enemies. 30 minutes of brainstorming (a lot of discussion, random thoughts, etc.) later it was decided to make a bullet hell. This would fit in nicely with the engine, the amount of art and the usage of music containing guitar sounds.
After that, everyone did his own thing for about 2 hours. I coded the basics of the game (gamestate management, game reloading, death, movement, scrolling, tile loading), quite some sprites were made and a beginning was made for the soundtrack. For most of the jam everyone knew what their task was and did it.
Four hours later we had a working prototype with moving enemies, bullets and one very basic fire pattern (one bullet every 0.5 seconds). Most of the rest of day one was spent on polishing the prototype and adding multiple enemy types. At the end of the first day we had a working prototype, but the art was lagging behind a bit, because our artist couldn’t be there for that evening.
Day two started early again for Peter and I, because we woke up early, so we could use that day as optimally as possible. This time was spent on optimizing code, improving hitboxes, adding functionality for multiple bullet types. Around 11 am that was all done. Also, the rest of the team has waken up.
The afternoon was spent writing special attacks and starting on the boss. The boss was an idea by Tim, in which I let him decide most of the phasing, telling him, I can do anything, as long as your boss works with rectangular collision, in fixed angle (every object is no the same angle). This sounds really technical and if you don’t understand it it’s because I didn’t explain it well. The game can explain it to you though. If you press tab it shows you where the collision engine (bump.lua) thinks objects are. You’ll notice quite a few odd things, for instance, the player is only a really small piece of the ship: the part around the cockpit. Also, some objects are a bit off. This is because the offsets had to be programmed manually and after a while I just gave up on doing them perfectly and went for a ‘good enough’ approach. This is a restriction of the collision engine we used. The boss he came up with is a threephase boss with different attack patterns for each boss.
The second evening, I started on the actual boss programming, with Tim peer-programming (I was tired) and the boss worked that evening. It’s firing patterns were a lot less satisfying than they are now, but it worked. Also, I got the wreckingball working.
During the entirity of the second day, Peter and Marijn worked on the music, sometimes switching to art and code respectively, if the need arised.
The third day
The third day was a lot less productive, because only two of us could do anything and even then only half of the day. It mostly consisted of bugfixing and slight improvements. It was during the second day that we decided to put the wreckingball as a standard secondary attack instead of as an upgrade. We felt that our unique weapon should be accessible and visible to all players. Our game is quite hard (even though I view it as doable if you take the time to memorize it) and some people may only retry two times or so and may never reach a point with a certain upgrade. We tried to put in the wreckingball as a main weapon, but.. The game would have been pretty much unplayable. It requires a lot of concentration to aim, which you already have on all the things to avoid on screen.
Name and Story
Around 4 hours before the end we realized something: we had no story, no name and no menues etc. I had facebook open and someone sent me a message asking me to play farmville. This immediately gave the spark to add the Fremium idea to the story. So while Marijn made the menues I made a simple (hacky) , hardcoded story system and wrote some cheesy story. After that we got distracted and started adding death lines to the game. The game features 15 different death quotes.
The two hours
We spent the last two hours working on small things and fixing sometimes big bugs. Two hours before deadline I found out that the wreckingball didn’t work properly at all, so I had to rewrite a few lines. It turned out to be really simple to fix, but it had to be fixed. Marijn meanwhile worked on polishing the levels, adding details. He also playtested the game a lot.. He even managed to finish the first level without firing and without taking damage.
Conclusions
I am very happy with both the result and the way we created it. It felt really good to have a prototype working early in the jam and having the last day just for fixing bugs means you can really polish your game. Some things weren’t implemented yet, such as the multiple player sprites, which were actually made, but never implemented.
The lessons I learned from this is to plan ahead, think small to big (what can I minimally do, what can I do if I have time left) and make what’s necessary, not more.
Another lesson is to not neglect level editing, because you need to have good levels to really impress. In this case, I think our game may have been better with a slightly more subtle difficulty ramp. However, this would have meant that to finish the game you’d need to do the easy (and boring) part a lot of times before getting to the difficult (and fun) bits. This is the main reason why we only had 3 levels: this takes about 2 minutes to finish, a few retries needed -> time needed to finish: 15-30 minutes. From playtesting with other students we found that most player either (A) finish the game in one go, because they played toho and think it’s fun, but quite easy, or (B) get frustrated at dieing three times in a row on the first level (the turret section) and use our RAGEQUIT option.
)
>PROGRAMMER USED ONLY ONE PICTURE