VectorStorm Blog

I had to add a little extra note..  one of my favourite entries in the TIGSource Retro Demake competition is this demake of Sly Cooper into an LCD “Game & Watch”-style game:  Thieving Raccoon.

I love how Shoo has captured the core gameplay of Sly Cooper, and rendered it down into such a minimal form.  If you liked Sly Cooper, you owe it to yourself to go have a look and a smile.  No download required, it’s Flash! 

Well, it’s happened again, TIGSource is hosting another interesting competition.  Folks here will remember that I started MMORPG Tycoon as an entry for their last competition, the “Procedural Generation” competition.

This new competition is “Bootleg Demakes”;  basically selecting a game and creating a bootleg version of it for older hardware.  Full details and rules are here.  I’ve had a few fun ideas for it, but I don’t think I’ll actually be entering this one;  there’s too much stuff to do on MMORPG Tycoon, and I already took one break from MMORPG Tycoon, to make “Robot Finds Ice Cream”.  I don’t think I could justify taking another big break.  But there’s a lot of exciting stuff happening in this contest.

My vector-loving heart is absolutely in love with VipeÜt (a demake of WipeOut, to the Vectrex console).  I especially love that it’s simulating the bright spots where the vector hardware’s display gun accelerates.  Someday I’ll add that sort of fine touch to VectorStorm.

Anyhow, back on the topic of MMORPG Tycoon, there’s been a lot of progress recently, but there’s still a long way to go before I reach 1.1!  I’ve got a thread with progress reports running over on the forums.  Check it out, if you’re interested in how stuff is moving along.

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.