VectorStorm Blog

So I’ve got the difficult bit of my 3D cursor model working.  It works more or less as you’d expect;  it finds the spot that your (hidden) mouse cursor is hovering over, and zips off into the distance to point at that spot.  The current cursor behaviour is very much like that from the 1.1 development version of MMORPG Tycoon (so if you’ve played with that, you know the stretchy behaviour that’s being used here).  Of course, the very first thing I did with this new cursor was to point out the shading discontinuity which currently occurs on the border between world zones.  That’s been on my “to fix” list for an awfully long time, and I’ve still never gotten around to it.  Probably because it shouldn’t be difficult to fix, so it’s not a particularly interesting problem to work on.. but it’s always annoying to spot one of those when I’m thinking about taking a screenshot.  Maybe by putting it front stage like this, I’ll motivate myself to fix it sooner.

While I’m on the topic.. while I do like the visual interest generated by the foliage effect, it becomes totally invisible only twenty or thirty meters from the camera.  In this shot, the foliage effect is being rendered over absolutely everything in the scene (except for the hilltops in the far, far distance).. and you really don’t get any benefit from it beyond the two slopes in the foreground.  And the color scheme being used here really isn’t working for me.  I should really fix that up.

But I seem to have derailed myself.  The cursor picking is working, yay!  Now I just need to fix the visible cursor’s behaviour.  The real problem with the cursor’s current behaviour is that the cursor doesn’t try to orient itself to be visible from the camera;  that is, the cursor is still a flat 2D object, and depending on how you’ve been moving it around, it can quite easily end up with its flat side facing the camera.  It also tends to end up sitting directly on top of the ground;  really, I’d like to have it hover a short distance above the ground, and perhaps cast a shadow down onto the ground, to help really show where it is in the scene.  Finally, since it has to be visible so far off in the distance, the cursor model is actually about three meters long, which makes it absolutely massive on screen when you point at a surface which is near the camera.  So it’ll need to change its size dynamically, so that it won’t end up using half the screen when it’s pointing at the ground right in front of the camera.

So I’ve finished up with terrain for the moment;  I’m pretty happy with the system and the general look that I have now.  I found some pretty major optimisations today, which means that I’m now able to render the terrain with the ground clutter in less time than it took yesterday to draw just the terrain without the clutter.

(For any programmers in the audience, the key thing was to pay attention to memory access patterns;  if you have an array of 65,000 vertices arranged in 256 rows of 256 vertices each, then it’s faster to draw triangles along the rows than down the columns, because the rows are organised close to each other in memory, whereas the columns are spaced widely apart)

So I’m now pretty happy with the basic terrain system and rendering.  There’s still a lot of stuff I could do to tweak it, but I’m going to leave that sort of tuning until everything else is in place.  I believe that the next thing I’ll work on will be “picking”.. that is, determining what object or bit of heightmap is under the cursor.  This will be essential for tasks like letting the player place roads and buildings onto the undulating heightmap.  The system I had in place in MMORPG Tycoon 1.x only worked in 2D, and the picking I wrote for Lord was an ugly hack that wouldn’t scale to the size of worlds I’m using here — you could fit about 500  of the “Lord” maps into the screenshots which I’ve been showing;   Lord’s game world was only 60 x 60 vertices in size, after all.

Once picking is working, then I’ll start on placements;  placements of buildings, and of an interface to make terrain adjustments.  There’s so much stuff to implement! 

On a whim, I’ve tried a new look for the terrain I’m drawing.  This is substantially more expensive to draw, but it’s kind of cool-looking, I think.  If I decide to go in this visual direction, I’ll need to find a faster way to get a similar effect.

(Actually, this is hugely more expensive to draw than it should be;  it’s about double the geometry being rendered, but it’s taking about ten times as long to draw a frame, so I’m assuming that I’ve probably made a silly mistake somewhere in my rendering code)

Many years ago, a then-workmate of mine (are you reading this, Paul?  We should have lunch!) put forward the conjecture that virtually any video game could at its essence be distilled down into a single meta-game;  a game which he used to call “The Space Bar Game”.  And no, it had nothing to do with the Steve Meretzky graphic adventure game pictured here.  Our version of The Space Bar Game is only a theoretical game and has never actually been produced (at least, not  to my knowledge).  But the core thing is this:  the gameplay of The Space Bar Game is analogous to the gameplay of most (and maybe all) other video games out there.

The core gameplay of The Space Bar Game is this:

When you start up The Space Bar Game, the screen goes entirely black except for a giant numeral “0″, centered on the screen.  It doesn’t matter what color the number is drawn, but we usually assumed that it would be white, or some other neutral tone.

At this point, the game screen remains static and the game waits for player input.  The only inputs which the game recognises are the keyboard’s space bar, and whatever mechanism the operating system uses to quit the program (so alt-F4 on Win32, Command-Q on OS X, etc).  Of course, quitting the program in The Space Bar Game leads to the program exiting;  in our “this game is like a condensed version of every other game” analogy, this quitting behaviour is directly analogous to the same quitting behaviour of those other video games.  It’s not particularly interesting, but it is a legitimate thing which the player could do at almost any time.

