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.
Has anybody else noticed that both games I designed under crunch conditions (Petition Damsel and Muncher’s Labyrinth) have an invulnerable player and a time limit? I wonder what that says about me..
If you want to be technical, then Starshot also has no lives and a time limit. And while Asteroids does have traditional limited lives, I can’t really claim to have designed that one. 
So it’s self-challenge time: The next time I do a “Game in a Week” (maybe next week?), I’m not going to allow myself to design in a time limit. That probably means that either I’ll have a traditional “limited lives” concept, or there will be no enforced “end” to the game, depending on what the game turns out to be. But I want to keep myself from getting stuck in the “the game arbitrarily ends after five minutes” rut.
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.
I’ve just updated Win32 and OSX builds of the VectorStorm test games and Muncher’s Labyrinth, to support configurable gamepads. (Including most of the “Stage two” features I mentioned before).
As it turns out, SDL doesn’t provide support for the ‘hotplug’ feature I wanted to implement, so I had to drop that. Hopefully it’ll be included in the SDL 1.3 series, when that eventuates.
So I borrowed a couple of gamepads from various friends, and have been spending the morning fixing VectorStorm’s gamepad support, and have reached what I consider to be “stage one” support.
“Stage one” support is that the system is set up correctly to work with an XBox 360 gamepad by default, and the Preferences game mode (or menu option, in the ‘Game in a Week’ standalone games) has a ‘Gamepad’ screen where you can configure the controls onto any gamepad controls you like. Note that your gamepad is calibrated at app startup time, so you might end up with miscalibrated joystick axes if you’re holding the joystick in a direction when the application starts up. This initial automatic calibration step was required in order to identify ‘trigger’-type joystick axes which center at -1 or at other strange points.
“Stage two” will be coming next, which will store control mappings separately, based upon how a gamepad identifies itself to the system. By this I mean that if your gamepad identifies itself sensibly (many do, some don’t), then VectorStorm will store that gamepad’s configuration automatically, and will then automatically recognise that particular gamepad in the future and re-load its custom configuration data. This will make it much nicer, swapping between various gamepads. I’m hoping that stage two will also add support for hotswapping controllers during gameplay.
I haven’t yet rebuilt any of the binary builds with this (I’ll probably wait for “Stage two” before I spend time migrating the changes around between all the various build branches), but there should be new versions of everything, with fixed gamepad support sometime tomorrow).
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.