Since people have started to announce their projects, I thought I might as well go ahead and announce mine. It'll be my first "and a bit" roguelike, and as with the tradition of the competition it isn't entirely orthodox, nor does it take itself too seriously.
To fully understand it, a bit of background information is required. Around the time the BBC Micro was popular, there was a magazine called The Micro User. And in the letters page, there were some humourous, fictional letters from Bob, writing to his friend Trev. These letters delt with the trials and tribulations of an 80's home computer tinkerer, and the way the world around him (particularly his wife) looked upon 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 Bob and Trev letter sends 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 once the competition is over), Bob and Trev: Resurrection (Working title).
The mechanics of the game will be like most other roguelikes. However instead of travelling down through the dungeon you will be travelling up to the top of a skyscraper; and instead of wielding +5 swords of Ultimate Power you'll be relying on a Stylophone and some mouse cleaning fluid.
But then I decided this would be far too simple an entry to have any real impact on the roguelike world, so I decided to take it one step further. The target machine will be a 2MHz BBC Model B with 32K of RAM and 100k disc drive. And for maximum portability (and because 6502 assembler would be a step too far), the game will be programmed in nothing but BBC BASIC. This means it'll run on any authentic Acorn/ RISC OS machine with 32K of RAM, or on practically any other machine that has a BBC emulator, or has a port of BBC BASIC, or can run the open-source Brandy (http://jaguar.orpheusweb.co.uk/branpage.html).
Of course this is a rather restrictive computer to aim for, so planning is key. To help with this I've made a list of around 150 items, monsters, and dungeon pieces. Apart from helping me work out some of the functional requirements of the game and how some of the mechanics will work, it's also allowed me to calculate how much memory is needed. The game should need little more than 3K of RAM to maintain its working state, and with a 100k floppy inserted it should be able to support a dungeon around 30 levels deep (Each previously visited level will be saved to disc, ala NetHack). Savegames, high scores, and bones files will of course be supported.
Unfortunately memory constraints mean that if I want an interesting game it will have to be black and white only, and operate in a 40 column screen mode. With the BBC I basically have two options available - a fully graphics capable mode, or the text-only teletext mode. There is a graphics mode that gives 80 columns of text in 2 colours (and another that provides 40 columns in 4 colours), but both require a whopping 20K of RAM. Teletext, on the other hand, provides 40 columns in 16 colours, and only uses 1K of RAM. As far as memory usage goes, the correct choice is obvious. Unfortunately Teletext in the UK doesn't allow you to place two letters of differing colours directly next to each other, so I won't be making any concerted effort to use colour for the map display. The good news however is that you can upgrade your BBC to well above 32K of RAM, so if I have time I'll try adding support for 4-colour operation in a graphics mode, for those with high-end machines. And colour TV.
There's still a fair amount of planning to do, so hopefully I'll be able to fight away my urges to start coding until the competition week.
Now, who's going to be the first to offer to write a 7DRL for a 1K ZX80?
> Now, who's going to be the first to offer to write a 7DRL for a 1K > ZX80?
Your idea sounds cool =) I don't have a ZX80, but my first computer was a so-called KC85/3, which was manufactured in the former and now R.I.P. German Democratic Republic. It had 32K of RAM (16 K were usable for BASIC), 320x240 resolution with 16 colors (but only for every 8x4 pixel) and a CPU called U880A, which was compatible to Intel 8080... there's even an emulator around for this computer, and your idea makes me think of programming a RL for this computer ... I loved it, I even programmed a graphical user interface (used only by me of course) for it ... but then its keyboard got broken :( However, I don't have time, and I have to finish LambdaRogue and Tiamyth, but in two or three years ... ;)
> But then I decided this would be far too simple an entry to have any > real impact on the roguelike world, so I decided to take it one step > further. The target machine will be a 2MHz BBC Model B with 32K of RAM > and 100k disc drive. And for maximum portability (and because 6502 > assembler would be a step too far), the game will be programmed in > nothing but BBC BASIC. This means it'll run on any authentic Acorn/ > RISC OS machine with 32K of RAM, or on practically any other machine > that has a BBC emulator, or has a port of BBC BASIC, or can run the > open-source Brandy (http://jaguar.orpheusweb.co.uk/branpage.html).
At last, a sensible reason for starting a new project with BBC BASIC - maximum portability! :)
Sounds interesting, though, good luck with it when coding time finally arrives. It'll be nice to have another reason to fire up the RISC OS machine every now and again. -- Antony Sidwell
Just a suggestion: Given the severe limitations, I feel it is justified to create non-persistent levels, and instead focus on generating particularly good random levels.
In article <1172141442.564917.67...@p10g2000cwp.googlegroups.com>, henrih...@gmail.com says...
> Just a suggestion: Given the severe limitations, I feel it is > justified to create non-persistent levels, and instead focus on > generating particularly good random levels.
It's purely an aesthetic choice whether to create persistent levels on not, IMO.
> Just a suggestion: Given the severe limitations, I feel it is > justified to create non-persistent levels, and instead focus on > generating particularly good random levels.
I don't think development time saved by not having persistent levels will allow me to develop a significantly better random level generator. The extra time would certainly be welcome, but I also don't particularly like roguelikes without persistent levels. In a traditional dungeon you can partially explain it away by saying that you're going down different passageways each time you go up or down a level, but with a skyscraper or other building you're unlikely to have that excuse to fall back on ;)
I've done some random map generation in the past, and am fairly confident I can come up with some good algorithm ideas before the compeition starts.
>On 22 Feb, 10:50, henrih...@gmail.com wrote: >>Just a suggestion: Given the severe limitations, I feel it is >>justified to create non-persistent levels, and instead focus on >>generating particularly good random levels. >I don't think development time saved by not having persistent levels >will allow me to develop a significantly better random level >generator.
If levels can only be altered trivially - opening doors, etc - and you're not going to be walking round a skyscraper with digging tools - random seed plus diffs might be an efficient way to store persistent levels. -- David Damerell <damer...@chiark.greenend.org.uk> Distortion Field! Today is Leicesterday, February.
> >On 22 Feb, 10:50, henrih...@gmail.com wrote: > >>Just a suggestion: Given the severe limitations, I feel it is > >>justified to create non-persistent levels, and instead focus on > >>generating particularly good random levels. > >I don't think development time saved by not having persistent levels > >will allow me to develop a significantly better random level > >generator.
> If levels can only be altered trivially - opening doors, etc - and you're > not going to be walking round a skyscraper with digging tools - random > seed plus diffs might be an efficient way to store persistent levels. > -- > David Damerell <damer...@chiark.greenend.org.uk> Distortion Field! > Today is Leicesterday, February.
Actually, the main space waster in the proposed savefile format is the object list. Each 40x22 dungeon can be stripped down to 660 bytes of data, but unless I go for a more complex save format I'll also be saving 202 objects, which are 8 bytes each. If on average each dungeon level only contains 30 items, that'll be over half the save file wasted with empty definitions.
If I have the time (or a really good idea) I'll go for a more complex save format, but the limits of DFS, BASIC, and 32K of RAM will be working against me. So for now I'm just sticking to storing a fixed size block of data per level.
>On 22 Feb, 14:42, David Damerell <damer...@chiark.greenend.org.uk> >wrote: >>If levels can only be altered trivially - opening doors, etc - and you're >>not going to be walking round a skyscraper with digging tools - random >>seed plus diffs might be an efficient way to store persistent levels. >Actually, the main space waster in the proposed savefile format is the >object list.
Well, in 8-bit text adventures, things were always taking away dropped objects. Maybe something vacuums most or all or the boring bits of the stuff out a level when you leave it. -- David Damerell <damer...@chiark.greenend.org.uk> Distortion Field! Today is Leicesterday, February.
> >On 22 Feb, 14:42, David Damerell <damer...@chiark.greenend.org.uk> > >wrote: > >>If levels can only be altered trivially - opening doors, etc - and you're > >>not going to be walking round a skyscraper with digging tools - random > >>seed plus diffs might be an efficient way to store persistent levels. > >Actually, the main space waster in the proposed savefile format is the > >object list.
> Well, in 8-bit text adventures, things were always taking away dropped > objects. Maybe something vacuums most or all or the boring bits of the > stuff out a level when you leave it. > -- > David Damerell <damer...@chiark.greenend.org.uk> Distortion Field! > Today is Leicesterday, February.
>On 22 Feb, 17:26, David Damerell <damer...@chiark.greenend.org.uk> >>Well, in 8-bit text adventures, things were always taking away dropped >>objects. Maybe something vacuums most or all or the boring bits of the >>stuff out a level when you leave it.
Please cut signatures and trim quoted text.
>Vacuum, eh?
"Hoover", surely? -- David Damerell <damer...@chiark.greenend.org.uk> Distortion Field! Today is Leicesterday, February.