VectorStorm Blog

Just for fun, here’s a very early screenshot of my MMORPG game project.  Apologies for the lack of anything really visible in it;  almost all the work thus far has been behind the scenes.

This is a somewhat zoomed in view of the map screen.  The toolbars and suchlike haven’t been filled in yet, but will eventually provide a number of controls.  The user can drag with their right mouse button to scroll around the map, and use the mouse wheel to zoom from a full-world map to a close-up view of the action.  Again, this is a bit like World of Warcraft’s map, but with smooth zooming control.

Each square you see in this view is a “zone”, which would be about a five minute trek from one side to the other.  Theoretically, if this was a full-on commercial MMORPG, each zone would be simulated on its own server to manage player load across the world.  In practice, I’m sure that I won’t actually have to worry about things like that.  :)

Not visible here, I’m using the “Meat” sprite from Muncher’s Labyrinth for players.  But that’s probably only temporary.  :)

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.