Late on RockSolid Rally
So we’ve been working some more on RockSolid Rally, a lot of little things have been done.
I’ve set up a value animation system with start and end value and different interpolation types (linear, smooth, bounce…) and it’s already proven quite useful in providing fun effects for buttons and in-game feedback. It’s now part of NuclearWinter which is the C# XNA utils library I started with stenciL.
Sadly the game will clearly not be ready in time for the deadline I set a few weeks ago (July 1st). The game looks good but gameplay-wise it’s still lacking a lot. Once the gameplay is fixed, designing a bunch of levels should not be much of a problem. Hopefully we’ll be able to release in a not-too-distant future. As always with this kind of project, it ends up being a lot more work that you’d imagine. Speaking of which…
Introducing… Project Copper!
Ok this one had been tickling my mind for too long. So Saturday I couldn’t hold it anymore and decided to take the day to give it a try and then ditch it if the result wasn’t satisfying. Needless to say, it turned out quite well.
Copper (working title) is a networked multi-player puzzle-platform game. Basically, 1-4 players control their robots through levels, activating switches, pushing buttons, squishing enemies, whatever. I took this opportunity to let vector graphics on the shelf and get back to good old pixel-art (using GIMP).
After much hesitation on the coding side, I went with Python, PySFML and bare sockets. I took a quick look at some old python network code I made for a long-forgotten game project, and together with the experience I had in decoupling logic from rendering with TURN, I managed to come up a very clean design. The client and server both use the same game logic classes, but the server has no dependency whatsoever on the rendering code . Networking is also nicely set apart from rendering and game logic. Most of it is accomplished by using the observer and pub/sub design patterns.
The game uses UDP sockets for droppable packets (repeated state changes) and a (supposedly reliable) TCP connection for important packets (object creation / deletion and other game events). While testing the game with two computers, we stumbled upon a lot of lag on my laptop. I spent an hour or two trying to improve interpolation or find a bug in the network code before realizing the problem had to do with rendering! Blitting a lot of sprites for drawing the level tiles is of course less-than-ideal. So I went ahead and rewrote the rendering part in PyOpenGL (still using PySFML for windowing, image loading, inputs and timing) and all the lag issues went away. Hooray!
On my daytime job at Creative Patterns, I’m having quite some fun implementing Lua mission scripting for a game we’re working on for an editor (can’t say more about it). Lua is definitely a great tool! I’m currently designing the engine’s scripting interface and documenting it as I go. I’ve heard most programmers dislike dealing with documentation, but I actually enjoy making it useful and look shiny :).
In unrelated news, I got my midi master keyboard (KeyRig 49) a few days ago and I’m having some fun learning to play, but it’s getting obvious that it’s going to take a while before I can play anything that you’d like to listen to ;).