This post is a continuation of Making of SketchBox 360: Pt. 1 . In the last post, there was a lot of discussion of about the engine and the tools used to build the game. Now let’s get to talking about programming the game itself. It’s always hard getting started with a new project. The question usually is “Where do I begin?” The answer is never straight forward and never the same for any two projects. Making something from nothing but an idea is an awesome power.
The first step involved with getting the project started was taking the animation engine used in FluidiMotion and implementing it into an actual game project. Again, I can’t stress how much I love the XNA Framework for maintaining my sanity throughout that process. Most of what this process involved was copying and pasting code from the engine and creating a series of helper methods to play animations and keep track of sprites. The very first animation we created was a cursor dot. A white dot with a ring around it that pulsated. The best way to make something work is to make what you are working on actually practical to the game.
After getting a cursor dot animating, the next step was to be able to control the cursor with the controller. The control scheme sounds simple enough. Move the cursor with the left stick. Rotate the right stick to speed up the cursor. There were also 2 more control schemes that needed to be implemented later. This was surprisingly difficult because it seemed like it was always jerky and not smooth. This went on for weeks. The math worked out perfectly, but strange things were happening around the axies. The solution? GamePadDeadZone.Circular. Well, who would have known that XNA was kind enough to automatically deadzone our input! That is certainly a problem with a framework that tries to make your life simple. You don’t always understand exactly what it does for you, especially the times when it does too much.
So after all of that, all we’ve got is a cursor dot moving around the screen with a controller. Now all we have to do is finish the rest of the ENTIRE GAME. As it turns out, we had solved a lot of these tough problems early on. Programming the minigames and the drawing modes weren’t all that difficult once we got our collision all worked out (but that’s a whole other blog post). They ended up being a few thousand lines of code each. I don’t think many people can get a grasp of how difficult it is to program simple minigames.
The beauty of a DrawableGameComponent is that it keeps things separated out so neatly. I had maybe 4-5 of them just to mess around. I had one for testing the controls, the animation engine, playing songs, ect… After getting the dot moving around the screen, the next step was programming the animations for the PlayBox. I’ll spare everyone the gory details. I lost my sanity over it. I don’t feel like recalling the experience at the moment. All you need to know is that it was a lot of code. I then started programming Bumpers. I spent close to a month making Bumpers. The reason it took so long was that I actually was writing collision physics code that was to be used in all the other game modes. You might notice that Bumpers contains every element of gameplay in the entire game. Line drawing, ball/cursor collision, wall collision, and “state management.”
At this point, it was just a matter of iterating on parts of the game until they were finished. We had solved all major problems programming wise, and it was just a matter of coding. It took a few months after Bumpers was done to finish the game. Finishing and polishing the game, the other “20%” ends up being 80% of the work. In later posts, I’ll discuss the experience of the difference being the game being done and being ready to release. There’s quite a difference. That’s all for now. See you next time!