In this article I try to give you an inside look on how the development process of our game for the indies VS pewdiepie gamejam went! In the first part I tackle the core Idea and Game Design.
[As posted on The Way of the Indie Game Developer]
Yeah! Post mortem time! Well kind of... Most developers don't bother writing post mortems for jam games, at least not until the end of the voting process. I am going to take a different approach on this. I think a post mortem is not only about how good a game turned out to be or if the game won a competition or not. I think a post mortem is about how well the development went. Did we meet our goals? Did our time management techniques work? Where have we failed? What can we do better next time? Did we make an interesting game after all?
First of all a game jam is like a post mortem writer's Christmas! What more could I ask? The entirety of the development process compressed in three days! It is really easy to see what went wrong and what not!
But first things first! You'll want to have the game for reference!
If you want to download the jam version of the game you can go here!
If you want to download the five-minutes after the jam version of the game you can go here!
While you are at it you may also want to vote for the game which you can do here!
Okay now that you have the game let's get ourselves started!
You can ask anyone, the worst part of making anything is finding where to start. Well that applies to game development as well. It's not that we did not have ideas, oh boy we had ideas... Most of them were superfluous, not-implementable or downright stupid! A farting unicorn endless runner, was the best idea we had and we were pretty sure we were going to make it. Most of us were disappointed with the idea but it was better than nothing.
Two nights before the jam our lead designer, Ilias, said something in the lines of "We are not five years old to find a lion on roller skates funny, personally I laugh way more if I see someone mess up a presentation". I was quoting him to the rest of the team when it struck me! "What if we make this?" I said. No one was really happy with the farting unicorn solution so everybody played along, It was decided. We were humiliating a presenter!
After that the name came to us pretty much without effort. Sabotaz Inc. what else would you call that game?
Was it a good idea? Well in retrospect I think it was. It is something we can show to the world without feeling ashamed, (I mean; come on farting unicorns?). It has a touch of novelty and can be implemented in many ways!
What went wrong? For all I can tell nothing. This must be the best part of our development process. The idea was as solid as possible!
Our team currently consists of 6 members. One dedicated game designer (Ilias), one designer/graphics artist (Panos), one animator/graphic artist (John), one graphic/concept artist (Kostas) and two programmers (me and Manolis).
Dividing labour correctly is one of the most important factors on the success of a project. First of all it was obvious that Ilias would work on all things design related and John would as always create and animate the characters.
The rest of the team was trickier. Panos had always have a more minimalistic approach on graphics and for that he was the best person for creating the UI elements; he also doubled as a designer when Ilias needed help. That left Kostas to create all inanimate objects and backgrounds. That worked well for Kostas since he was the one we had left in charge of our social media as well.
Since there was a need to create original music we had to find someone to write it. I usually write music but in 72 hours I was far better coding than doing literally anything else. So we went searching for outside help. First name that popped in mind was Aggelos! A friend of ours and bassist at Void Droid. He came when we called and that covered music!
Finally it came the time to decide what we programmers were supposed to do. After some talk and judging from our past experience we decided that Manolis would do the UI and anything not related to mechanics and gameplay. I, as you may have guessed already, would code the core game.
Was it a good idea? Fortunately everyone had a very specific job that corresponded to their strengths so we had the best line up we could possibly get.
What went wrong? Even though Kostas managed the social media pretty smoothly he was still doubling. That did not affect his work as a graphic artist but I would have preferred to have someone not involved with the development itself manage them.
The shooter was the most obvious genre to go with this concept. At first we thought of making an assortment of different "weapons" which you could buy and upgrade. Every weapon would have a different effect on the presentation (dazzle the speaker, destroy the projector etc.). Unfortunately the implementation of the blowpipe was going way to slow so that did not leave us time to implement other weapons. We didn't specify exactly how this would help you progress towards victory but it sufficed for the moment. Then we needed a losing condition. "Security guards!" Panos said.
At this point (about an hour in the jam) we had a basic idea on what we had to make. A blowpipe that would throw spit-balls on a presenter on top of a platform, security guards patrolling between the seats, one humiliation bar that shows the progress towards victory and one detection bar that shows your progress towards failure. As you can see in the following screenshot from the final game we implemented most of the features we planned in those first couple of hours of the jam!
Were is the detection bar? Well we crossed this part out a bit later. When Ilias started thinking with more detail on wining and losing conditions he realised that a detection bar was a bad idea. The game would be extremely easy and hard for us to scale the difficulty in later levels.
You have to understand that at this point in design the detection bar was not totally created yet. We had a vague idea on what it was but it was too generic for us to do anything with it. That's when we decided it should go! Instead we added a total of three losing conditions:
a) If time runs out you lose. Timers are always the easiest way of scaling difficulty. You don't know how to make something harder? Put a timer on it! Even trivial tasks become hard when you have to do them within a certain time limit. Just imagine having to get dressed in less than three seconds!
b) If you run out of spit-balls you lose. Well it is a shooter isn't it? Why would you have infinite projectiles? What is this the 70's? Jokes aside finite spit-balls give you just another number to play with. Find the right place for it and you have yourself the difficulty level you desire!
c) Security Guards! They're big, they're scary and they're wearing black! Avoid detection and you'll be fine! Don't and... "HEY YOU!"!
If you noticed I wrote avoid detection, not avoid hitting the guards. That is because at this point having the guards as moving obstacles was Plan B. Plan A was a bit more complicated.
Let me introduce to you the idea of disguise! Two and a half days in and that concept was still in our minds. I hadn't implemented it yet but I sure was thinking of it. Let me explain what that is. You were supposed to be part of the crowd. The blowpipe would still be where it is right now but you were supposed to be someone sitting somewhere in the scene. Every guard would have a certain range of detection and if you fired your blowpipe while you were in that range you were being detected and immediately lose.
When it came that fateful hour to decide between Plan A and Plan B we immediately saw the flaw in Plan A. What was that range supposed to look like? How are we going to make the player understand it? Will it only work when you shoot the spit-ball or do you have to try and keep the spit-ball out of guard range as well? Those were too complicated questions to ask 65 hours in. Fortunately we were smart enough to choose plan B then. Rule 1 of game jams, when running out of time something proven is better than something unique!
As far as winning conditions go we decided that your goal would be to hit the presenter a total of three times. We thought of giving more depth in this but all other solutions wanted us to invest time we did not have. So we kept this approach. The design team decided that the number of balls should be constant to have the difficulty scale only because of the losing conditions.
The last issue the designers had to tackle was the "weapon" upgrades. It wasn't that hard to see that having the same blowpipe throughout the game would make it impossible for you to get through some levels. So they started thinking of possible upgrades.
At first they thought of ball size, ball speed and rate of fire, After a while they decided that ball size was making the game harder instead of easier. Yes you could hit the speaker easier but the same was true for the security guards! They crossed size of the list and drafted an upgrade tree that looked something like this:
Red upgrades would give you a better ball speed, while yellow upgrades would allow you to shoot more often. Green upgrades were supposed to be visual updates of the blowpipe. The final green upgrade was supposed to be the "Corporate Destroyer 4000b". We all loved this design and still do but not everything can go perfectly. For reasons that will be explained on Part II of the Post Mortem we did not have the time to do this. As always the designers came to the rescue with an easy alternative. Check the players gold, if he has more than a certain amount give him all the percs up to each green update. In simpler words, do you have more than 1000 gold? Cool you get the first visual update and a better fire rate and ball speed. That's what we implemented in the uploaded game.
Was it a good idea? In my opinion more than simply that. It was one of the most sound design processes I've seen in a while.
What went wrong? As far as design is concerned nothing really went wrong. Some decisions were taken way too late into development (65 hours in) but that did not slow us down, since the rest of the team always had their hands full. The designers could not have done anything more to create a better jam game. Despite that there was one error in design that I can spot. There is no way of telling when you are going to get an upgrade. This is not the designers' fault though. We had to implement the upgrade system in the last hour of the competition meaning that they were working on their feet to solve the mess the programmers left behind.
Well that's it for today. I thought this could fit in one post but apparently I was mistaken. Part II will be ready hopefully within 24 hours covering Graphics and if that does not turn out too big Programming as well.
Oh by the way Asylum Project Global made a "Let's Play" video of Sabotaz Inc.! You may want to check it out!
Thanks to everyone for their support during the jam and for all your votes! It really means the world to us! Stay focused and see you in Part II! Cheers!
Read more about:
BlogsYou May Also Like
