Introduction

StickJitsu was a project brought to life as part of the first of two major group projects during the Game Development program at Full Sail. The course mostly taught techniques for working with a group of developers on a project, as most if not all of our programming projects at this point in the program were solo assignments. Groups were assigned by the course director and had between three to four members. The two-month course had one primary objective – design and program a game from start to finish. Once we started, it seemed like we had all the time in the world. That changed rather quickly once we began our projects.

The idea of StickJitsu came about by our group’s design lead. He was a fan of internet kung-fu flash animations; more precisely, the Xiao-Xiao films. If you’re not familiar with these particular animations, the emphasis is on fluid motion and cool maneuvers as opposed to awesome graphics. The characters in these animations are all stick figures, so there is absolutely nothing to take focus away from the action. Plus, using a similar art style for our game made it incredibly easy for us to make our own art work, which was great since we didn’t have an art team at our beckon call.

The cool thing about this game, is technically we were using a lot of technologies that you’ll find in the current generation of games, but the gameplay mechanics still has the same feel as older arcade style “beat ‘em up” games. Since we decided to use stick figures for all the characters in the game, we thought it would be easier to simply draw the characters instead of having to make sprites for all characters. A member of the team designed an awesome animation system that worked much like 3D animation systems you will find in current games, but projected into two-dimensions. Secondly, we had the idea to have all characters in the game react correctly when they get hit for the final time. You’ll see this referred to in some games as “ragdoll physics”. This feature made for some pretty cool effects in the game.

Now that I’ve gone over some of the features of the game and what it’s about, I’d like to tell you a little about my role on the team and what I did for this game.

My Role

For this project, I was my group’s Technical Lead. The titles given for this project wasn’t nearly as important as Final Project. Basically, what this title meant was that I wrote much of the underlying low-level systems in the game. I was responsible for the game’s state machine. This system kept track of the status the game was in, and made calls to the proper state functions when it needed to. This system has two parts – The game state machine class, and the game state classes. This object-oriented approach to state machines allowed specific portions of the game to be split up in a modular form so it was easy to maintain.

Second, I was responsible for researching a scripting language and implementing it into the game engine so that other team members could write scripts for the game. I chose the Lua scripting language for this project mainly due to the support behind the language, as well as the ease of integration with a C++ project. This allowed large portions of the game engine to be exposed to the scripting language so that game mechanics could be manipulated without requiring the game to be recompiled. The main use of the scripting language ended up being the game’s menu system (switching game states, etc.) as well as in-game triggered events, which I’ll talk about more in the Level Editor section.

Finally, the largest portion of my job on this game was the graphics engine.

Writing a Modern 2D Graphics Engine

As you might be able to tell from some of the other content on my site, one of my favorite areas of programming is graphics. Naturally, one of the very first projects any aspiring graphics programmer writes is a tile engine. Well, I had written one just a month prior but instead of reusing a bunch of old code, I started from scratch hoping to learn from the mistakes I’d made with the first one with a few additions of course.

For the game we used DirectX 9, mostly because at the time the project was written DirectX is the only API we had learned. The engine did most anything you would expect from a traditional tile-based game some of these features were:

• Smooth-Scrolling Tiles
• Multiple Layer Support
• Parallax Scrolling Backgrounds (for that fake 3D look)
• Animated Tiles
• Tile Alpha Transparency

To bring the game into the 3D graphics era I decided to design a simple post-processing effects system using HLSL Pixel Shaders to get some really neat image effects. This system allowed us to do some really cool things that just weren’t possible back in the day of the 2D action game. We used the system for water reflections on certain levels, a black and white filter for the pause menu, and added a little bit of camera blurring to our camera shake. Originally, I had planned to expand the use of this system to do dynamic lighting, but unfortunately time did not allow it to happen. Even so, these few additions gave the game a bit of graphical polish to an otherwise retro looking game.

The Level Editor

So now we have this cool game with the charm of an old-school favorite and the features from the latest and greatest (all that really techie stuff that I geek out on! :D) but how does the game get made? We surely can’t hard code the placement of -everthing in the game… Well, we could but it wouldn’t be nearly as cool as what really happened.

For StickJitsu, I wrote a level editor in C++ using MFC that allowed total control of everything that could possibly be in a level in the game. The editor allowed us to completely change the way the progression of the game without touching a single line of game code.

The level editor uses the same graphics system used in the game, so the levels look exactly the same whether you’re editing them or playing through them. I feel it is extremely important to give that consistence between game tools and the game itself, as it really cuts down on the amount of time needed to tweak your levels, so it’s something I’ve tried to do in all the graphical game tools I write.

Users of the level editor have the ability to create maps at whatever size they choose, create multiple layers to place tiles on, define tile animations and collision boundaries, as well as set level information and place entities (such as enemies and items) and scripted triggers to control game events like the end of a level or spawning enemies, etc.

Post-Mortem

I have to say, going into the project I was a bit skeptical but it was an awesome learning experience. Here are a few things I might have done differently if I had the chance.

What Went Wrong

• Work from a pre-existing code base if at all possible – For StickJitsu I had a large chunk of code written just the month before that I probably could have used – at least part of it – for this project had it not been a class project. Starting from scratch isn’t always the best way to go about solving problems, especially with the rushed schedule we had in this project.
• Get a realistic gameplan early on – With this project, I did a lot of dreaming. What I mean by that is I thought of all the really cool technology I could use to make this game, but in the end the game could have been a lot more fun if scheduling put more emphasis on balancing the game and creating additional levels. On the same note…
• Schedule time for play testing – One of the biggest things I believe we could have done a better job at is scheduling time to make the game fun. One of the most enjoyable features of the game, versus mode, was a last moment add-in to the game and was only in there because we had a certain number of features we were required to have in our game. We didn’t realize how much it added to the game until we played it with friends in other groups. So let people play your game, especially friends. They’ll be brutally honest about whether or not your game sucks. ;)

That being said, there were a fair amount of things that went right with the game.

What Went Right

• Unique Idea – I think this game idea was very original, and I’ll have to admit, there were moments where I wasn’t sure if we could get it done to the level we did before the final deadline. Our team took as risk with the game we chose, and just being able to say we accomplished a majority of our goals feels amazing.
• Passionate, Driven Teammates – Plain and simple, the number one thing you must have if you’re going to make through those long hours and sleepless nights through to the final deadline is a team that is passionate about the game and its success. This may seem like a no-brainer, but I’ve heard one too many stories about teams who had nothing but trouble because a single member wasn’t totally on board with the ideas agreed upon for their game. The team I had for this project was amazing, and wanted nothing more than to make a great game. This is a tough one too, because you rarely pick who your teammates are going to be.