VectorStorm Blog

After some discussion over on the forums, I’ve finally implemented the new road placement system for version 1.1.  Roads now pass through “Road Nodes”, which serve as anchors for splines.  Each “road node” can have up to four roads attached to it.  This means that in 1.1, you’ll be able to have nicely curved roads and branching roads, and it’s easy to specify exactly the path that roads should travel, instead of always being approximately straight lines between destinations.

There’s still a little work to be done in the interface (the road node graphics need to change their scale based upon the current zoom level, so they’re always visible but not obtrusive, adventurers need to actually use the nodes, etc).. but placement is working in my development branch, and I’m pretty happy with the behaviour.

For the curious, in this screenshot, there are six road nodes.  Though I could have done it with just five.  And those green dots are monsters (we’re zoomed too far out to see more detail than just dots)

For those who’ve been bitten by the “Preference value too high!” crash, I’ve finally found the cause of that, and have uploaded a fixed version of MMORPG Tycoon;  it’s 1.0.16, available from the link in the sidebar.

You may need to delete your old Data/Preferences/MMORPG.prefs file, if you still have trouble with the new version.

So I see that Geometry Wars 2 has been released on XBox Live Arcade.  I kind of have to acknowledge it as it’s one of the few other glowy vector graphic games out there right now.  And wow, they’ve really nailed the glowy vector thing in a big way.

Granted, in this revision they’re a bit less vector than they’ve appeared to be in the past;  lots of things have been added which are obviously textures and there are plenty of curved lines (which usually aren’t present in old-school vector graphic games), but the overall look is still very nice.

So in reaction to Geometry Wars 2’s beautiful glows, I’ve been revisiting the glow shader used by VectorStorm games.  Here’s a shot of the current map screen in the in-development MMORPG Tycoon 1.1, using my updated glow shader.  For those who’ve played MMORPG Tycoon, you’ll notice a few interface niceties already;  textual level ranges have vanished at this sort of zoom level and in fact, similarly-zoned regions are being drawn as just one larger region, when we’re zoomed this far out.  Also, there’s a cute little compass rose in the northwest corner of the map.  But really, this is showing off the new, brighter, softer, and much more accurate VectorStorm glow shader. I’m pretty pleased with it.

And it doesn’t even cost much more GPU time.  In fact, the optimisations I made to the code probably actually make it cheaper, on most video cards.  (Although I’ll confess that I haven’t actually profiled it)

With bare minutes to spare, I’ve finished Robot Finds Ice Cream!  Go grab it from the sidebar.

I’m vaguely pleased with how it came out, though I do wish I’d had more time to spend with it.  You’ll notice that it feels a little more rushed than the previous GiaW games;  that shows up mostly in the inconsistant art style, its lack of a main menu, and the rather small number of levels (I’d have been happier if there were about fifteen of them).  But hey, what do you want for something that’s free and both designed and implemented in under a week?

And now I’m going to post this, before the clock turns over to midnight.  Hope you all enjoy! 

I’ve added a simple set of forums to the site; logins are shared between this blog and the forum.

Casual comments here on the blog still only require an e-mail address, but you’ll have to actually create an account to post to the forums.  Sorry about that;  it’s a requirement of the forum software I’m using.

Anyhow, I’m closing off comments to the static game pages to keep them from becoming any more ridiculously lengthy, so we can have some proper threaded discussions now, and hopefully make those static pages load a little faster.

Check out the new forums.  If you’re having trouble with a VectorStorm game, or want to make comments or suggestions, or just make idle chatter with like-minded individuals, then this is the new place to do it!

So the latest TIGSource competition has finally been unveiled: Procedural Content Generation. The competition starts today (or yesterday, depending on which part of the world you’re in), and finishes in four weeks time; on June 2nd.

I’ve never entered one of the TIGSource competitions before, as I usually found out about them when people started announcing the winners of competitions which had just finished, but I managed to catch this one in time, and I’m entering it. So I guess this is the start of my very first Game-in-Four-Weeks.

