Three-Eyed Monkey-God

I didn’t do much game programming this month, but it wasn’t a complete waste of time. In fact, I started my first open-source project on sourceforge! It’s called DiscInsert, which is just about the most uncreative name I could come up with, but hopefully it will serve some people well.

I wanted a program that could rip DVDs to my HTPC as soon as they were inserted—without any interaction from the user. It seemed simple enough to me, really. It would just need to have a set of ripping locations defined, and be able to connect to the Internet and download the title of the inserted DVD from some database. Then, when it comes time to rip a DVD, it chooses the first output location available with enough free space, appends the DVD title to it, and passes it all off to a command-line DVD ripper. It would also be nice if the program could display a “Play” button as well for a little bit, just in case you only want to play the DVD instead of ripping it. And since this application would be so well-suited for an HTPC, why not show the box art of the DVD and do it all with a nice and easy-to-use 10ft interface?

So that’s what I did. The only hard part really was finding a way to retrieve the DVD info from some online database. IMDB has no interface or API for this, Amazon is finicky and doesn’t always get the right DVD info, and there’s no open-source database for DVDs like there’s freedb for CDs. Then it dawned on me: Windows Media Player retrieves DVD info somehow, and there’s a Windows Media Player COM object. Why not check that out and see what it can do? Sure enough, Microsoft is apparently letting developers utilize their DVD database through the WMP dll.

Unfortunately, I couldn’t find a way to retrieve box art using the Media Player object. It seems like it should be able to since Windows Media Player can, but as far as I could tell there just isn’t a way (let me know if you’ve found one!). Box art is just eye candy anyways, though. It’s not really essential to get the right box art like it is to get the right DVD title, so I figured it was acceptable to pass this off onto Amazon. So once the correct DVD title is retrieved with WMP, DiscInsert uses it to do an Amazon search and retrieve the DVD box art. It works pretty well most of the time, and who really cares if you get the box art for the Kill Bill Box Set when you put in Kill Bill Vol. 1 anyways?

After the DVD info is retrieved, the program displays it along with nice, big and shiny “Rip” and “Play” buttons. You can also configure a timeout so the DVD will just automatically start ripping or playing after a certain amount of time.

The actual ripping and playing are passed off to whatever programs you want. You just configure a command line to be executed, and include placeholders for things like the retrieved DVD title, the first output location with enough free space, the letter of the DVD drive, etc.

Configure Windows to use DiscInsert as the DVD AutoPlay handler, and voila! You can now rip a DVD just by inserting it, with no other interaction whatsoever. You don’t even need to have your monitor or TV on!

I also decided to make DiscInsert open-source and put it up on sourceforge.net. It’s nice to give a little something back to the open-source community when I’ve gotten so much from it already, and I was really impressed with how much sourceforge provided for me at no cost. As soon as my project was approved, I had free web-hosting, a subversion repository, forums, support/bug ticket trackers, a task manager, a news server, MySQL databases, and shell access to a linux server—all setup and ready to go, and all for free.

The only hard part about making DiscInsert open-source was understanding, choosing, and implementing an open-source license. I ended up going with the GPL, and it all makes pretty good sense now that I’ve gone through it all. It was just a little time consuming for something I had never put much thought into before.

Anyway, so that’s what I’ve been doing with my spare minutes this month. Sorry no more updates on game development stuff, but hopefully you’ll find DiscInsert useful! Give it a look over on sourceforge!

Even with my extensive background in programming and web development, even with some nice APIs at my disposal, and even with my earlier experience doing QBasic game development, I still didn’t really know the first thing about how to structure a large-scale game project. Luckily I could admit this to myself and decided to research some of the approaches other people have taken. The first thing I came upon was the idea of game states.

Game States are basically the different screens you would see in a game. You start out with the introduction screen, then the title/menu screen, then probably the actual gameplay screen. From there, you could go to the pause screen, the ending screen, the gameover screen, or back to the title/menu screen. All of these translate into the different states the game can be in, and each one functions differently than the other.

