Hugh Robinson has contacted us to let us know that he's converted classic Acorn platformer Asylum to C, using the SDL library. With full support of original author Andy Southgate, Hugh's source code has now been released under the GPL, and is available to download from the SVN repository on the SourceForge project page.
 
Although a quick look at the source suggests to me that it's fully converted, there are still some bugs and compatability issues to sort out, so feel free to send any fixes Hugh's way if you manage to get the game running. Although the source to Asylum has been available on asylum.acornarcade.com for a few years now, this is the first known port of it to any other platform (and could potentially form the basis of a back-port to RISC OS, to produce a fully 32bit compatible version).
 

In this article we look at some of the programs and projects - some obvious, others less so - that influenced the history of the RISC OS platform and its users. These are our suggestions, not a top ten and certainly not in any particular order. What other applications would you add to the list?
 

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.