I think I’m going to be implementing my as-yet-unnamed MMORPG concept, which I mentioned a week or two ago. Really, four weeks feels like an eternity.. so I’m going to keep myself productive by trying to get a basic gameplay proof of concept up and running in the first week, just as though it was a regular “Game in a Week” project, and then spend the rest of the time on improvements and tutorials and polishing and suchlike. Wish me luck!

A quick note on what’s going on with the VectorStorm engine.

I’m midway through converting VectorStorm into a dll/framework. Once this is completed, I’ll be switching VectorStorm over to a different, more permissive license; most likely the LGPL, as that would make our license compatible with that used by SDL and SDL_mixer. This would have the benefit that I could theoretically bundle all those libraries together into a single .dll, which would make it much easier to start up a new project, to avoid version conflicts between the various libraries, and would really cut down on the dll clutter in my games.

Additionally, there are now “VS_VectorStorm.h” and “VS_VectorStorm_Debug.h” files, which are intended to be used as prefix files;  they include every header in VectorStorm, so there’s no more micromanagement of which headers you need to include, and it no longer requires explicitly adding every VectorStorm directory to your game’s header search path.  All in all, it’s just intended to make VectorStorm a heap easier to use.

I already have this bundling working in the Mac build; now I just need to get it going under Win32.

But I am banging my head against one problem. My singleton template class uses a static variable to store the pointer to the single instance of each particular class. In the Mac build at least, this ends up meaning that the static variable is created both inside the framework and inside the game code, and which of the two variables your code ends up accessing is pretty much random. This can lead to some really difficult to debug bugs, where some code finds a class instance, and other code doesn’t.

It feels like there should be a simple fix for this, but I can’t for the life of me figure out what it is, and Google isn’t being much help.

If anybody happens know the solve for this, I’d be thrilled to hear about it!

So last night I downloaded and spent a little time playing Lost Cities on XBox Live Arcade. Lost Cities is a card game, and I’m a big fan of board/card/etc. games, and really enjoy them when computerised, particularly when they use the computer to automate things which had been annoying without a computer. For example, scoring in Carcasonne is really painful and error-prone when you’re doing it manually, so having a video game version do it automatically is awesome.

So imagine my surprise when I realised that Lost Cities assumes the user has a high-definition screen, and that every pixel it draws is going to actually be visible on the user’s screen. For those of us still using standard definition screens (I believe that we’re still the majority?) there’s a thing called the “safe zone”, which specifies the pixels which you can always assume will be visible on everyone’s screen, no matter what sort of television they have. To find the “safe zone”, you basically just remove 10% of the width and the height of the screen; the middle bit remaining is the “safe zone”; the part that you can safely use to display important information. Outside that might be lost under the frame of the television.

So I was all looking forward to Lost Cities, only to discover that its font was needlessly small, making it very difficult to read on my screen, and then to discover that important information (for example, my score) is apparently being displayed inside the safe zone, and cannot be seen at all on my television.

Ever wonder why virtually every console game out there floats your health bar and other data on top of the game image, a short distance in from the corner of the screen, whereas PC games usually use a solid bar at the very edge of the screen to show that information? It’s the safe frame; we don’t actually know where the edges of the screen are going to be on console games, and so we have to just put the information somewhere away from the edges of the screen so we can be certain that everyone will be able to see it, whereas PC monitors don’t have that problem.

Now, the safe zone has been around for an awfully long time. Anybody who’s ever developed a game for a console older than the latest crop will already know all about it. Additionally, anyone who’s worked on television broadcasts knows about it as well. Everything from the nightly news to the latest Wii games all obey the safe zone, and do not put important text or other information at the edges of the screen. Almost all of the next-gen full-price games are built with the safe zone in mind. But a lot of new XBox Live Arcade games are being written by people who have only worked on the PC before, and many of these companies seem to assume that a television display is basically like a PC display, when it really isn’t.

So I was all annoyed at this, when it suddenly occurred to me that none of my VectorStorm games obey the safe frame. And what’s worse, the VectorStorm engine doesn’t even provide any debug tools for showing where the safe frame actually is. Now granted, VectorStorm currently only runs on normal computers which will have normal monitors which will display the whole video image. But who knows; someday I might port VectorStorm over to the XBox 360 or PS3 or something else (stop looking at me like that; it could happen! ), and at that point, none of the games I’ve written for it would actually play nicely on standard def screens.

