Set to steal GOTY from the big publishers for sure!
Before this weekend, I didn't have any experience in video game development. Well, that's not quite right. I used to work in Quality Assurance for Activision on Skylanders Trap Team, and I did make a very small game during my introduction to coding course in University. But come on, limiting homework and testing for bugs doesn't prepare you all that well for the experience of real development. So, when I was approached by a gal at work to make a game with her at the tri-annual Ludum Dare game jam, I had my doubts. And yet, here we were last weekend! A misfit team composed of four people that, though all of us worked in a field related to software (The company three of us worked for specializes in intelligent search), isn't exactly made of industry veterans.
For people unaware of what the Ludum Dare is, it's a competition that challenges people (solo or in a team) to build a video game in a weekend. All that's asked is that you respect licenses; don't use copyrighted material and credit anything you use that hasn't been made by you. And in the end, you're encouraged to review games by other creators, which boosts the visibility of your own game in return.
Here's how it roughly went down.
While the game's theme was unveiled at 9 PM (EST), we met up more than an hour beforehand just to make sure everybody's setup was in good shape. We went with Python as our coding language, since we had more experience with the language before the jam, and pygame's a pretty good tool for displaying sprites, playing back music and such. I kind of wanted to prepare a lot of game ideas before the theme was unveiled, but the others weren't really having it. To be fair, there was like over a dozen possible themes, so it would have been a lot of wasted effort.
At 9PM precisely, the LD website was crumbling under load. But! Through Twitter, the chosen theme was unveiled: "Running Out of Power". At first, we weren't so hot on it, but it turned out to be pretty nice once we started the brainstorming process.
Some of the game concepts we juggled around during the brainstorming process include:
At first, we thought the last idea was the most promising, as it felt like a more creative application of the theme. Philippe, who originally came up with the idea, wanted to make a game where you'd dispatch people to repair lines or build new ones. It was decided that it would be difficult to make it fun to play without introducing complex concepts that would go beyond the scope of a game made in a weekend. I had a concept planned out in which you were contracted by a man known only as "Mr. Mustache" that wanted to build the best city in the world in three years. You'd build power facilities with power, health impact, cost and risk of catastrophic failure, and you'd balance. We decided that there would be little reason to not build every space the same way, which would make for an unexciting game.
Ok so it's like SimCity, but with Mr. Moneybags, what do you think?
So in the end, we decided to go with the more story-based approach of the third option, with a series of boss battles representing the evil powers. I felt like this could easily turn too political which would hurt the game, so I made an effort to make the game more comedic (I made the title and end screen, for example) to avoid making something that felt like it was pushing a message. I also suggested that the theme would be more obvious if it was also represented in the gameplay, which is why we made the player character's weapon run on a limited charge. Then, we dispatched the tasks. Marie would work on the general framework with features like UI that would apply to every boss battle, Alexandre would begin working on sprites, while me and Philippe started designing two bosses. This marked the start of the implementation, roughly 2 hours into the game making process.
This might seem like a lot of talk and not a lot of walk, but during the first day of a competition like this I feel like taking your time is rather crucial. We brainstormed individually multiple times for a couple minutes, and then came back with ideas to offer the whole group that became more and more specific. These early brainstorming stages are actually super important for two different reasons. For starters, they're very important to limit the scope of your game. A weekend is a very short time, one that isn't suited at all for large-scaled narratives or intricate mechanics. If you shoot for the moon and miss, you'll end up drifting in the emptiness of space; It's much better to design a small game that everyone is confident they can make. The second benefit of keeping your first day focused on brainstorming is that you end up with a more cohesive vision, where the team members' individual perception of the game aligns more. I think this is crucial in a game jam like Ludum Dare.
The crazy thing about making a game like this is seeing how quickly it builds itself around you. I came up with my boss idea Friday evening. It would be a tank-type boss that can move in all directions (without needing face different directions like a human would) and attack using its cannons. I quickly came up with the three different attacks that ended up sticking for the duration of the implementation. First, a regular-ass bomb with a regular-ass explosion. Then, an electric bomb that exploded into bullets. And finally, a dash attack to force people to move around quickly. I realized fairly early on that the first attack was the least engaging of the bunch, and so it was used less than the other two in the final result.
My initial design for the first boss was a duck tank with four heads, and a cannon mouth in each. I wish we could have kept that design. It was random and comical and I liked it.
Saturday was mostly spent on tuning the boss' attack patterns. I did end up also creating the tutorial boss late in the day, as the game needed to naturally teach the player how to charge before fighting a real threat. My initial idea was to have the player step on charging tiles in one of the corridors before the first boss battle instead, but that idea was scrapped because the player wouldn't be in the same mindset... So while Billy the tutorial battle isn't the most exciting enemy to fight against, he has a purpose still!
Speaking of the tank boss' attack patterns, my initial vision for the fight had it stay consistent through the entire battle. This worked fine enough during initial testing, but I ended up feeling like it needed to start easier to allow players to get a better grip on the boss' concept, and end harder to make sure finishing the battle was satisfying to the player. So I designed a very simple difficulty state for the boss that increased as the battle went on. While I ended up nerfing the boss more and more on Sunday to make him more manageable across all phases, I still think the end result might be a bit too overwhelming towards the end, especially to less experienced players. Still, this iterative process ended up improving the boss a lot.
A funny bug that happened during the time period when I was creating the boss' phases. It was stuck in a state, so it attacked every single frame. The resulting amount of bombs and dashes is something else!
Something that felt particularly useful during the implementation phase was taking breaks to talk to the rest of the team about the progress made on what we were working on, and what we were working on next. If something didn't mesh together quite well, we could give advice to each other, and the game benefitted from it. When Philippe saw my multiple-phase boss taking form, he wanted to implement something similar in his "laser boss", so he came up with the idea of making the battle more and more hectic as turrets popped out of the ground. Small things like that can really add up.
Somewhat disappointingly, we never ended up taking the time to compose or look for fitting music for the game until Sunday, the final day of competition for us (day jobs and all). Though honestly, I think Philippe did a great job with his picks of royalty-free music, so I doubt music will be what most people believe to be the Achilles' heel of this game.
If I had to change something about how we implemented the game, it would be to get people outside the team to test our game as early as Saturday. By the time we got useful feedback about difficulty or general design, like a lack of contrast between the UI and the background, we were already back to our day jobs. When you end up working with a game over and over, seeing it progress like that, it's easy to lose focus on the points that need ironing out. Even in small projects like this one, game testing could definitely make a difference.
You can take a look at the finished product for yourself here!
I'm pretty happy with how the end result came out! I'm proud of my team for not only delivering a fairly polished game, but also doing it despite a lack of experience and working together for the first time. Still, I think there's definitely room for improvement. I would have wanted to give the final boss a tell for his dash attack, and the character having a smaller hitbox would make players less frustrated. So I'm glad to have had this first non-Mario Maker experience at game design, as this is tremendous experience for whatever I end up doing next.
Hopefully, the next project will have more than a weekend of work put into it! ^^