Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Suddenly, Thousands is a mob-controlling puzzle game developed for Bacon Game Jam 08. In this Post Mortem, we discuss the strength in Suddenly, Thousands' level progression, embracing accidents, and danger of making your development process open-source.
[This is a cross-post from Omiya Games' blog]
Now that Bacon Game Jam is over and I had some good time to rest, it's a great time to do a post-mortem!
Suddenly, Thousands is a mob-controlling puzzle game that uses a recruit and dismiss system like Pikmin and Little King's Story (more closer to the latter), while implementing a synchronized character movements like The Swapper. It also allows you to switch which character you play as, which turns out to be a critical element in the later levels, as some characters are shorter and can fit through smaller spaces, while others jump higher and reach higher locations. Combined with the many dynamic elements of the game, including movable blocks, deadly lasers, switches and doors, the game becomes a chaotic and challenging experience for the player, yet oddly manageable.
It was developed by one developer in 48 hours for the Bacon Game Jam. In fact, it's available for voting right now!
Embracing Accidents
The theme for this game jam was "millions of them." Initially, when I was brainstorming on the theme, I've decided to go with a Hitman, Assassin's Creed and Watch_D0g hybrid idea where hints identifying the person to assassinate will trickle in through your device, and you had a short time limit to figure out who it was using Facebook data and stab him. The game would use some items that would disperse the crowd, spreading them out or isolating a few people to make it easier to find your target.
If that sounds incredibly daunting for a 48-hour task, well you'd be right. It was incredibly fortunate, then, that while developing the crowd AI on the first day, I accidentally dropped 2 characters with the same control script code. Watching these 2 characters move synchronously was so mesmerizing, I literally ended up playing with it for a few minutes before dropping everything I had and said, "Screw Watch_D0gs; I'm going to make this into a game." I couldn't be more happy about this decision, since the code was already there and the mechanic legitimately felt fresh and satisfying.
Using External Resources
So I won't mince my words when I say I'm a lazy programmer. Let me say that again: I'm a really, really lazy programmer. Knowing from experience that programming is typically the worst bottleneck, having the willingness to use openly available code and resources is a great attitude to have, especially during game jams. This time around, I used a lot of the code from the Unity wiki, Sample Assets (beta), and code I wrote for Ichabot Crane. They were all huge time savers.
Making Each Character Unique (Even If They're Barely Different)
Outside of giving each character a distinct model, I also configured them to have different physical heights, running speed, and jump heights. This turned out to be a huge strength in the game, as it drastically increased the kind of puzzle elements I could introduce, and gave a distinct personality to the game to differentiate itself from its inspiration, Pikmin and The Swapper (though it's not nearly as distinguished from Little King's Story; that game is brimming with personality). Additionally, the differing run speeds adds a lot to the chaos, an element I found to be the most entertaining part of the game very early on. Just making small differences like these can make a huge difference in the impression one gets from the game.
The First Three Levels
Having made many game jam games by now, I pretty much have the order of which to introduce elements in a game down to a science. Basically, my formula goes like this:
Level 1 tells you how to control your character in a stale but safe and non-distracting environment.
Level 2 lets you practice what you learned one more time in a slightly more dangerous situation.
Level 3 is the level where I instantly drop the player into the meat of the game, letting them know why they're playing the game, and why it's so unique.
I started working on this level progression with Touch Yoga, and used String Theory and Ichabot Crane to really fine-tune this structure. I felt like Suddenly, Thousands implemented this in the best way possible, especially after watching this Let's Play of an early build (that had a lot of bugs and only four levels, grr...) that shows how effective this strategy is.
The Last Level
Unlike Touch Yoga, String Theory, and Ichabot Crane, I felt that Suddenly, Thousands had a wonderful final level. Yes, up to this point, I haven't been really satisfied with the last level I created for all the #OneGameAMonth games I've made. This time around, I think it's perfect. It properly utilizes all the mechanics I've introduced the player into a single level. It has a simple and easy-to-understand layout that lets the player easily figure out where to go next. And it has the incredibly satisfying feeling of controlling a ton of characters at once. This in comparison to all the other games where it was pointlessly hard and failed to utilize all the elements introduced earlier, let alone emphasizing why the game is so interesting.
Utilizing A Task Manager
Yes, for a coder, this is a very obvious advice: use a task manager. It was a life-saver. I started using BitBucket's issue tracker on the second day of Bacon Game Jam (first day was pointless because it was all experimentation). The tracker does an excellent job at reminding me what the priority of the tasks were, especially for this sleep-deprived event. Numerous times during the game jam, I have completely forgotten what to do next, so the issue tracker really helped!
Missed Narrative Opportunity
In an earlier post mortem, I said I would spend more time exploring gameplay and narrative integration. I...didn't for this project. I was short on time, but I feel like this was a huge lost opportunity to experiment with narrative for this game. I mean, all the elements are right there! The need to gather outside help, check. Progression gets easier as you gather more characters, check. The need to use individual strength, check. The devastating effect of losing even just one character, check. And the work to get everyone to the finish is sloppy but satisfying, triple-check. This would have been a wonderful metaphor for the importance of teamwork and individuals, but I completely neglected it! Grr! Maybe next time...
Too Much Time Spent On Graphics
If you watch the time lapse below, you might notice that I spent a bit of time on playing around with shaders. Then I do it again a little later, this time taking hours. Then again, slightly shorter. Then yet again...
Seriously, I know I'm a graphic whore when it comes to designing games (I have a very high standard on the games I make, even if it's only 48-hours), but taking this much time on it is too much. Originally, the issue I was trying to solve was the huge variance in character model and texture quality. Ultimately, I've decided to drop all normal maps, and use a post-processing effect that drops to details in the entire game, but the process to get there took way too much time. Seeing that graphics don't drastically affect the development of the game, I should have left that effort until much later
Level Design at the Last Day
Broadly speaking, my development process went as follows: Brainstorming the first day, implementing puzzles and mechanics the second day, and level construction in the third. This meant I spent about 8 hours (between 10:00 AM and 6:00 PM) to complete all 12 levels and credits. Bad idea. I honestly should have reserved a few hours on the second day to create some levels, and use the third to clarify them as well as adding more. It would have given me more time to understand what makes the game really tick.
Proper Credits
I'll be working on this later today, but I completely forgot to update the LICENSE.txt file in the BitBucket repository, which until yesterday declared that the entire project was MIT-licensed (it also stated the project was a template...which it wasn't). I greatly apologize. I should have constantly updated the repository's license as I imported or copied each individual file, at least to signify which folder belonged to which company/individual. Better late than never.
Lack of Marketing Material
I didn't have much to market other than screenshots, gameplay video, and the time-lapse, which is a real shame. Right now, the Bacon Game Jam voting period is going on, so I unfortunately lack the time to construct things like trailers when other methods, like playing other people's games, commenting, and providing lets plays, are more effective means to get votes. Plus, I need to spend some time on my next project, Prototype: Murakami.
Terribly Fickle Controls
The controls in the game is honestly not on-par with my standard. The characters move sluggishly, and the camera controls are incredibly wonky. Given the time I had, I'm only slightly unsatisfied with what I have, but I really think more time should have been spent fixing these.
Not Enough Juice
While technically, puzzle games are exempted for requiring a lot of juice, a little more could have seriously helped this game. The one element in particular I think could have benefited from juice were the switches goals, especially when a character enters or exits their field. As of right now, I only have sound and a change in label, which isn't enough of an indicator in my opinion. Additionally, I could have in a very short amount of time implemented a projector that indicates the range of character recruitment, making the mechanic that switching characters also shifts the recruitment circle more obvious.
Lack of Sleep
Well, duh.
Schedule Level Construction Earlier
Levels are obviously one of the most important core experience of video games, so I need to put more emphasis on them. In the next set of projects, I'll do my best to allocate more time to explore designing and polishing levels. As they say, it's not the quantity that counts, but rather, the quality.
Experiment With Gameplay and Narrative Integration
I feel really ashamed for completely missing out on this, so I'll definitely work on it sooner with my next set of projects. In fact, as hinted earlier, I'm already working on it with Prototype: Murakami.
Get Comfortable With Making Marketing Materials During Development
It's going to be important moving forward to get used to creating marketing material, and allocating resources to distribute them as part of the development process. I'll spend much greater effort on this in the next set of games where I can.
Honestly, I'm really satisfied with Suddenly, Thousands for the time I spent on it. I cover the level progression really well (especially when taking into consideration how stressed I was), and the game has a lot more personality than I expected. However, I had a few easily avoidable slip-ups that I need to be careful next time I attend events like these.
Suddenly, Thousands is available for free at the following venues:
You May Also Like