Now, without thinking about it, you could easily just start coding your game without really separating out the game states. All you have to do is fill your main game loop with lots of “if” statements or a big “switch” block, trying desperately to keep everything organized. However, as you might have guessed, this will quickly get out of hand and before you know it, enemies will keep moving while the game is paused, the menu screen will show up but won’t accept input, or any other number of oddities that will just get increasingly harder to debug as the codebase grows. If you want to have any chance of being able to navigate through your code, you’ll need to find a better way to structure things.

The solution is to create an abstract GameState class with virtual methods like Update(), HandleInput(), and Draw(). You can then derive “subclasses” from the GameState class such as IntroState(), GamePlayState(), PauseState(), etc., and all you have to do for each state is fill out those few virtual methods.

You’ll also need a class that manages your game states—like GameStateManager. The GameStateManager typically holds a stack of GameStates and has its own methods for Update(), HandleInput(), and Draw(). The only thing these methods do, though, is call Update(), HandleInput(), and Draw() on the topmost GameState. It also needs methods for adding and removing GameStates from the stack.

So, to start out with you’ll just add the IntroState to the top of the GameStateManager stack. After the intro is over, the IntroState tells the GameStateManager to pop itself off the stack and add the GamePlayState. If the game is paused, the GamePlayState adds the PauseState to the top of the stack, so HandleInput(), Draw(), and Update() get called on the PauseState instead of the GamePlayState (because PauseState is at the top of the stack now). When the game is unpaused, the PauseState tells the GameStateManager to pop itself off the stack, which leaves the GamePlayState to resume where it left off.

This is a simple and effective design that will keep your different game states organized in a logical and cohesive manner. However, I’ve fleshed out the design a lot more to allow for more functionality. Things like state transitions, passing input, allowing lower states to draw “underneath” higher ones, and more will be supported in my engine very easily. As of now, it’s about 95% done.

“Only 95% done!?", you say? Well, the next thing I came across was the game object concept. The idea is that every object in your game (the player’s character, trees, rocks, sounds, lights, cameras, etc.) are all represented by an abstract GameObject class. Each GameState contains a list of GameObjects, and each GameObject has methods that are called by the GameState’s Update(), HandleInput() and Draw() methods. So until I figure out how exactly I’m going to implement GameObjects, the GameState stuff needs to be put on hold. It’s all done except for the areas that deal with GameObjects, so that’s why I say it’s 95% done.

I’ll share some code once things are more finalized, but for now if you’re interested in game states and want to know more, check out these articles that helped me get going:
Cornflower Blue: Basic Game Structure
Managing Game States with OGRE
Managing Game States in C++

Tune in next time when I’ll tie up these where-I’m-at-so-far posts with everything I’ve learned about GameObjects!

Anyone who knows much of anything about me knows my obsession for game development. Really, as far back as I can remember, it’s all I’ve ever wanted to do. As a kid, even before my dad brought home our first computer, my mind was filled with game designs that I would dream about, draw out on my homework, or play out with my friends. I suppose it wasn’t until I opened up QBasic at about 12 years old, though, that things started to get serious.

There it was… NIBBLES.BAS. A game hidden in the depths of our computer. I double-clicked that sucker faster than you can say “I’m bored and the Internet doesn’t exist yet". A program called QBasic opened up and then Nibbles started playing. When I was done, I quit the game, expecting to go back to Windows, but what to my wondering eyes should appear, but the full source code to the game I just played! Up until that point, I didn’t have much of a concept of what it took to make a game. I knew they were “programmed", but after examining a few of my game’s EXE files in notepad, I figured I could never learn how to write that stuff. But here it was—a whole game, with the stuff that made it run being very very readable. My jaw dropped and a chill ran up my spine as I realized what this meant. It was all possible. I was staring at the tools I needed to make my dreams come true… My destiny had been laid out in front of me in plain sight that day.

I spent the next few years learning QBasic and making some awesome little games and programs. Once the Internet came around, I even learned some web design stuff to start a website where I could host my games for download and market them. One program I made (a painting tool for QBasic game developers) even sold a single copy! Was I proud? Sure I was. Before my first real job, I had made money selling software. Sure, I might have only made a whole fifteen dollars, but I was having a ton of fun programming these things, and I was learning a lot as I went along. Was I happy? Not exactly. I was having fun, but I was reaching some obvious limitations in QBasic. Even with a new and beefy 300MHz computer, the performance I was getting in QBasic just wasn’t enough to compete with the stuff I was seeing released by the big companies. I took some classes in C++ and read lots of game programming books, but once I started working and going to school, it was just too much for me.

