VectorStorm Blog

So after a few hours of consideration, I’m really finding myself enchanted by the word “sophistication” from the topic. In particular, I have a vague mental image of the player playing as a very small man or a rodent or something, hopping along the heads of anonymous people at an elegant evening soiree.

However, in order to do such a thing, I realised that I’ll need an editor; something like the game design I’m considering would be heavily polygon based and would require a certain amount of artistic flair, which just isn’t likely to come through using my traditional text-editor-created ‘.vec’ files.

So I’ve started learning Blender, and wrote a quick and dirty importer for VectorStorm to read in extremely basic WaveFront (.obj) format files. The screenshot above is the very first thing VectorStorm rendered from an .obj file. (Well, the very first thing that it rendered correctly. It was all very strange and glitchy until I worked out that WaveFront numbers its vertices from 1 rather than from 0.)

I don’t know whether I’ll keep moving along in the ‘dinner party’ direction tomorrow, or whether I’ll be drawn in a different direction. But either way, having a nice importer from a real graphics app can only help out!

The book this week is “The Complete Home Confectioner” by Hilary Walden. It’s copyrighted 1986 by Quarto Publishing Ltd.

This is the book that I used to learn how to make toffee, butterscotch, fudge, and other such candies, and is on extremely extended loan from a friend (and I really ought to get around to returning it!)

But since I still have it, down it came from the shelf, and I randomly opened it to page 76, which happens to be the first page dealing with Jellies (I have a bitter feud with Turkish delight, which I have never managed to successfully create, despite literally dozens of attempts. Someday I will give in and just use gelatine instead of trying to use the traditional recipes which use corn starch).

In any case, the first complete sentence on page 76 is:

“The diversity of jellied sweets ranges from the sparkling simplicity of fruit jellies to the sophistication of creme de menthe, from the Eastern promise of Turkish delight, to cloud-like marshmallows.”

As always, some initial conjectures: Immediately obvious good words to use as inspiration here are: “Fruit”, “Jellies”, “Cloud”, and “Marshmallows”. I rejected the word “promise” back on Petition Damsel (actually, it was “pledge” — edit) and so maybe I should attempt to work that one in this time, somehow.

Other, less obvious but still potentially useful words might be “ranges” (if I wanted to do something boring with guns, or perhaps invent some sort of cooking game), or possibly “sophistication”; set up a game to be played at a fashionable dinner party.

But I’ll confess that right this minute, I’m most drawn by “cloud”. Maybe leaping from cloud to cloud, or soaring amongst the clouds, or being a cloud yourself.

Maybe you need to rain on someone.

Anyhow, that’s all the design consideration that I’m allowing myself today. Real gameplay designing starts tomorrow! :)

I have a bad habit of doing this; A game is coming out that I’m really looking forward to playing. And whereas others gush excitedly on forums or conduct interviews about the upcoming game, I usually say, “Well gosh, I could write that myself.”

It’s what happened with StarShot (loosely based upon Boom Boom Rocket, which had suffered well over six months delay in its Australian release, compared to the rest of the world), it happened with my original GemStorm (based upon the then-brand-new Bejeweled, which wasn’t available for my operating system), and it had happened many other times in the past.

And now it’s happened with Petri Purho’s brilliant Crayon Physics. Yes, everyone’s making blatant clones of Crayon Physics these days, and now I’m just as guilty of it as everyone else. So instead of finishing off the Space Maze Express testbed today, I instead spent a few hours putting together this little prototype, to really put some pressure onto my physics library translation layer. And I think it was totally worthwhile; Space Maze Express wouldn’t have forced me to add nearly this many features to the VectorStorm collision/physics system, or put nearly as much strain onto the Box2D engine.

Strictly speaking, Vector Physics (as the new game is called) isn’t really a game; it’s just a desktop toy. You can create static objects, dynamic objects, and ropes just by drawing with your mouse. You can delete unwanted objects by right-clicking on them (or just letting them fall off the bottom of the screen).

I’ll confess that it’s still a little bit glitchy (in that objects will sometimes interpenetrate), but I’m not planning to work on Vector Physics any longer; it has served its development purpose.

And I can honestly say that after doing this basic physics implementation, I can now totally understand why Crayon Physics Deluxe is taking so much time to complete! And I’m still anxiously waiting to be able to pre-order. :)

If you’d like to have a play with Vector Physics, there are updated builds of the VectorStorm test harness games available from the “VectorStorm Test Games” link in the column on the right. You want build 168 or later.

This post is going to be extremely boring to everyone who’s not me, but I wanted to quickly express pleasure with a bit of VectorStorm restructuring I’ve been doing today. So apologies to everyone in advance for the technical code discussion that follows. Feel free to ignore the remainder of this post, and I’ll talk more about game design issues tomorrow. ;)

I’ve been extremely unhappy with the Box2D integration into VectorStorm ever since I started it, but hadn’t really been able to figure out how to fix it. I always ended up with Box2D-specific code in game code, which effectively ties individual games directly to the Box2D game engine, but I’ve finally figured out how to encapsulate Box2D (or any other physics engine) into an abstraction layer.

Just like VectorStorm isolates the OpenGL rendering from game code via the vsDisplayList class, so too does it now isolate Box2D from game code via the colObject class (todo: possibly rename this class). This still needs a lot more work; in particular, joints still require implementation within the translation layer. But moving in this direction makes me much happier, since it gives VectorStorm more flexibility. That is, in the same way that we could switch to DirectX or any other rendering framework merely by modifying one or two source files, we could just as easily switch to APE or another physics engine simply by modifying one or two files, without ever needing to touch the dozens or hundreds of files of game code.

And of course, the fewer places where I need to convert vsVector2Ds into b2Vec2s and back, the better. ;)

I’ve noticed that when programmers get a new tool, like, say, a 2D physics engine, they tend to start creating games which are basically example apps for the new tool, with a constraint or a goal condition attached. So with physics engines, it’s not at all unusual to see these games become about moving boxes or circles around, either using the mouse or via an elaborately physics-simulated device of some sort.

There’s nothing wrong with that, of course, as long as the game’s fun.

But on reflection, those really aren’t the sorts of game I want to spend my time creating. The world already has enough “Behold, I have physics!” games without my adding to them. And it’s occurred to me that that’s exactly what Space Maze Express is, at its heart; it’s just another “move boxes around with physics” game.

I’m still going to complete it, as it’ll still be a great testbed for engine physics support. But in the same way that I promised myself that the next game I made wouldn’t have a time limit, I’m also going to try to avoid making “look, it’s physics!” games in the future. :)

So I’ll be doing another Game in a Week next week. And I guarantee that the goal of that game will not be to move a box from point A to point B. :)