So here’s a big TODO for me: Add a debug feature to the core VectorStorm engine, to draw the borders of the safe zone to the screen.  This will be useful when developing games, so that I can easily lay things out relative to the safe zone and keep my informational displays (score, lives left, etc) safely on screen just in case I someday port the thing over to a real game console.

I’ve now put a first pass implementation of very basic networking into the core VectorStorm engine.  This is only a very, very rudimentary implementation (and will currently only work under UNIX operating systems;  I need to load it up under Windows and add the necessary extra WinSock calls.  Shouldn’t take but a few minutes).

Here’s a screenshot of the Testbed game, which talks to a special server I was running on vectorstorm.org for a short while.  It’s not doing anything fancy, but it’s passing data back and forth.  Network packets are constructed using memStores (which were already being stored in network byte order, in preparation for this), and you use one or more vsNetClients and a vsSocket to specify where packets should be delivered.

Eventually, I’ll build cryptography in.  But this was a nice first step.  And it’s in the public SVN repository now. 

In other news, I’ve also added what I call “String Mode” to the input system.  Put the input system into “String Mode”, and the keyboard will stop acting as an emulated gamepad, but will instead construct a text string as though you were typing into a text editor.  This is in preparation for TIG’s all-but-inevitable “Procedural” competition, where I’ll want to accept a string input by the player in order to initialise my world generation algorithm.  This also is now in the public SVN repository.  (Though it’s kind of ugly;  right now it only supports basic alphanumerics and spaces.  No punctuation or unicode characters.)

The Game-in-a-Week version of Nicholas Spratt (the downloadable one available from the sidebar) had a reasonably simple murder timeline generation system.  Basically, it picked a murderer and someone to be murdered, and picked a time during the day when the murder would be committed, then “locked” the room in that moment so that no other characters could blunder in and disturb the action.  It then picked an earlier time for the murderer to be alone in the room with the murder weapon, and locked the room so that no one else could be in the study at that time, either.  And then it used a pseudo-random system to have the remaining characters wander about between the game’s 24 turns, and recorded what everyone saw, and who was in the room with them.  (There was also a 2% chance of a mistaken memory, where a particular guest wouldn’t notice someone or would remember the wrong person, etc)

And that’s basically all there was to it.

For Spratt 2.0, I’m thinking about dramatically expanding on this.  Here’s the list of changes I want to make:

• Give all guests a randomly selected motive for wanting to murder the victim.  This is just for flavour.
• Randomise the mansion floorplan.  At least one room per guest (including the victim).
• Add doors to the mansion, to show how to move from room to room and from room to hallway.  Doors may be open or closed.
• Add multiple possible murder weapons.  Probably one murder weapon per mansion room
• Change the murder timeline from using 15-minute timeslices to 5-second timeslices, for finer grained accuracy on guest vs guest visibility.  Guest memories remain labelled according to 15-minute timeslices, but multiple things can now happen within a single timeslice.  Guests may move only a single grid space per five second timeslice.  Two or more guests may occupy the same grid space as long as all or all but one are still walking.
• When guests are in a hallway, they can see any other guest within line of sight, including those on the other sides of open doors.
• Add collision to the mansion walls, and let the player walk around inside the mansion.  one guest will be in each room, either stationary or pacing.  Talking to a living guest will let you examine their memories as in the GiaW version.  “Talking” to the dead guest will provide details about how he died (gunshot wound, bruising, etc, to help the player determine the murder weapon).
• Grandfather clock in the entrance hall, so those in the entrance hall will know the exact time, while others only know the last 15 minute bell that has chimed.  This is probably just flavour;  probably won’t matter to actually solving the mystery.
• Have two or more guests planning to perform the murder, and gather/return murder weapons, instead of only one guest doing this.
• Consider witnesses during the murder generation phase, and actually make sure that there are witnesses present to see particular key moments.  (Someone’s opportunity to get a murder weapon, etc.)