log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- !OBrowse reviewed (News:6)
- Aemulor (Gen:16)
- DDE reaches release 28 and above (News:)
- Elesar quicks dispels stormy clouds (News:2)
- RISC OS London Show 2017 - Notes from the talks (News:2)
- RISC OS London Show 2017 (News:)
- RISC OS London Show 2017 - Pictures (News:)
- October News (News:2)
- Retrospective thoughts on 12 months of Titanium ownership (News:4)
- RISC OS London Show 2017 (News:1)
Related articles
- Bob and Trev: Resurrection: Just in time
- Monster AI
- Combat
- Visibility and pathfinding
- The level generator
- Static game data
- How to fit a roguelike in 32k
- Wakefield 2003 - the preview
- Newsround
- Games news
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
Site Search
 
Article archives
The Icon Bar: News and features: Bob and Trev: Resurrection
 

Bob and Trev: Resurrection

Posted by Jeffrey Lee on 00:00, 10/3/2007 | , , , , , , , ,
 
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
 

  Bob and Trev: Resurrection
  andrew (10:42 10/3/2007)
  Phlamethrower (22:13 10/3/2007)
    VincceH (00:00 11/3/2007)
 
Andrew Message #99727, posted by andrew at 10:42, 10/3/2007
HandbagHandbag Boi
Posts: 3439
Amazing idea and on the Beeb as well!
If you didn't use BASIC to run the game I think there's a lot of memory below PAGE you can use. As things stand there's about 20 bytes or thereabouts to potentially use there.

Mode 5 has big graphics, 4 colours and 20K free (IIRC) and if you're clever enough you can reduce the Mode screen memory size to get even more free memory.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #99747, posted by Phlamethrower at 22:13, 10/3/2007, in reply to message #99727
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15057
I was going to post a progress update now, but I think it will fit better at the end of tonight's article.

If you didn't use BASIC to run the game I think there's a lot of memory below PAGE you can use. As things stand there's about 20 bytes or thereabouts to potentially use there.
I don't think I'm quite at the stage where 20 bytes will make all the difference

I could make a much better game if I wrote it in assembler, mainly because of the speed boost, but it would take far too long for a 7 day challenge. As it is, I think the constraints are working well - although I'm not going to be able to put in all the features I want, it will leave me with more time to focus on making the features that are there worthwhile.

Mode 5 has big graphics, 4 colours and 20K free (IIRC) and if you're clever enough you can reduce the Mode screen memory size to get even more free memory.
The game is currently targetted at Mode 7 - it's the only real option I have available considering the memory constraints (tonights article will explain it better). I suppose hacking with the screen memory would be one way of getting a better display, but getting the timing right in a BASIC program would be tricky
  ^[ Log in to reply ]
 
VinceH Message #99750, posted by VincceH at 00:00, 11/3/2007, in reply to message #99747
VincceH
Lowering the tone since the dawn of time

Posts: 1583
If you didn't use BASIC to run the game I think there's a lot of memory below PAGE you can use. As things stand there's about 20 bytes or thereabouts to potentially use there.
I don't think I'm quite at the stage where 20 bytes will make all the difference
There's actually quite a bit more than a spare 20 bytes, IIRC, depending on what you're doing and using. (ROMs, user defined graphics, etc). The space can be potentially be used for code or program data.

And a quick search later reveals a PDF of the BBC User Guide which basically confirms that. That brings back some memories.
  ^[ Log in to reply ]
 

The Icon Bar: News and features: Bob and Trev: Resurrection