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.

Whoops, forgot to mention earlier;  I’ve updated the Win32 VectorStorm binary build with the Space Maze Express gameplay prototype.  It also has the overlay demo (mentioned in an earlier post) in the Testbed game slot.

So if you feel like experimenting with lifting boxes using only an Asteroids ship, there ya go. 

It’s pretty easy to divide all video games into two groups. “Good” vs. “bad”, for example, is a fairly common (albeit subjective) division. And people like dividing things on that axis, so it’ll probably always be the main one, even if nobody can agree on precisely which games belong in each camp.

But there are other, more descriptive ways to categorise games.

One that I’ve been thinking about a lot recently, during my creation of Game in a Week games is the difference between process-based and content-based games. These days, nearly all professional video games are content-based, whereas a high proportion of independent and freeware video games are process-based. Virtually all traditional tabletop games are process-based, but some newer tabletop games are content-based. Here’s what I mean by these terms:

Continue reading “Two types of game”

So there’s no maze yet, but I’m getting there.

This is a screenshot of an initial grappling testbed.  That’s the Asteroids ship transplanted into a world with gravity, and a rope attached.  If the rope’s end touches a box (or any non-static physics object, actually), it will automatically attach, and the player can fly it around.   Press the ‘A’ button to release the object.  As an initial testbed, it’s working pretty well, I think.

A key point in the implementation here is that the rope changes color, to show you whether or not it has connected to something.  Without that, it can sometimes be difficult to tell whether or not it’s managed to grab the object you want it to.

So I’ve decided not to do a Game in a Week this week. Instead, I’m going to implement a third test harness game to be included in the main VectorStorm distribution.

Continue reading “Test Harness in a Week”

That last screenshot was pretty subtle. Here’s one that’s downright garish.

These are three boxes, rendered using a single overlay. Each box is rendered as ‘white’ in VectorStorm, but they’re all sitting under a single overlay that acts as a gradient from red to green, so the final colors that show on screen are between red and green, depending on locations of the boxes.

As the boxes move and spin, they move beneath the color overlay as you would expect them to; the color is stationary on the screen as though it was a sheet of cellophane laid over it, rather than moving along with the boxes.

Note that in this shot the gradient doesn’t line up precisely between the two larger boxes, since I’m rendering the overlay by calculating the correct colour at each vertex, instead of per-pixel. I’ll eventually write a fragment shader to calculate this effect correctly per pixel, which will probably actually turn out to be even faster. But for now, this will do.