My last two posts have been mostly related to getting the business up and running. I still have a couple more of those, but today I thought I’d post about how I’m approaching the process of starting my first game.

Building a game isn’t easy; I know this. I’ve been doing this long enough now that I know how much work it takes to make a game, let alone a good one. So where does one begin? Well, with an idea. I started with a very abstract idea that I had. It’s a concept I’ve been kicking around in my head since I first started wanting to make video games, back in university. I’m not going to explain what it is just yet, you’ll have to wait a while before I’m ready to talk about specifics.

So, like I said, I had this idea. It was more of a concept, than a game idea, but I started keeping a journal. Every time I thought of some cool (or even mundane) idea that related to my original concept I would write it down. I’d also write down any idea for a game, or gameplay concept that occurred to me. My journal now contains sketches, diagrams, written ideas, gameplay concepts, and lots of terrible ideas for games that should never be made.

While I’ve been going through the process of doing all the company start-up, business stuff, I’ve been trying to collect my thoughts and ideas into something concrete. At the same time, I’ve been looking at various 2D games engines that are available for free, or on the cheap. Put these two tasks together and it’s prototype time!

“But, Owen,” you ask. “Why make a prototype?” My answer is simple: because I’ll be able to make a better game. Prototyping allows me to try game concepts and see if they work. It allows me to test my assumptions about what I think will be fun. It allows me to play with the game before I’ve invested so much time into it that I can’t afford to throw work away. The more prototyping I do up-front, the more time I can spend making I game I know will work later on. The idea is to spend no more than a week on the first prototype. I want a working game that I can play in that time so that I can start mucking around with ideas and gameplay choices. Once I have something I’m happy with, I’ll start over and start building the game “for real”. I may even have to go through several different prototypes before I’m happy, but in the end it will be worth it.

• Power of 2 Games (www.powerof2games.com) – The Power of 2 Games guys have a fantastic article on their site about their prototyping process.

Once I had decided what I wanted to do, I was able to come up with a list of requirements for the engine I would use to build my first prototype:

• The engine should be built for 2D and do it well, since I don’t need 3D for my first game
• I need to be able to tint textures
• I would like built-in support for animated textures
• Must have cross-platform support: at least Windows and Mac
• Free is best, but cheap is OK too
• Should have an active community of developers and developer forums
• Flexible enough that I can drop in other libraries (for things like audio, physics, or networking)

With all of this in mind, I looked at three engines as the most promising (there are lots of others out there, but these seem to be the three best that are designed around making 2D games):

1. PopCap Framework (developer.popcap.com) – I’ve played around with the framework before. It’s free! I found it extremely easy to set up and use. It’s C++, which is a huge plus. It supports software rendering as well as hardware rendering. You get access to the source code, which is a huge plus. The big problem: Windows only. There are developers in the community who have ported it to Mac and will port your game for you (for a fee), but this was a big down-side for me.
2. Torque Game Builder (www.garagegames.com) – I downloaded the trial of this and was able to build a simple falling blocks game in about 3 days (including the time it took me to learn how to use it). It’s extremely easy to use and very powerful. It’s cross-platform (Windows and Mac, but also supports Xbox 360 and WiiWare if you pay for the upgrades). However, it only supports hardware rendering, which is a problem for some casual games portal sites. It doesn’t support C++, they use their own scripting language. The script language is good, but it means it would be hard to port parts of your source code to another engine at a later date. The biggest problem is that an indie license is $250. This is still really cheap for an engine of this calibre, but it’s a consideration.
3. Playfirst SDK (developer.playfirst.com) – This is a C++ based engine. It’s free! It supports Windows, Mac, and web Active-X control. No access to source code, which is a big downside. I still haven’t figured out if it supports software rendering, so I need to dig a bit deeper.

In the end, I’ve decided to build my prototype using the Playfirst SDK (called Playground) as it basically does everything I need right out of the box. I’m about two days into prototyping and the API is pretty decent to work with. They have a neat system for handling sprites and their asset classes have built-in reference counting, which is handy. The interface is a little different from what I’m used to working with, but I’m starting to get comfortable with how things work. It’s been surprisingly easy to get some sprites drawing on the screen, doing some simple animations.

As the prototyping process continues, I’ll post further updates. For now, I think that’s enough; I need to get some actual coding done!

Owen

This entry was posted on Monday, July 28th, 2008 at 9:56 am and is filed under Design, Technical. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.