Today is the 10th of March.
Today is the start of the annual 7-day roguelike contest.
Today I start work on Bob and Trev: Resurrection.
 

What?

I suppose some explanation is in order.
 
A roguelike is, as the name suggests, a game like Rogue. NetHack and Angband are two roguelikes; perhaps you've seen me talk about them before.
 
A 7-day roguelike (7DRL) is a roguelike written in 7 days, or perhaps more precisely "This means the author stopped writing code one hundred and sixty eight hours after they started writing code." For the past few years, the denizens of rec.games.roguelike.development have held a 7DRL challenge, in the months of February or March. There aren't any winners or prizes per se, it's just an excuse for people to experiment with new ideas, and produce a working game which others can explore to see how well those ideas worked out.
 
Bob and Trev are two characters who first appeared in a series of joke letters in The Micro Users' letters page. These letters dealt with the trials and tribulations of an 80's home computer tinkerer, and the way the world around him (particularly his wife) viewed his hobby. Some of these letters can be seen online here.
 
The letters however were rather tame in nature, and not really befitting of a roguelike. The real inspiration for the roguelike comes from a much later letter, in 1995, in the last ever issue of Acorn Computing. This letter sent things down a slightly more surreal and apocalyptic/dystopian path, featuring cemtex mice, floppy disc drives brandished as deadly weapons, the dongle squad, the Acron Users' suicide clan, and the usual smattering of in-jokes. This of course is a perfect setting for a roguelike.
 
So, I present to you, (Or at least I will do in 168 hours), Bob and Trev: Resurrection.

Surely you can do better than that!

That's what I thought. For a few weeks I was idly trying to think of an idea for a roguelike to enter into the competition, but the Bob and Trev one seemed to be the only one that I could make work. All the others lacked focus, or lacked depth (e.g. in terms of the range of dungeon items and monsters), or would require too much time to try and make it authentic when compared to the source material. The only option that I was left with, and would be fun to write, was one based around Bob and Trev.
 
But the problem is, that as far as roguelikes go, my design didn't attempt to do anything particularly new. If I wanted, I could just go into NetHack or Angband and rename all the monsters and items, and come out with pretty much the same game. This would be my first "and a bit" roguelike, so I didn't particularly want to stray too far from the norm in developing new gameplay mechanics that I may lack the skill to implement. But I am an experienced programmer, so maybe I can focus my efforts elsewhere?
 
Traditionally, roguelikes are written in C or C++, and use the curses or ncurses library for screen IO. This ensures the games are portable and can run on a wide range of hardware, usually considered as one of the defining features of a roguelike. However I've never used curses before, and from my work with porting NetHack I know that it isn't always easy to get it running nicely on RISC OS. My original intention was to ignore this issue entirely by writing my own IO library, basically a thin wrapper around the RISC OS VDU which could then be swapped out with curses at a later date, to allow non-RISC OS users to play the game.
 
But that still doesn't solve my problems of a Bob and Trev game being too 'easy'.
 
So, I decided to take things a step further. Bob and Trev were big BBC fans, and the game was going to be focused mainly around BBC-era hardware. So why not write the game for a BBC?
 
After a bit of research, I came out with some minimum specs for the game. It should be able to run on a BBC Model B with the default 32K of RAM, and a 40-track floppy disc drive. Out of a choice between programming in BASIC II and assembler, I chose BASIC - my 6502 assembler experience is limited, there's no guarantee the resulting program would be smaller than the BASIC version, and BASIC is far more portable. If I write it properly, the BASIC version will be able to run on anything from an authentic (or emulated) BBC, to a modern RISC OS machine, to non-native ports of BASIC, or on the cross-platform, open-source BASIC clone Brandy.

Still to come

For the rest of this week, I'll be posting daily articles discussing the processes behind designing a roguelike for such a limited platform, describing some of the major engine components (such as the map generator and how to implement visibility checks), and recounting any significant pitfalls or breakthroughs that occur during the writing of the game.
 
Of course, going to work, designing a roguelike, implementing a roguelike, and writing about it in a 7-day period is a bit much, so I've taken one of the liberties afforded by the challenge rules and designed most of the game beforehand. I've also written most of these articles beforehand, based around that design. The challenge I've set myself isn't to write a roguelike from scratch within 7 days; it's to see exactly how much can be squeezed into a BBC Micro (in 7 days). I've got no idea how large the code will get as I add feature upon feature to it, and I've got no idea how much I'll be able to optimise it to make it run as fast as possible; so rather than just charge in blindly it made much more sense to plan all the major features beforehand and check it all makes sense. It would have been rather embarrasing, for example, if on the first day I start writing the game to use an 80 column screen mode, only to find out on the second day that the 8K of RAM I'm left with isn't even enough to fit a map generator and a couple of monsters for the player to fight.
 
Saturday the 10th: Bob and Trev: Resurrection (this article)
Sunday the 11th: How to fit a roguelike in 32k
Monday the 12th: Static game data
Tuesday the 13th: The level generator
Wednesday the 14th: Visibility and pathfinding
Thursday the 15th: Combat
Friday the 16th: Monster AI
Saturday the 17th: Conclusion