Kung Fu Killforce Postmortem
Oct 16, 2011—
uDevGames 2011 Entry
- Best Overall Game
- Best Presentation
- Best Audio
- 2nd place in Gameplay
- 3rd place in Graphics
About the teamAAA games, iPhone games, XBLA, and even the dreaded social game. At the start of the contest this year, I had just come off of being let go from my job, so I was looking to the contest and Kung Fu Killforce to be the beginning of a (hopefully permanent) indie career. And besides, I was looking forward to tangling with some old friends again!
Joining me this time as an artist was Mr. Erik Skov, who is a newcomer to the world of video games, and who I met through the Best Damn Podcast Ever. Blake Buck, who is the host of the Best Damn Podcast Ever and independent DJ, joined up to write some music. Finally we were rounded out by Mark Gardner, a longtime podcast listener who became our playtester.
About Kung Fu Killforce
Kung Fu Killforce is kind of a return to roots for me. My favorite dev to date is still Kill Dr. Cote, my first major game written in C++ and OpenGL, which was entered into uDevGames 2004 where it won best Gameplay that year. After several more indie game developments and over a dozen titles for the good old Capital-I Industry, I always missed the purity of that game. Sure, it was amateurish at best but the goal of the dev was very simple— to create a small experience that was still as fun as it could possibly be.
Since then, I’ve been a part of a lot of projects that were what I like to call Asset Tours. I did many huge development cycles for games where the gameplay was simple, but featured a TON of content and art. This also led to a problem: I like to make very difficult games. And the problem with a very difficult game that is based on content is not everyone will be able to see all that content. It’s a trap that even my last indie game, Laserface Jones vs. Doomsday Odious, fell into.
So with Kung Fu Killforce I wanted to make a pure arcade game again. It ended up with a little bit of content, like enemies and scenery but that only existed to provide variety in the gameplay (something which Kill Dr. Cote lacked.) I will leave it up to you to play it and decide if we succeeded. :)
For this project, I used the latest incarnation of my own “engine,” called FicTech. It has very few parts that I would call a proper engine, but it has a lot of code that I’ve developed to make things easier for me over the years. Admittedly, it’s designed more for myself— it doesn’t make much effort to be user- or client-friendly, it’s meant to fit my own coding style (which, over the years, I’ve been told is very weird) like a glove.
There was a ton of pressure to use Unity this year. A lot of people have been jumping on it in the last 12 months or so and many entries used it this year. I opted to stick with my own engine because of its ease of use for ME, and my familiarity with it. I’ve also designed my engine to be a game logic and 2D graphics powerhouse, and that’s where I wanted to focus my efforts with this game. Unity might be the fancy car that everyone wants to drive and be seen driving, but I chose to stick with my own trusty motorcycle for this dev.
The 3 month dev cycle looked something like this:
Month 1: Prototype.
I spent an entire month working on a prototype and getting that extremely fun before I tackled anything else. I had a base set of graphics from Erik and placeholders for the rest, and just prototyped, prototyped, prototyped. There were two major aspects of the gameplay that were new and unproven for me, and those were the platforming and the beat-em-up aspects. I had experience making beat-em-ups already from Pride and Prejudice and Zombies for Freeverse, but I felt the gameplay I did there was still flawed and not as fun as it could be. And I’ve NEVER done a platformer before. In that sense, this was an extremely risky dev, since I was out of my shooter comfort zone of “point at things and they die,” but I wanted to challenge myself with something a little more complex (see more about that under “What Went Wrong” below, haha) and honestly I didn’t want to enter three shooters in a row to uDev.
The beat-em-up portion was fairly easy to get going. I had some melee attack code in place from Pride and Prejudice and Zombies to use as a starter point (I call it “Ficticuffs”) and it wasn’t too hard to retool it to get it working in two dimensions and beef it up for what I needed here. I designed Ficticuffs to handle pretty much everything you’d need for a fighting game, including arbitrary hitboxes, priority, windup/cooldown, movement, and invincibility frames.
The platforming section, however, had to be created from scratch, and took several iterations to get it feeling fun and prevent it from impeding the gameplay. I tried several approaches, including a tile based platforming system (yeah no), and then arbitrary quads (decent, but still not fun and led to weird collision edge cases), until I finally settled on arbitrary line segments. They had to be simple enough to not cause a ton of weird behavior when you say, hit the corners or hit the platform at a certain speed and at a certain angle, but flexible enough to make any sort of arrangement possible.
Month 2: Architecture
This was the boring one, and I think it’s where most people burn out. After the super fun prototyping phase, I had to get all the systems in place for being able to make the rest of the game (and its content.) For the first two months, I had several levels planned out, so I coded support for an arbitrary number of levels with arbitrary objects and platforms. Also originally, the player chose ONE style in the beginning of the game and would keep that style for the whole game. The scrolls didn’t exist. So architecture for choosing a style was added as well. Finally, I needed really good control on spawning enemies at certain times, and being able to have an arbitrary number of enemy types and be able to add/remove one easily depending on the amount of time I had remaining.
During this time, Erik and Blakebuck created the vast majority of the game’s assets. Adding them in during the second month kept the sense of progress going somewhat, since architecture is a big huge chunk of time where you’re adding SUPPORT for things but you don’t see any of that reflected in the user-facing product.
Month 3: Content and Balance
This was both an incredibly fun and incredibly stressful month. Many features had to be cut (including all of the levels except one, which is still a little heartbreaking) and many changes were made to the design to make it feasible to finish in a month. For instance, the pre-game style choice was removed and replaced with the Scrolls, which gave you a random style. This a) allowed for the player to see all the styles in one playthrough and b) didn’t force the styles to be AS balanced, which ended up being a boon because they’re very much not.
Also all of the enemies and AI were added during this time, and many of the cool little extra scenery items in the dojo, and a few extra licensed music tracks and all the menus and UI.
Finally, during this month (right at the end, which I regret a bit) I added the game’s adaptive difficulty system. I wanted the game to be fiendishly hard, but I also wanted anyone to be able to at least jump into it without getting their face ripped off, and I wanted to reward and challenge players who were extremely good at the game. I’ve always considered arcade games to be a force— not like a force to be reckoned with, but in the mass times acceleration sense. The game’s difficulty is a force, and the player’s skill and achievement is an opposing force. When the two are pushing equally, the game is fun. If the game pushes too hard, the game never becomes fun, and if the player gets good enough to push the game around, they lose interest. So I wanted a game that, the harder you pushed it, the more it pushes you back. BUT, I also believe that the game, once it pushes with a certain force, must never let up if the player starts sucking. Even unperceptive players will notice this, and when they do, it’s insulting. Adaptive difficulty should NEVER ask players mid game if they want to turn the difficulty down, even if that’s what they want to do, or lower it by its own choice. It should start at a level that anyone can play, and then ramp up to meet them as quickly and as transparently as possible.
I think I have accomplished that— the rampup feels good to me, but the jury is still out on whether the rampup is good for everybody which is the goal of that whole system.
What went right
Supportive Friends and Family
Of all the things that went right this time, this one went the MOST right. I’ll be honest, losing one’s job does a number on one’s psyche and raises a lot of self doubt. I wrestled with that a lot this time, more than in previous contests, and was very lucky and fortunate to have a ton of support from awesome friends and family to keep me positive and keep me motivated. They kept telling me that I was where I was meant to be, and that I was gonna do great. They sent cards and candy and brownies. And when it came time to vote, not only did they vote, but a lot of them showed the game to their friends, spread the word, and became evangelists for me, which floored me and I am forever grateful to them. They know who they are. :)
Returning to Roots & Finding My Own Style
As I mentioned before, this was sort of a return to roots for me, a return that I’ve been dying to make for a long time. Being able to create a pure arcade game again like Kill Dr. Cote was incredibly satisfying. I think another reason why Kill Dr. Cote was such an enjoyable dev for me is that I myself was a pretty blank slate at the time. I wasn’t sullied by expectations of the type of game I should produce or what things those games should have in them. KDC was when I was most being myself, and being able to return to that was incredibly liberating and resulted in a game I’m not ashamed to scream about.
Additionally, I pressured myself into copying the style of 70s Kung Fu Movies for Kung Fu Killforce. While I still did with the logo and title sequences, the gameplay is vintage Fic. It took a long time to come to that decision— for awhile I was looking into desaturating the colors and blurring things a little bit to make it look like a 70s movie, even writing a few 70s movie shaders. I even had a black and white movie shader written that left all the blood bright red. In the end, I didn’t want to make things look WORSE just as a style choice, and opted to just go nuts the way I like to do, and I think it was the right choice. The 70s influence the game in all the right places (the logo, and the sound effects especially) and it tactfully backs off in the places where the game needed to be itself.
Modular & Scalable Design
Having a scalable design helped out a LOT in the final month when I had to make cuts left and right to the game. There were originally 5 levels, each with its own boss. But the architecture in place, and the design of the game (just pick a level and go, no progression) let me cut that down to 3, and later down to one really great level. Also, the three best bosses DID make it into the game, but only one is the actual boss. The other two (Jimmy Han and the Sky/Wind assassins) became regular enemies. Sadly, the chainsaw-armed Jimmy Han had to be simplified a little bit— we also have him swinging around a claw a la Enter the Dragon, and even spraying bullets around with a massive minigun arm. Maybe in a future update. ;)
What went wrong
Too Many Knobs
I mentioned earlier that I wanted to challenge myself with something a little more complex. The game ended up being a LOT more complex. In games like Kill Dr. Cote and Laserface Jones, I made sure to add a few game design knobs that I could jiggle around and easily change the parameters of the game. Kung Fu Killforce has about ten times as many knobs. Being able to tweak damn near anything was a boon, but when changing something requires that you choose 3-4 knobs to tweak out of like 15 that affect that portion of the game, it becomes overwhelming. As a result, the game isn’t as balanced as I’d like it to be.
Poor Time Management
One would think that having no job this time around would help matters, as it means more time to focus on the contest and developing the game. It was actually the contrary. Talk to a lot of newly self employed people and they will tell you that when you don’t have a job, you’re always working, and that was certainly the case here. The result was many days of me, zombified, in front of the computer, making no progress, while my body was begging me to take a break but my brain freaking out that any moment I didn’t spend working was a wasted moment.
For Laserface Jones, I made that WHILE I had a full time industry job, and not only that, crunchtime on the job happened at the exact same time as crunchtime for the contest. BUT, it got me into a very good rhythm— I worked on design in a Moleskine on the subway ride to work, worked on a different game, and on the way home, went over that morning’s designs, corrected, and did a little more, including deciding what to work on when I got home. I was in front of my laptop maybe 33% of the time for Laserface as I was here, but that 33% was completely focused and efficient work. It also prevented burnout, which hit me HARD this time, and several times at that.
And the kicker is I got about the same amount of work done on both games. With Laserface requiring about one third of my time, that was a FAR more efficient dev.
Not sure why I didn’t do it this time, but I didn’t. It was a combination of having an old, lame website that I didn’t like and was half under construction, and feeling like I should spend more time actually coding. The boons of blogging about progress are great, and I even advocate it in my uDevGames survival guide, so it’s kinda unforgivable that I didn’t do it. ;p
Late in the third month, I started pulling all nighters to get the game where it needed to be, and I found myself in search of good late-night snacking items. The typical crunchtime staples of beef jerky and energy drinks were present, and then I was derp-derping around the convenience store downstairs one day and I found them.
Breakfast hot pockets. Applewood smoked bacon, egg and cheese. “Good source of Protein!” The box boasted.
I hesitated. “Made with Real Eggs & Low Fat Cheese!”
I bought em. I don’t know if I was getting them just to joke that I got hot pockets for crunchtime or if I was actually planning on getting some sort of actual nutritional value out of these things, but I bought em. That was my first mistake.
The second mistake was eating them.
The box had proudly said: “What could be better than fluffy eggs and melty low fat cheese wrapped in a tender flaky crust?” As it happens, what’s better is eating one and then collapsing in a heap in the shower dry-heaving for 30 minutes and wishing for the sweet, sweet release of death as soon as the vile things clear your esophagus and enter your stomach.
I’d like to say I’m getting better at this every go, but I’m still making a lot of mistakes. But I’m zeroing in on a good style and development process that works for me, and in the meantime, I have so many awesome people to back me up, for which I am forever grateful. And the result is a game that I promise will rock your face, and is also a good first step (back) into the world of indie development. So I hope you enjoyed the game, and I hope you learned from my trials and tribulations with this postmortem, and if there is one piece of advice I hope you take out of all of this, it would be
DO NOT FUCKING BUY HOT POCKETS.
|Release Date:||October 2, 2011|
|Length of development:||3 months|
|Key Development Tools:||Xcode, Adobe Photoshop, Pixelmator, Ableton Live|