I did, however, develop a taste for web development along the way, which is good because that was starting to become a rather lucrative field to go into. So I put my dreams on hold and focused on this web design stuff—hoping I would someday be able to start a website that would afford me the time and money I needed to focus on game development again.

Flash forward to 2008. After many jobs and a few failed businesses, I now work 40 hours a week doing web development from home. I have an awesome girlfriend. My life, as a whole, is pretty great! Most importantly, though, I now have the time to get back into fulfilling my game development dreams—and that’s exactly what I’ve been doing.

The hardest part I was finding about game development nowadays is doing 3D graphics. I don’t have such an extensive math background, and all the books on the subject didn’t get me very far. I could learn how to render a 3D teapot in realtime using directx or opengl, but as far as something practical goes? Nothing.

… until I found ogre. Ogre (Object-Oriented Graphics Rendering Engine) is an open source 3D rendering API that wraps all the complex directx/opengl code into an easy-to-use, cross-platform, object-oriented API. It even has a built in scene graph, and supports pretty much any cutting-edge rendering feature you can think of. This is stuff that’s essential if you realistically plan on developing a game, but stuff that would take one person working a few hours a day (like me) years to figure out and implement. By the time that preliminary stuff was done, I would already be years behind the competition… and that’s only if I didn’t lose all my motivation doing all that boring stuff. But couple Ogre together with open-source APIs for sound, physics, input, etc., and you’ve got yourself the building blocks of complete game engine just begging to be put together.

These APIs are like today’s QBasic for me. I look at them and (with my now matured and experienced eyes) I really do see the tools I need to make my dreams come true. The journey will be long and hard, but I now have everything I need to begin.

So how far am I? Well, I had already started writing some design documents for a couple game ideas. One was an online puzzle game, and the other an action/adventure game. I decided the puzzle game was the obvious choice for my first project, so that’s what I’m keeping in mind as I trudge through the construction of my game engine.

The engine itself is coming along slowly but surely. The “slowly” part is mostly because I’m really thinking through how everything should be organized and making sure I do everything “right". Of course, there is no “right” way to make a game engine, but there are certainly wrong ways and there are certainly proven techniques and approaches that others in the industry use. I want to make sure this engine is something that will be easily re-usable for future projects, and something that’s logical enough for other programmers to understand (in case I bring on extra help later).

Ogre is in there for the graphics system, and OIS is in there for input, but I’m still deciding on sound, physics, and networking APIs. That’s all been put on hold while I come up with the most logical and organized architecture I can model… and I think I’ll save that for my next post!

I’m finally getting back into game development—and in a bigger way than I have before. I’m actually learning a 3D rendering API and coming up with a programming architecture using fairly new, likely to be industry standard concepts. In other words, I’m starting from scratch, thinking ahead, and doing things in a logical way from square one. It’s making the initial development a little harder, but the payoff will be huge. I really feel like I’m laying the groundwork for many successful projects to come. It’s a ton of work, and this is just the beginning… but this is my dream—and I’ve never felt more excited or prepared for the challenges ahead.

Therefore, I decided it was time to start a blog to chronicle my game development journey. Not only will this help me solve problems by looking back at what I’ve done before, but it will give me the much needed motivation to keep going when things get rough—and things will get rough. Who knows, it might even serve as a roadmap to help me decide where to go next when I’ve lost my way.

So welcome to you, visitor who’s interested in my perils. Perhaps you share my interests, perhaps you share my hardships, or perhaps I’ve even managed to write something insightful here that got dugg a thousand times. Whatever brought you here, I hope you’ll benefit from my musings as much as I will.

I also might include the occasional entry about things in my personal life, but I’ll try to keep those to a minimum and hopefully at least technology/game related. Tune in next time when I get this blog up to date on where the project’s at!