Technology Selection: PopCap Games Framework
It’s time for me to start posting more news on my in-development game. I’ll start with the framework for the whole thing: the PopCap Games Framework.
Here are the highlights:
- It’s all in C++. Many otherwise great offerings, such as the Torque Game Builder, rely heavily on custom scripting languages. Tools for C++ development are far more advanced that the tools for most other languages. I’ve found that strong tools can easily outweigh any gains from language advancements.
- Easy to learn. The API is clean and simple. Six quick tutorials teach you most of what you need to know.
- Full-featured. It’s more than just a few routines for drawing images. It has a simple XML-based resource system, flexible sound playback, widgets, and more.
- Proven. A lot of work on a software framework only happens once you deploy it in the real world. PopCap’s had to deal with a large user base with a lot of quirky PCs.
Here are PopCap’s biggest flaws:
- PC only. They’ve separated out their DirectX calls nicely, so in theory I should be able to write an OpenGL implementation. It’s probably a lot more work than it seems.
- No networking. I’ll need to find and integrate another networking library if I want any online aspects. Since there’s no client-server architecture in place, I can forget about real time multiplayer.
There were several competitors, the foremost of them PTK. It’s cross-platform, and supports some impressive titles. It’s also a little lower level than PopCap, and lacks features such as widgets.
Despite its shortcomings, I’m very happy with the PopCap Framework so far. Of all the options, PopCap made it easiest to get started making my game.
November 10th, 2006 at 6:51 am
Initially, my first concern was with the license, but it looks like a standard attribution style, with a clause for protecting their trademark. Not terribly restrictive.
As far as the networking thing goes, I sort of understand why they wouldn’t bother. Most games are going to be pretty specific with their networking code as far as the application-level protocol goes, so provided you’re sticking to standard TCP/IP, an evening futzing around with Beej’s Networking Guide will probably serve you better than learning somebody’s abstraction.
It would’ve been nice if they’d targetted OpenGL rather than DirectX, as they’re serving as an abstraction layer anyhow, right?
November 13th, 2006 at 9:11 pm
Good points. The license looked good to me, but perhaps I should pay a bit more attention before writing my entire game.
I’ll find out more about networking issues eventually. I’m pretty clueless on that front right now.
Yeah, the DirectX choice over OpenGL is kind of tough to fathom. DirectX is faster to support the latest video card features, but I’m not writing a 2D game to target people with Windows Vista and $600 video cards.
November 14th, 2006 at 2:23 am
well, don’t wait too long on thinking about the networking stuff. It’s easier to stub out some hooks now than try to bolt multiplayer on later. Seriously, even an evening spent playing around wth Beej’s Networking Guide is going to help, because you’ll need to think a little about how asynchronous events are going to fit into your main event loop. Wouldn’t be a bad time to brush up on threads, either. A little planning goes a long way.
If you’re really feeling nutty, KDE has a UML editor (not too far off from Rational Rose) called Umbrello It’s currently *nix only, but if you decide to turn your old backup box into a staging server, you can get an X server via cygwin. Maybe that’s more process than you actually want to apply to your game, but if you find yourself working in short bursts, you can at least record some of your ideas without having to relearn or remember whatever you were working on last time.
My 1.16 cents (after taxes)