7DRL: Bob and Trev: Resurrection
Phlame...@gmail.com
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:
http://myweb.tiscali.co.uk/themicrouser/menus/humour.htm
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?
Cheers,
- Jeffrey
Mario Donick
> Now, who's going to be the first to offer to write a 7DRL for a 1K
> ZX80?
On 21 Feb., 02:39, Phlamethro...@gmail.com wrote:
> 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 ... ;)
Mario
Antony Sidwell
> 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
henr...@gmail.com
justified to create non-persistent levels, and instead focus on
generating particularly good random levels.
Gerry Quinn
henr...@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.
- Gerry Quinn
Phlame...@gmail.com
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.
David Damerell
>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 <dame...@chiark.greenend.org.uk> Distortion Field!
Today is Leicesterday, February.
Phlame...@gmail.com
wrote:
> Quoting <Phlamethro...@gmail.com>:
>
> >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.
> --
> 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.
David Damerell
>On 22 Feb, 14:42, David Damerell <damer...@chiark.greenend.org.uk>
>wrote:
>>not going to be walking round a skyscraper with digging tools - random
>>seed plus diffs might be an efficient way to store persistent levels.
>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 <dame...@chiark.greenend.org.uk> Distortion Field!
Today is Leicesterday, February.
Phlame...@gmail.com
wrote:
> Quoting <Phlamethro...@gmail.com>:
>
> >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.
> --
> Today is Leicesterday, February.
Vacuum, eh?
*makes note: add vacuum cleaner to game*
David Damerell
>>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 <dame...@chiark.greenend.org.uk> Distortion Field!
Today is Leicesterday, February.
henr...@gmail.com
>> 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. [snip]
To me it isn't a matter of development time - it is a matter of
content:
With only 32k working RAM it makes a lot of sense to keep a lot of
game data (monster stats, items, etc) out of RAM and on the disk -
the way I tend to create lots of data I would not really want the
spare disk space to go to level persistency.
If you absolutely require persistent levels, I suggest the following:
Store the random number seed of a level so you can remake it on
the fly without having to actually store the result; and just let
items
get hoovered away from a level when you leave. (However
digging through walls would require extra handling, since you
climbing a skyscraper I imagine it isn't too relevant an issue.)
The advantage then is that you're not limited to small levels, you
could have relatively large persistent levels with more fanfares at
the loss of item/monster-persistence.
If you really want-it-all (persistent levels and objects) the easiest
would be to use level-rebuilding from random seed and to have
all the item types possible in a single array on disk
(differentiating between identified/not, blessed/uncursed/
cursed, etc). Then each object stored in a level only requires
position and type to be saved. That would be 3 bytes, or only
2 bytes if you can compress the position and type into 16bits.
Phlame...@gmail.com
> If you absolutely require persistent levels, I suggest the following:
> Store the random number seed of a level so you can remake it on
> the fly without having to actually store the result; and just let
> items
> get hoovered away from a level when you leave.
Thinking about it, I don't think there's much of an argument for why I
should have persistent items. Any monsters which are left alive could
either run off or follow the player to the new level, and any items
which are left behind have presumably been left because the player
doesn't want/need them. But at the same time, I can't think of any
reasons why I shouldn't have persistent levels and items. Having fully
persistent levels and items will certainly place some restrictions on
the game, but I'd rather try working within those restrictions only to
find it's impossible rather than take the easy route and throw all the
old data away without even trying.
If my ideas don't work - then fine, I'll start cutting them back. But
at least we'll have some concrete evidence of them not working,
instead of (what appears to me to be) a load of people running around
claiming the sky is falling :)
The whole idea of me writing it for a BBC is to find out exactly
what's possible within the limitations of the machine - so I'm going
to want to be pushing against and challenging those limits, not
running away from them.
Gerry Quinn
Phlame...@gmail.com says...
> On 23 Feb, 02:37, henrih...@gmail.com wrote:
> > If you absolutely require persistent levels, I suggest the following:
> > Store the random number seed of a level so you can remake it on
> > the fly without having to actually store the result; and just let
> > items
> > get hoovered away from a level when you leave.
>
> Thinking about it, I don't think there's much of an argument for why I
> should have persistent items. Any monsters which are left alive could
> either run off or follow the player to the new level, and any items
> which are left behind have presumably been left because the player
> doesn't want/need them. But at the same time, I can't think of any
> reasons why I shouldn't have persistent levels and items. Having fully
> persistent levels and items will certainly place some restrictions on
> the game, but I'd rather try working within those restrictions only to
> find it's impossible rather than take the easy route and throw all the
> old data away without even trying.
You're in a skyscraper and the elevator only goes up.
You're in a cave and have to jump down a hole to the next level.
The portal to the next level requires passing through an event horizon.
> If my ideas don't work - then fine, I'll start cutting them back. But
> at least we'll have some concrete evidence of them not working,
> instead of (what appears to me to be) a load of people running around
> claiming the sky is falling :)
>
> The whole idea of me writing it for a BBC is to find out exactly
> what's possible within the limitations of the machine - so I'm going
> to want to be pushing against and challenging those limits, not
> running away from them.
In a (never completed) project a long time ago, I saved the seed for
each level, plus a list of the ten most important/valuable items.
Other items just had their value added up, and items of that value
would be generated randomly on re-entry. The saved items would
persist.
- Gerry Quinn
Ray Dillinger
> Thinking about it, I don't think there's much of an argument for why I
> should have persistent items. Any monsters which are left alive could
> either run off or follow the player to the new level,
Hee! What a dastardly idea! You could have all hostile
creatures encountered *always* shift level with the character,
until the character kills them or they find some reason to be
more interested in something else than the character.
So, you meet BigNasti out of depth on level 9, run upstairs,
and he chases you back to level 8, and 7, and 6 ...
This could make an interesting subgame where the successful player
goes "what have I met that wasn't hostile, but which will fight
BigNasti?" or "what have I met that BigNasti would rather eat
than me?" And leads the chasing creature back to it.
It could also make for interesting variations where the player
(advertently or otherwise) leads something back to town and leaves -
and when he comes back it's eaten all the people. Bonus points
if it was a vampire and now all the townspeople are too, or
something like that!
Bear
henr...@gmail.com
> what's possible within the limitations of the machine - so I'm going
> to want to be pushing against and challenging those limits, not
> running away from them.
Respect - and good luck ;)
Even with 32kb RAM + 100kb disk I think pretty much everything is
possible. You'd have to ask yourself how much time are you willing to
offer for each computational step; for example, do you want to keep
all data (monster stats, item types) on the disk and retrieve data
only as needed - or do you prefer to get the most dazzling speed out
of the system and keep most things in RAM.
Phlame...@gmail.com
started coding last night.
So far I've managed to write the core of the engine, including the
load/save system, prototype map generator, and line-of-sight code. I
can happily wander around the map opening and closing doors.
http://www.phlamethrower.co.uk/misc2/batr1.png
But then I tried running it under a BBC emulator, and discovered how
hideously slow it all is. Some of it seems unavoidable (20 seconds to
load the 4KB data file with all the dungeon items in), other bits are
due to the unoptimised state of the code (taking 1 second to draw each
map cell), and other bits suggest I'm pushing the machine too hard -
the line of sight algorithm takes around a minute to run!
Admittedly I am only using a very simple ray casting algorithm (mainly
to keep code size down - it's already up to 10KB, out of 16KB max I
have available when taking all the other data into account), but even
if I were to take the time to implement a beam casting or similar
algorithm I doubt it would approach a playable speed. So currently I'm
trying to decide whether I should switch to a different LOS technique
(e.g. a room gains visibility when you enter it, but remains visible
even if you go elsewhere), or ignore the speed problem and have a go
at crafting some assembler optimisations once the competition is
over :)
Phlame...@gmail.com
On 10 Mar, 18:32, Phlamethro...@gmail.com wrote:
> So currently I'm
> trying to decide whether I should switch to a different LOS technique
> (e.g. a room gains visibility when you enter it, but remains visible
> even if you go elsewhere), or ignore the speed problem and have a go
> at crafting some assembler optimisations once the competition is
> over :)
Luckily, I came to my senses and just wrote a simpler LOS technique.
The game now effectively treats doors (and windows!) as vision
blockers, so you can only see the contents of the room you're in.
Although this code is a lot faster (and only needs updating when you
change room), it does make some of my planned features harder to
implement (e.g. the sunglasses that would reduce your visibility, but
provide protection from being blinded by bright lights).
Following some rewrites and optimisation, the code now runs at an
acceptable speed on a BBC - you can take about 2 or 3 moves per
second. Save files are now a bit smaller too, so it should be possible
to fit the game and a full save file onto a 40-track floppy :)
New features:
* level progression
* unique start and end levels to the dungeon (aka skyscraper)
* rudimentary item and monster spawning
* inventory management; take, drop, and look commands
http://www.phlamethrower.co.uk/misc2/batr2.png
http://www.phlamethrower.co.uk/misc2/batr3.png
Monster AI and combat will be the next thing on the list, after which
the game could probably be classed as, well, a game.
Unfortunately I'll soon be pushing against the memory limit of the
machine - the code is now almost 15KB in size, and runtime checks show
I only have about 1700 bytes left. Luckily there are some tricks
available for me to shrink the code. Modern versions of BASIC have a
CRUNCH command, which can remove about 3KB of wasted space, and there
are some more advanced BASIC compressors available, which can get the
current code down to under 9KB. Plus there will be more space gained
'naturally' as I remove unwanted items from the game data file.
Cheers,
- Jeffrey
Phlame...@gmail.com
> Monster AI and combat will be the next thing on the list, after which
> the game could probably be classed as, well, a game.
The game is now "a game". I had for forsight to book today off work,
which means:
* (simple) monster AI
* Combat - bare handed and with wielded weapons. Throwing, firing,
etc. still to come.
* Armour
* More useful and entertaining error handling
* Colour support!
* A couple of dungeon generator fixes
* Added framework for extra player stats - experience points,
intelligence, hunger status, etc.
* Added memory use tracking
http://www.phlamethrower.co.uk/misc2/batr3.png
http://www.phlamethrower.co.uk/misc2/batr4.png
The game still runs at an acceptable speed on a BBC, but the un-
compressed code is now 19KB in size, which is far too big. Compressing
it gets it down to about 12KB, which as the second screenshot shows,
leaves me with about 5.5KB space spare. There are only a handful of
really major features left for me to implement (proper item/monster
spawning, HP regen, win condition, and xp level advancement), so I'd
say things are looking good memory-wise.
Phlame...@gmail.com
> There are only a handful of
> really major features left for me to implement (proper item/monster
> spawning, HP regen, win condition, and xp level advancement), so I'd
> say things are looking good memory-wise.
These features are now implemented, so I could now say that the code
is "complete":
a) It's a roguelike
b) It has an achieveable win condition
c) There are no known game-killing bugs
d) It runs on the target platform, at an acceptable speed.
So technically I could just spend the rest of the week playtesting and
tweaking item stats.
But of course I'm not going to do that, because there's still a raft
of features I want to add, and optimisations to make...
And one of the screenshots in the previous post should have been
http://www.phlamethrower.co.uk/misc2/batr5.png instead of no. 3
again ;)
Cheers,
- Jeffrey
Phlame...@gmail.com
crunch approaching :)
* Both the player and monsters start with items. Different monsters
will start with different items, e.g. the Stylophone Clan members will
start with Stylophones.
* (basic) code to handle stacks of items is in
* .... which also means that weapon firing code is in, for both
monsters and the player.
* Map discovery is back - the dungeon layout will be hidden when you
start the level
* Explosive weapons implemented
* And not mentioned earlier, but the visibility/LOS code is now in its
fully optimised state. Only takes a few seconds to change room, and
90% of that time is spent in screen updates.
The uncompressed code sits at 26,946 bytes; the compressed code is
16,114, although I can shrink it further. A runtime check shows I have
about 1.5K of memory spare, so there's still some room for expansion.
But preferably I want to have all the code finished tonight, so I can
spend the remaining couple of days testing, balancing, and fixing. I'm
not sure exactly which features I'll have a chance to squeeze in, and
the player currently has two stats (intelligence and wisdom) that do
nothing.
Hmm.
Cheers,
- Jeffrey
Phlame...@gmail.com
> Things are starting to come together now... I can feel the final
> crunch approaching :)
...and that's the final crunch over with. Yesterday morning I finished
adding the major missing features I wanted, and then did a size check.
Only around 600 bytes of RAM spare, which means I can't expand any
further because that memory is needed for strings, local variables,
etc. Unfortunately I'd also broken the code, so I only found out
exactly how much was left when I was able to fix it after coming home
from work.
So the good news is that I'm now in the process of the final
balancing, bug fixing, and play testing. The bad news is that last
night I also tried running it under the Linux version of Brandy
(http://jaguar.orpheusweb.co.uk/branpage.html), and found a couple of
critical bugs in the interpreter. So anyone who wants to run it under
Brandy will have to recompile it with my fixes (which should be ready
in time for release, assuming there aren't other bugs lurking), or
wait for the official distribution to catch up.
Cheers,
- Jeffrey
Phlame...@gmail.com
http://www.phlamethrower.co.uk/riscos/batr.zip
damn last minute bugs :(
Readme extract follows, for those who are unfamiliar.
Cheers,
- Jeffrey
--------------------------------------
7DRL: Bob and Trev: Resurrection
--------------------------------
(c) Jeffrey Lee 2007. Released under the GNU GPL version 2.
Created for 7DRL challenge 2007:
http://roguebasin.roguelikedevelopment.org/index.php?title=7DRL_Contest_2007
Introduction:
-------------
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
dealt 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:
http://myweb.tiscali.co.uk/themicrouser/menus/humour.htm
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, Bob and Trev: Resurrection.
Minimum system requirements:
----------------------------
A BBC Model B with 32k of RAM and 100k disc drive, i.e.:
* BBC BASIC II
* 24.75k free RAM
* A 40x25 text mode
* 22k free disk space for game data
* And (up to) 57k for each save file
The game should also run fine on newer versions of BBC BASIC (i.e. as
shipped with RISC OS), or on the open-source Brandy (http://
jaguar.orpheusweb.co.uk/branpage.html). Note however that the current
version (1.19) contains some bugs that need patching in order for the
game to run (see below).
Technically the game should also run on BBC BASIC for Windows (http://
www.bbcbasic.co.uk/) but I have been unable to test its compatability
due to the 8K RAM limit on the demo version.
The game:
---------
The goal of the game is to ascend to level 30 of the building, steal
the Nut Device, and escape back into the sewers. Along the way you
will meet numerous people who will try to kill you, and find a
multitude of items to defend yourself with.
Features:
* 4 colour ASCII graphics (if enabled)
* Permadeath
* Persistent levels
* Character and monster statistics - XP level, speed, strength,
dexterity, intelligence and wizdom
* Melee, ranged, and fired weapons
* Armour
* Hunger, food, drink, and cooking!
* Item identification
* Map discovery, simple LOS
* A few opportunities for stupid deaths
* Scores file
Phlame...@gmail.com
> Perhaps a minute or two late, but here we are:
>
> http://www.phlamethrower.co.uk/riscos/batr.zip
>
> damn last minute bugs :(
...and the award for the first (real) bug report goes to me. Eating
corpses is broken, which results in you either getting no nutrition
from them, or a completely random value. And the relative lack of
other food (unless you're lucky and start with some pot noodles) means
it's a lot harder to survive than I thought :(
The good news though is that the webpage is up, with some more info
about the game: http://www.phlamethrower.co.uk/riscos/batr.php
And I've been chastised for not publicly plugging TIB on the
newsgroup, so here's a link to the series of article I wrote about the
game ;)
http://www.iconbar.com/articles/Bob_and_Trev_Resurrection/index1131.html
If anyone thinks there's anything useful in them, I'd be happy to copy
them over to roguebasin.
Cheers,
- Jeffrey