VectorStorm Blog

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.)

Oh well. The WaveFront (.obj) file format looked ideal yesterday; simple, straight-forward, ASCII-based.. but it doesn’t support object hierarchies, which pretty much limits its utility for me. It means that if I wanted to create a character with multiple joints, I can’t build them all together and make a single export; I’d have to build each piece separately, centered on the world origin, and then manually piece them back together again in code.

It’s too bad.. other than that, WaveFront supported everything I wanted, including both polygon and vector definitions, basic materials, etc.

I still like the dinner party idea, but I’m now thinking that it’s a little too ambitious to realise this week; there’s too much engine work that would be required to put it together well (primarily to do with writing an importer to actually get data into the game). I’ll come back to it later on. Perhaps as ‘Game in a Week #4′, or something.

So I’m now back to thinking about the other possible game topics, clouds especially. I have this vague notion about slamming clouds together to make them rain.. but don’t really know whether you’d do this using a “pool”-style interface, or by flying a plane around and shooting them with little bullets to push them around, or whether there’s some other method to use.. and I don’t have a very strong idea about why you’d want the clouds to rain, exactly. Perhaps the goal of each level is to make all the clouds give up all their water. Could call the game “Drought Relief” or somesuch.

But I’m not really convinced by that idea; I’m going to have to keep mulling it over, and hope to come up with something brilliant in the next day or two.

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!

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.

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”

So one thing that I’ve learned from doing all these vector graphic games is that the black background is really tiresome after a while. Your screenshots end up looking dull and lifeless, and.. well.. a little monochromatic.

In an effort to gently improve the visual appeal of VectorStorm games, I’ve added a new feature to the engine. Back in the early days of video games, many coin-op games pasted bits of cellophane over portions of their screen, to make their games appear to be in colour, even though the graphics underneath were rendered entirely in white.

I have added to VectorStorm the ability to specify an overlay which works in exactly this way. There may only be one overlay at a time, and it cannot change in the middle of a drawing operation, but otherwise, the sky’s the limit. Overlays may either be a solid color, or may be a linear gradient (I plan to add circular gradients in the future). The picture of StarShot here is using a gradient overlay, to give a gentle ramp of color to its background. It’s very subtle in this case, but makes the scene look much more alive and interesting than the flat black backdrop that was used before.

I haven’t updated the binary builds with this change yet, as there’s still some more work to be done on it before it’s really ready for public consumption. But for those of you using the subversion repository, the code is in there as of revision 151.

So Muncher’s Labyrinth finally convinced me that while physics in games is very cool, it’s not really something that I’m good at implementing, and so for the last few days, I’ve been out looking at various existing physics libraries which I might be able to integrate into VectorStorm, rather than spend all my time trying to teach myself physics code, when I’d rather be making games.

The biggest option on the list is Box2D, a fantastic collision and physics solver (that is capable of far, far more than is visible in the screenshot above), and so I’ve spent the past hour or two getting it to run inside VectorStorm. The screenshot here is using a temporary ‘testbed sprite’ class that’s just a proof of concept of how a VectorStorm vsSprite might be linked to a Box2D b2Body.. but it needs an awful lot more work before it’s really as seamless as I’d like!

For anyone who’d really like to look at it in the VectorStorm world, there’s an updated Win32 binary build available here (you want build 148); the demo shown here is in the “Testbed” game mode from the main menu. Use the left analog stick (or arrow keys) to move the large solid block around, and the ‘A’ gamepad button (or the space bar) to reset all 300 blocks. But if you want to see cool physics stuff, the demos available from the Box2D site show off the system far better than this little proof-of-concept demo!

So one of the things I realised from Muncher’s Labyrinth is that even though these games are relatively simple, I can still get far too many objects inside the collision system to run at realtime (this is the reason why the blood and other particles in Muncher’s don’t collide against the walls of the maze).

To fix this, I’ve been implementing space partitioning within the collision system, so that only objects near other objects actually perform collision testing.  It’s about 3/4 implemented now, and is already fast enough to allow me to turn on world collisions for the Muncher’s particles.

(TODO:  I need to stop developing features inside Muncher’s;  I need to make a collision-heavy large-world game inside the VectorStorm testbed.. perhaps I’ll bring the Maze class over, and write a quick and dirty space game to take place inside it, or something.)

I also have another graphic feature in the works;  it’s the next step beyond filled triangles, and it should be pretty cool, and very different from anything you’ve seen before, but still a natural progression from real-world vector graphic technology.