I just set up a message board for a client. There are at least 20 usable products out there: the awesome Forum Matrix solves that in a hurry. View a list of options pared down by your requirements, then view a list of the most important criteria to you (from a list of something like 50).

In this case, vBulletin was the winner. vBulletin is a very nice product, but the competition wasn’t nearly as strong as I’d anticipated after first viewing the size of the field. One similarly-priced solution has their demo offline until some time next year, with their site claiming it’s coming in October. phpBB has a lot of theoretical power from user-created mods, but they’re hit and miss (the file attachment mod is gold, but calendar options are lacking).

vBulletin was easy to install, has a great calendar, supports archiving, and is just extremely full-featured. It costs $160, which it quickly justifies when I compare its setup time with the work I spent on other solutions. People with different requirements might like phpBB or some other free option fine, though, so hit up that aforementioned matrix.

While brainstorming for Christmas gift ideas this year, Ruth came up with a great idea: design a fun (subject redacted– sorry, some recipients occasionally read this blog!) game for any friend and family who like (subject redacted).  What this gift has going for it:

• Covers a lot of people.  Game design, even for a small, non-professional game, is a lot of work.  Designing a game for just one person is probably more than we can take on during the holidays.  If you pick a design that covers a couple groups, though, you’ve taken a good chunk off that list.
• Cheap!  Christmas is way too expensive.  With the right game design, you can reduce your costs to some slick forms from VistaPrint, or even something entirely homemade.
• Personal.  With gifts like this, your lucky recipients will always remember you fondly as creative, strange, or both.  With a bit of luck, they’ll even enjoy the game!

Another reason this idea is so great is that it’s a way for someone like me to give creative gifts.  I don’t have to be able to sculpt, paint, or do anything else that requires an ounce of visual sense.

I’ll write more about the gift after the holidays.  Feel free to drop me a line if you’d like to hear about it sooner.

Recently, I started using these macros to use Java-style interfaces in my C++ code. They allow me to gain the advantages of interfaces, without the madness of multiple inheritance.

As I was soon reminded, though, using anything in C++ without a solid understanding of what’s going on under the hood leads to certain doom. My event broadcasters were broadcasting, my event listeners were listening, but the event would come along and no one would do anything with it. What was going wrong?

• When can two pointers to the same object be unequal?
• When can calling a virtual function on an object call a superclass’s version, even if that object has overridden it?
• When can a base class see a different “this” pointer than its descendant sees?

When you’re using multiple inheritance! It all makes perfect sense once you know how multiple inheritance is implemented, but at first I found it unintuitive that pFoo and pBar could be unequal in the following code (more complete example here):

FooBar fb;
Foo* pFoo = &fb;
Bar* pBar = &fb;

If you’re hazy on that, too, you may want to check out this excellent resource. It talks about how multiple inheritance is handled by the compiler, and when to use dynamic_cast. I spent a few hours reading over it and writing test cases. Armed with my new knowledge, I replaced a couple select typecasts with dynamic_cast, and now my events are playing happily.

I’m giving Akismet a go: it claims it’ll filter out all the spam for me, and I can shut off moderation. Comments should appear a lot more quickly now, without any getting lost in limbo for a couple weeks. Let me know if you have any trouble posting, or if you want to sell me any cheap Rolex+VI AGKrA super combo packages.

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.