As you might expect from the game’s title, the more interesting part of The Space Bar Game is the behaviour of the space bar.  For when the player presses the space bar, that giant numeral “0″ is replaced by a giant numeral “1″, and a happy “bling” sound is produced from the computer’s speakers.  At this point, the game screen again remains static, and the player is confronted by his second important gameplay decision:  will he quit the game now, or will he — dare he — press the space bar again?

Assuming that our player is an intrepid soul who chooses to continue, a hesitant, tremulous second press of the space bar produces a second happy “bling” sound, and a numeral “2″ appears on the screen in place of the “1″.  If he should continue pressing the space bar (bling! bling! bling!), the number displayed on screen continues to rise, until it eventually reaches ‘9′.

At this moment, our player is likely to pause expectantly, savoring the heady sense of anticipation over the threshhold he’s about to pass.  A deep breath. Slowly, expectantly, he presses the space bar one more time.

Bling!

The screen now reads “10″, and our player is presented with the same choice again;  quit, or press the space bar.

As I design, play, and think about video games, I find myself repeatedly being reminded of The Space Bar Game.  Once you know about it, you see it everywhere.  Crafting in World of Warcraft is just a paper-thin veneer over The Space Bar Game.  Experience points and equipment in virtually every RPG out there are The Space Bar Game, too.  It’s everywhere in RTSes and in games like Civilization and The Sims, and you could make a case for it even in FPSes; particularly the more modern ones which contain forms of skill advancement.  Do the thing you have to do to make the number bigger.  Bigger numbers are better, because bigger numbers are closer to even bigger numbers, and you want to reach the even bigger numbers, don’t you?

The Space Bar Game lays bare the question:  “Is 2 really better than 1?  And if so, why?”

And if you think that The Space Bar Game sounds like a perfectly tedious, boring little game (as I do), then.. why do people suddenly find it to be interesting when it’s had a coat of paint and been renamed to “levelling your fishing skill”?

I don’t have an answer.  But it bears thinking about.  Perhaps someday I’ll actually implement The Space Bar Game and put it up on the site;  it shouldn’t take any more than an hour or two to put together.  Maybe it wouldn’t be as bad as it sounds.  Maybe it’d even become hugely popular, and people would spend weeks and months of their lives trying to reach the top of the leaderboards.

But I’m not holding my breath.

Apologies; the following post is kind of technical.  Those who are uninterested in this sort of fiddly technical stuff can safely ignore this post;  it contains nothing at all relevant to game design. 

A bunch of work under the hood of the VectorStorm engine, the past few days.  It’s mostly invisible from game code, but produces better performance in general.

The first big change is that I’ve created a “vsCache” class, which can handle any sort of named, reference-counted game resource (textures, files, etc).  It’s trivial to create these for anything you might want to keep cached or otherwise reference-counted.  I’ve reworked both the “vsTexture” and “vsMaterial” systems to use the vsCache system.  The system is, generally, invisible from the game code;  you still create “vsTexture” and “vsMaterial” objects from code exactly as before, but now these objects look in the cache for existing data that they can piggy-back on top of, instead of always using up extra memory for something that might be a duplicate.  This basically means that if you create sixteen identical vsMaterials, you’re not actually storing sixteen copies of the data any more, but only one.

Building on with that change, materials can now be loaded from text data files.  To do that, you just create a vsMaterial, passing in the filename from which to load the material definition.  Again, if that file has already been loaded into the cache, the engine won’t actually load the file, but will use the one which had previously been loaded.

Finally, materials now compile themselves into OpenGL display lists, which really speeds up the process of changing from one material to another while rendering the scene.  (Still TODO is to consider trying to make the engine automatically batch materials together, so we don’t have to keep switching back and forth between materials.  With the number of polygons I’m pushing through with each material right now, this would probably be a lot more work than it’s worth, so I’m not going to do it unless something easy occurs to me)

I’ve also fixed a couple of engine bugs.  One annoying bug in particular involved how the file reading classes parsed unquoted strings, which caused some strings to vanish entirely before the game code had a chance to see them.  I’ve fixed this bug in each “Game in a Week” game since Robot Finds Ice Cream, and keep forgetting to migrate the fix back into the core VectorStorm engine code.  I’ll remember this time, I promise!

I’ve also added some facilities to make sure that singletons created by engine code are accessible by game code.  All I’ll say here is that the C++ standards are basically non-existant about how static templated data should work when statically linking libraries together (and this has caused problems for me in optimised OS X builds, in particular)..  so by pairing a hash table with RTTI information, I’ve created a mechanism to make the code do what I want it to, without relying on a particular behaviour from the compiler.  (This was a critical fix, in order to get the vsCaches working)

I’ve also fixed an infinite loop bug in the vsHashTable, if there was a hash table collision.  Silly bug, I’d overlooked it before just because I’ve never plugged enough data into one of these to make a collision happen, until now.  And to my knowledge, nobody’s actually played with that before;  it was just something I’d put together months ago while working on localisation support, which kind of fell by the wayside once the basics were implemented.

These engine upgrades and bug fixes are all in the MMORPG 2.0 codebase now;  they have not yet been ported back into the public VectorStorm engine repository.  But I’ll get to that within the next few weeks (once I’m really confident with them).

Also, I currently have about five essays about game design half-written.  I should really finish one or more of those, so I can stop boring people with these painfully technical code updates.