Previously, on Bob and Trev: Resurrection...

Game over, man
 
The competition is nearly at an end, which can only mean one thing - tomorrow's article will be the conclusion, and will (hopefully!) feature a copy of the game to download.

...and here it is.
 
 

Previously, on Bob and Trev: Resurrection...

Next time I'll be talking about monster AI. I'm not going to be creating an Einstein, but I will be able to talk about a few of the basic features I'm hoping to implement.

But before I talk about monster AI, I might as well take the time out to talk about the time system that the game will use. Also, I don't have much other material for this article.
 
 

Previously, on Bob and Trev: Resurrection...

Next time I will be tackling combat. Having never written a roguelike combat system before, it will be an interesting exercise in deciding how mechanics such as strength and armour class will work, and attempting to get the numbers right first-time to reduce the amount of balancing required.

Forsight, there.
 
Combat is an important aspect of all roguelikes. But having never looked at a roguelike combat engine in detail before, I don't really know much about how they work. Monsters have strength, dexterity, and armour class attributes, but how do those translate into how hard the monster hits with a weapon?
 
Note that a lot of the values and equations presented in this article aren't set in stone yet, and will require tweaking during play-testing. But hopefully I'll be able to shed some light on the different aspects of combat, and the thought processes involved in creating a balanced combat system.
 
 

Previously, on Bob and Trev: Resurrection...

...

Yeah, looks like I forgot to write anything to lead onto this article.

Anyhoo, this article will be discussing visibility and pathfinding. Both are important aspects of many roguelikes, and both have some important implementation issues to try and overcome. Line-of-sight algorithms are a popular topic on rgrd - right now I can see two threads talking about LOS algorithms, and know of at least one other that talks about them.

 

Previously, on Bob and Trev: Resurrection...

Previously, on Bob and Trev: Resurrection...

The current dungeon level.
For simplicity, I won't be having a scrolling map. This means that the largest level possible would be 40 by 25 tiles; in reality I'll only be using 40x22, as 3 rows will be required for displaying the players' status and game messages. And since the dungeon is fairly simple in design, I'll only need at most 1 byte per tile - so a full map of the current dungeon level will require 880 bytes of memory.

Until now, I haven't really gone into any detail about what the dungeon structure will be like. Since you don't find many BBC users in Gnomish mines, I realised quite early on that the traditional underground dungeon setting wouldn't work very well for this game. So instead I turned the game world on its head - you'll start at the bottom of a skyscraper and work your way up. In particular, if I have the time I'll make the first and last levels unique - the first level will be an underground parking lot, and the last level will be the rooftop, where you will find your nemesis (Don't ask me who he is - I haven't decided yet!) These unique levels will require only simple generators, but how will the office levels inbetween be generated?
 
 

Previously, on Bob and Trev: Resurrection...

Initially, I was considering using DATA keywords to store the static data. BASIC II supports RESTORE by-line-number, so by storing data for each item on a seperate line I could have fast access to it without requiring the entire DATA segment to be read or extracted and stored elsewhere.
Unfortunately some simple maths shows that DATA statements would take too much space. To store a one-digit number, two bytes would be required - one for the number, and one for the comma seperating it from the next field. A raw CSV export of the spreadsheet I was designing everything in came to 14K (A bit of an unfair test, but indicitative of how many items I'm hoping to include in the game). So, I set about designing a better solution...

This is a discussion about that 'better solution', a program which I've dubbed 'dungen', and by the time you read this will hopefully be complete. As input it will take a TSV file, and as output it will produce a data file for use by the game. Dungen will be written in BASIC, so anyone able to run the game should be able to rebuild the data for it.
 
 

Previously, on Bob and Trev: Resurrection...

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.
 
...
 
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

So the questions I need to answer are:

1. What restrictions does the game need to work against?
2. What data does a roguelike need to store?
3. How can I fit all that data into the machine?

 

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.