Wednesday 27 February 2008

Overengineering taken to wobbly extremes

At lunch today I sketched out a concept for a remote console. This is a simple console app that can connect to a debug version of the game and permits selective echoing of output to said app. Initially I thought this might be useful simply because it's frequently handy to have vast swathes of debug information being spat out of a game, but neither game interfaces nor standard output streams give much helpful capability in the way of filtering and feedback.

This seems quite nice. You can run the main game exactly as you expect the final game to work, and dump debug spraff at various levels to selected channels on the network facade, to be displayed on multiple client console windows. It's all very simple, and as long as its compiled out for release not a security concern.

Then I got to thinking about using it as a debugging aide. With some friendly elves opening up firewall ports for testing, several people could play the game and if something goes tits up, I can dive in and get some limited information. Of course, the next logical step would be to allow for network duplication of the game state along with recent history, which could be loaded into a local copy of the game and debugged properly. This wouldn't have to be efficient or anything, as it's just a debugging tool.

Of course, then I got to thinking that maybe you could allow two-way chat, maybe a full chat service by using a few common protocols. You could even allow remote spectators, with a client running as a dumb terminal...

Then I realised I'd taken a sane idea, dressed it in a three piece suit made entirely of pilchards, sellotaped a rubber chicken to its forhead and given it a nerf bazooka loaded with balls of barely sub-critical enriched uranium.

No comments: