But whose birthday is it?

It's ours, of course!

Ten years ago today, Acorn Arcade officially opened to the public, as this handily-archived newsgroup posting shows. With Alasdair Bailey and Graham Crockford at the helm the site soon increased in popularity enough to warrant moving to its own domain name, acornarcade.com, and eventually to its own dedicated server, owned by our benevolent dictator Rich Goodwin. A few years later Acorn Arcade gave birth to The Icon Bar, which then in an ironic turn of events absorbed the content of Acorn Arcade in late 2006, in order to give both sites a much-needed overhaul.

But what does all this mean?

Well, despite the fall of Acorn, changing home, giving birth, and then getting eaten by our child, the award-winning Acorn Arcade is still here, and we hope that we'll be able provide you with news, reviews, downloads, help and support for at least another 10 years, even if we're not posting as many articles as we used to.

And speaking of articles, we've got a little surprise for you. When migrating Acorn Arcade's content into The Icon Bar's new article system we found a couple of folders on the server that looked like they hadn't been touched in years. And inside those folders we found some relics from times past - Acorn Arcade news archives stretching back to April 1998, and previews of MicroDigital's Mico and Acorn's ill-fated Phoebe machines. Since we were on a tight launch schedule for the new-look Icon Bar, the decision was made to hold these old articles back. After all, no-one except us knew about them. Predictably, we promptly forgot about the forgotten folders, until the topic of our 10th anniversary popped up in the staff forum. Luckily we were able to take a break from our rigorous schedule of procrastinating podcast 6 in order to import the articles in time for today.

Also, with a little help from the Internet Archive Wayback Machine, we've managed to get a couple of screen shots of previous designs of the site, which you may find interesting. Or not.

Forgotten news archives

1998	Pre-July	July	August	September	November	December
1999	January	February	March	May	June	July-November

Forgotten previews

Alasdair's Phoebe preview
Foggy's Mico preview
ChopX Preview
King and Country preview
Super Snail 2 preview
Toy Chronicles preview
Wubble preview

Other forgotten articles

ART thingy - Who are these strange people?
ART attack
ChiBER - RISC OS in a PC box
What's happening on csag?
Doom and Heretic Updates
Heretic upgrades
1998 Midlands show report
NetStation gaming update
PushyII for the PlayStation

9 comments in forum

Merry Christmas to all our readers, and we hope you have a wonderful new year - whatever you're doing and however you're celebrating.

Links:
Christmas (Wikipedia)

1 comment in forum

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

3 comments in forum

The introduction

Eek! There appears to be a problem with the Sheepwell reactor - it keeps going critical and in hot weather melts down. You play the role of "Chin-up" Bill in his Laserdrive - the only man who can stop potential catastrophe by firing a laser bolt directly into the heart of the reactor thus causing a controlled(!) destruction of the whole plant. Of course it's not as easy as that as the reactor is protected by concrete blocks - some immoveable, others you can destroy with your laser. You'll have to deflect the laser round the blocks by strategic placing of mirrors which are not only portable but rotateable.

Enough of the title screen, then. What about the game?

The game

If you haven't worked it out yet, LASER is a game about lasers, mirrors, radioactive sheep, and the soon-to-explode Sheepwell reactor. The action is fairly simple - You have to navigate the maze-like level and position the mirrors so that you can fire a laser into the heart of the reactor before the time limit is reached. The problem lies in that you can only fire the laser from "safe" zones (those without the radiation hazard symbol), and there are both destructible and indestructible walls in the way as barriers. And the occasional two-headed sheep.

If you run out of time you are rather unceremoniously returned to the first level, but since there are only 8 levels in total, it isn't too much of a nuisance to have to redo them. Although the first few levels can be done on your first run through, the last few are quite tricky.

Although fairly attractive, the graphics for the game are also fairly simple. Having said that, the game is designed to run on the lowest common denominator (it will probably run on a 512K machine at a push), and the lack of detailed character animation (e.g. for moving between map squares) doesn't detract from the gameplay. Similarly, the sound effects are simple, yet effective, and there is no background music.

The extras

As previously mentioned the game also comes with a level editor, which allows you to create your own levels (as well as take sneak peaks at the default ones). As with the game the editor is a simple single-tasking affair, using the keyboard to create and edit levels. You also get a few "cheat sheets", showing solutions to the last 4 levels of the game.

The verdict

LASER is a fun little game, one deserving its five minutes of fame on the Internet. Unfortunately it hasn't aged too well, and plays a bit fast on modern machines. Luckily all the code is written in BASIC, so apart from serving as a tutorial for writing simple BASIC games, it's also quite easy to slow the game down if it plays too fast for you.

5 comments in forum

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.

Does it work?

Um, I think so. After not having quite as much time as I liked to get it finished and balanced today, I then remembered at 11:30 that I hadn't tested the exploding weapons yet. And then spent an age trying to work out why it wasn't working. It turns out I hadn't been very careful with my variable names, and some of the screen output code was overwriting variables which were being used to track what's in range of the explosion. Which made for an interesting round of debugging, where code which used to do something suddenly decided to get stuck in an infinite loop.

As such, I haven't been able to play the game to completion, or do enough playtesting to get the balancing right. And with my current screen telling me I have 498 bytes of RAM spare, I'm not even sure if the game will make it all the way to the end.

Now, please excuse me while I go outside and have a heart attack.

r.g.r.a release announcement
Original r.g.r.d thread
Game web page, with source available for viewing online

19 comments in forum

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.

Time

Just like with the combat system, I haven't really looked at roguelike time systems before. Obviously I know what the outcome is - some monsters move more often than the player, and others move less - but I don't know the exact mechanic or formulae behind it.

For Bob and Trev: Resurrection, the choice of time keeping system was fairly simple. The game would have a global 'turn counter', and the speed attribute of the monsters and player would determine how often they move. A proper roguelike time system would likely give each monster an internal timer, which counts down how many ticks are left until the monster can next move; this would allow certain actions to take more time to complete (or recover from) than others. But with memory an issue, I decided to go for an approach that only relies on the global clock:

IF (time MOD speed)=0 THEN move

Simple in design, and on the surface quite effective. However it won't correctly handle cases where the speed of a monster changes (i.e. a monster which slows down may get its next turn a lot sooner than it should), and depending on the scale of the time and speed values, a small change in speed may have a dramatic effect on how fast a monster moves (i.e. changing speed from 2 to 1 will cause a monster to move twice as fast).

Goal-based AI

Goal-based AI is a simple and effective method to make nasties in computer games more interesting. Each AI has a set of goals it can choose between (such as attacking the player or running away). The AI will stick with its current goal until such a time that it completes it, or deems another goal to have a higher priority. For Bob and Trev: Resurrection, I'm aiming to include four basic goals:

• Attack the player
• Run away from the player
• Collect items
• Wander aimlessly

If the player succeeds in damaging the monster to a certain threshold, or the player is significantly more powerful than the monster, the monster may opt to run away. There are many possibilities for a "run away" algorithm, but not all of them are simple enough to be suitable for BASIC running on a 32k BBC.

Similarly, there are many possibilities for a "collect items" goal. A monster could examine its surroundings and seek out the item it will find most helpful - such as weapons or armour. In reality I may not have the time to implement this fully, so a simple "move to nearest item and collect it" approach may be taken.

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.

No comments in forum

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.

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.

Attributes

Bob and Trev: Resurrection has the following attributes that affect combat:

• Mass
• Bludgeon multiplier
• Bludgeon range
• Properties: Explosive, sharp, etc.
• Firing range
• Armour class
• Hitpoints
• Strength
• Dexterity

1. Deciding if the target gets hit
2. Deciding how much force the target gets hit by
3. Deciding how much damage (in terms of hitpoints) that force inflicts on the target

Deciding if the target gets hit

At its simplest, this involves comparing the dexterity of the attacker and the defender. If the attacker is more dexterous than the defender, he has a higher chance of hitting, and vice-versa. But wielding a weapon should also affects dexterity. And how do you measure the dexterity of a copy of Disk Duplicator 285 that's been launched at the player from a 5.25" floppy disc drive?

Time pending, I may design a system that takes all these factors into consideration. But for now, I'm sticking with the KISS approach:

hitratio=(yourdexterity-theirdexterity)/10+0.5

If the difference between your dexterity value and your targets dexterity is 5 or less, the above formula will return a value between 0 and 1, representing the chance of hitting the target. The result of RND(1) will then be compared against this value, to find out whether you do hit or not. If your dexterity is more than 5 points away from your target, it will result in one of two outcomes - always hitting, or not hitting at all.

Also of note is the bludgeon range attribute - this dictates the range of a wielded weapon. Mice and keyboards have long cords attached, so allow you to attack monsters more than 1 square away from you.

Calculating the force

This, thankfully, is quite simple. And is actually based around real science, instead of a load of madeup voodoo, like pretty much everything else.

Firstly, we can assume that the force the attacker is exerting on his weapon is proportional to his strength. We can also assume that the distance he moves his weapon before it hits his target is fixed - let's say a nice round 1 meter. Plugging these values into a few simple physics formulae gives the following result for the acceleration of the weapon:

acceleration = strength*fcoef/mass

(Where fcoef is a magical, to-be-decided value that will scale the strength of a monster into a force value)

Now that we have our acceleration, we need to work out how fast the weapon will strike its target. The kinematic equations come to the rescue at this stage, boldly stating that:

v_f² = v_i²+2*a*d

Rearranged and with our acceleration formula, this gives, for v_f:

velocity = sqrt(2*strength*fcoef/mass)

And finally, one further equation (momentum=mass*velocity) will tell us how much kinetic energy, and thus how much force, the weapon will strike its target with:

momentum = mass*sqrt(2*strength*fcoef/mass)

But not all weapons are created equal. Weapons with sharp edges will undoubtedly do more damage, and a more rigid weapon will do more damage than a floppy one. Hence the introduction of the bludgeon multiplier - the momentum of the weapon is multiplied by this value to give the actual force of impact.

Also, the weapons which are flagged as bladed have a chance of doing extra damage - but the chance of doing this damage, and the amount of extra damage performed, is yet to be decided.

Also, you'll note that (apart from bladed weapons) the force of impact isn't particularly random. To fix this, I've merely added a random factor to fcoef (and factored in the 2 from the kinematic equation). The exact limits of this random factor are still yet to be decided.

Calculating the damage

So, we've determined that the target is going to get hit, and how much force he is getting hit with. Now we need to translate that to a hitpoint value we can remove from his health. The amount of damage reduction is related solely to the targets armour class. The higher the armour class value, the less damage should be done. Particularly, I'm after some nice curve that will cause weapons to do 100 damage to a creature with an AC of 0, and 0 damage to a creature with an AC of infinity. After a bit of cogitating, and messing around with one formula, I arrived at a completely different formula:

damage = damage*a^(AC^b)

By changing a and b, I can chance the characteristics of the damage curve. a can range from 1 to 0, and controls the curviness of the curve. b can be pretty much any positive number, and higher numbers will compress the curve further.

The only problem with the formula is that if b is even, a negative armour class will have the same performance as a positive armour class. This is bad, since it's potentially possible for the player to get stuck wearing cursed armour that gives him a negative AC - and I'd either want the formula to return 1, or some value above 1 to amplify the amount of damage he receives.

Also, if b isn't an integer, the result for AC 0 is undefined (Or, as BASIC puts it, "Logarithm range at line XX"). But that case (along with negative AC values) can easily be catered for with an IF statement.

After a bit of fiddling, I decided on some initial values for a and b - 0.95 and 1.3 respectively.

Calculating the muzzle velocity of a 5.25" floppy disc drive

Weapons which can take and fire ammo have a range attribute, dictating how far the ammo is fired. But how fast does the ammunition travel?

To start with, we can assume that the effect of air resistance on the projectile is negligible - i.e. the only force acting on it while it is airborne is that of gravity. We can also assume that all weapons are fired from the same height (Which we'll just say is 1 meter to make the calculations simpler). And by using another kinematic equation, we can find out how long it will take an object dropped from a height of 1 meter to hit the ground:

d = v_i*t+1/2*a*t²
1 = 0+1/2*10*t²
t = sqrt(5) =~ 2.23

So, no matter what range a projectile has, we know it has a maximum flight time of around 2.23 seconds. We can then calculate the velocity, and thus the momentum, of the projectile by using the old stalwart speed=distance/time (Completely ignoring the effect of gravity on the velocity, of course).

momentum = mass*range/2.23

In reality, the 2.23 will probably need tweaking a bit, either to increase or decrease the effectiveness of firing ammo compared to just walking up to someone and hitting him with it.

For manually thrown objects, the situation is pretty much the same. However, the distance thrown needs to be calculated from the strength of the attacker and the mass of the projectile; using a formula which I'm yet to deduce.

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.

7 comments in forum

...

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.

Line of sight

A roguelike typically uses a line-of-sight algorithm to calculate what the player can see, what monsters can see, and what should get hit by any area-of-effect events such as explosions. There are many different algorithms available, from brute-force ray casting, to the more optimised recursive shadow casting, or highly-specialised routines which rely on certain dungeon layouts. Although fast routines obviously run faster, they are also likely to take more memory - either in terms of code or data. Since I initially thought my largest enemy was code size, I started off with a brute-force ray caster.

The algorithm

The algorithm scans from the player outwards, in the shape of a series of concentric squares, as follows:

6666666666666
6555555555556
6544444444456
6543333333456
6543222223456
6543211123456
654321@123456
6543211123456
6543222223456
6543333333456
6544444444456
6555555555556
6666666666666

For each square in the sequence, a line is traced from the player to each point on the edge of the square. If the line makes it all the way to the end without hitting a solid object, the square is marked as being visible. So far, this is the same as a regular brute-force algorithm, apart from using a radial scanning order. The optimisation I've applied relies on this new scan order - for each radius, a set of flags are kept, indicating, for each side of the square, whether there was any tile that was visible. If no tile was visible on that edge during the previous iteration, then the algorithm assumes that no tile will be visible this time, either. When it reaches the state of no tiles being visible on any of the edges, the algorithm will terminate.

So far I've only using simple floating-point differentiation to walk trace the lines. A more advanced routine would use Bresenham's algorithm, which will be many times faster. But, I suspect, not fast enough - the floating point version takes around 40-60 seconds to run on a BBC. And since it has to be performed after every movement the player makes, it's obviously far too slow for a playable game.

Visibility, MK 2

After panicing for a while and debating whether to change to another algorithm or produce an assembler version of the current one (most likely post-challenge), I came to my senses and realised there was a much simpler approach I could take. My dungeon (currently) consists of a series of rectangular rooms. If I treat doors as vision blockers (even when they're open), then the player's visibility will be limited to just the room that he's in. This means two things:

1. Visibility information only needs to be recalculated when the player changes rooms (i.e. moves outside the currently visible area)
2. Calculating what's visible is just a case of finding the bounds of the current room

Pathfinding

Pathfinding will be used for monster movement. Without pathfinding, the monsters won't be able to follow the player very well if he tries running away. There are basically three approaches available to me:

Algorithm	Accuracy	Speed	Memory usage	Code size
A*	Perfect	Medium	High	Low
Breadth-first	Perfect	Slow	Medium	Low
None	Low	Fast	None	Low

Of the accurate algorithms, A* is definitely the fastest, but requires the most memory. Memory which is unlikely to be available. Breadth-first requires less memory, and can be used to build a map of the entire level, pointing the monsters towards the player - so will become faster as more and more monsters use it. The algorithm entitled 'none', however, only uses simple comparisons to try and guide the monsters towards the player. E.g. if the player is to the east, walk to the east. A couple of extra rules can be used to try and guide the monsters round walls or through doors, but that's about it. It definitely has the speed advantage, however - there is no route map to rebuild every time the player moves.

Since the dungeon is fairly simple in construction, and my memory requirements are so tight, I'll be using the 'none' algorithm. Currently, this involves just sending the monster towards the player, trying to head in a vaguely correct direction if it bumps into something, and then trying a random direction if that doesn't work.

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.

No comments in forum

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.

The Office: A roguelike workplace

The Acron Suicide Clan Member hits!
####-####-########################-#####
#.........#..........#.........#.......#
#.>.......#..........#.........#.......#
#....@S...#..........#.........#.......#
|.........######-#########-#####.......|
#.........|....................|.......#
#####################-##################
#......................................#
#......................................#
|......................................|
#......................................#
#......................................#
#......................................#
#......................................#
|......................................|
#......................................#
#####-#####............................#
#.........#............................#
#.........#............................#
|.....<...#............................|
#.........#............................#
####-####-####-####-####-####-####-#####
Floor:XX £123456 Hungry Conf
xx/yy ACXX StXX InXX CoXX DxXX WiXX ExXX

Above is a fairly simple mockup of what the screen could look like while playing. Windows line the edge of the level; if he wants, the player could break through one of them and jump to his death. Or perhaps push a monster out. Doors seperate the different rooms. Rooms can contain furniture such as chairs and desks, interactable items such as water coolers and plant pots, and hidden traps to thwart any invaders. There will also be toilets, urinals, sinks and cubicle walls, to add some more variety to the design. But how can I generate the levels?

Luckily, I already have an algorithm that works quite well for indoor areas - it's the one I've discussed before that's used by GAIO. With a few tweaks, I can easily adapt it to generate office-like levels for this game.

The algorithm

The best way to describe the algorithm is in terms of how it differs from the GAIO algorithm. For example, it won't split a room if it's a thin corridor. But the more interesting differences are how the new algorithm deals with memory management.

The GAIO algorithm used a lot of scary linked list structures to maintain lists of rooms and edges. This resulted in the code being larger and more complex, and the algorithm using a fair amount of memory (Memory which simply won't be available on the BBC). Furthermore, BASIC doesn't really support dynamic memory allocation, so if it would all have to be done manually. There's also the rather archaic algorithm that randomly connects rooms until all rooms in the map can be connected.

I'm pleased to say that all these issues have been dealt with in the new algorithm. The memory requirements are even low enough for the algorithm to store its temporary data in the 1414 bytes of per-level object data (Which will be free for use, because the game will be halfway between levels at the time).

To start with, I'll talk about how it tackles the problem of room connectivity. Since I won't be having a way for the player to blast through walls, it's important for the player to have a route of doors leading from the start room to the exit room. But how can you generate a level which is guaranteed to have all rooms connected?

Take a look at the following diagram:

......#########
......#.......#
......#.......#
##########-##########
#.....#.......#.....#
#.....#.......#.....#
#.....|.......|.....#
#.....#.......#.....#
#.....#.......#.....#
##########-##########
......#.......#
......#.......#
......#########

By looking at it, you can see that all the rooms are connected. If we split the middle room, we could end up with the following arrangement:

......#########
......#.......#
......#.......#
##########-##########
#.....#....#..#.....#
#.....#....#..#.....#
#.....|.A..#B.|.....#
#.....#....#..#.....#
#.....#....#..#.....#
##########-##########
......#.......#
......#.......#
......#########

Suddenly, the rooms aren't connected anymore. The two on the right are inaccessible to the four on the left. The obvious way to reconnect them is to introduce one or more doors on the new edges - the three edges to the north, west, and south of room B. And if we turn any of those new edges into a door, the map will remain fully connected. And that's all there is to it - making sure that when a split is made, at least one of the new edges introduced is a door edge.

In reality, the algorithm works slightly differently. Assuming 3 new edges are created, it picks two random numbers from 1 to 3, and turns both those edges into doors. Sometimes it may pick the same number, sometimes it may pick different ones - thus ensuring that all rooms are connected without the level degenerating into a linear route or a fully connected graph where each room is connected directly to each of its neighbours.

The other major difference is how the room and edge lists are handled. Instead of storing them in linked lists, they are stored in linear lists. The room list starts at the bottom of the 1414 byte temporary memory block, filling it from the bottom up, and the edge list starts at the top, filling it from the top down. Some quick maths suggests that under normal circumstances the algorithm won't run out of memory - but if needed I can put in an extra clause to stop the room splitting algorithm when the buffer becomes full.

For each room, 5 bytes are stored - 4 bytes for the coordinates, and one byte for the room style (Empty, meeting room, 'office space', toilets, etc.). For each edge, 3 bytes are stored - 2 bytes contain the room IDs of the rooms the edge lies between, and the 3rd byte contains the flags (contains a door, contains window(s), etc.)

The splitting algorithm has also been changed slightly. The recursion used by the original splitting algorithm isn't needed, as it doesn't really matter which order rooms are split in. The new algorithm simply runs through the room list in order, repeatedly splitting the current room until it becomes too small. Each new room created is appended to the end of the room list.

Edge handling is slightly more compelx, however. Whereas each room in the GAIO algorithm maintained its own list of edges, the new algorithm only has one global edge list. The only way to get the list of edges for a room is to iterate the full list and check each edge individually. Although this will be slower, it simplifies the code significantly. In reality the loss of speed won't matter much, due to the small size of the levels, and speed gains made elsewhere (e.g. not relying on a seperate stage to connect rooms with doors).

Room styles

As mentioned above, I'm hoping to have a few different room styles. The room style will be determined by several factors - the size and shape of the room, and how many of its edges contain doors. For each style, there will be a different filler function - the function which creates the interior of the room. For example, the filler function for a 'toilets' room will split the room into a series of smaller toilet cubicles. These will only be 'virtual rooms' - i.e. no new entries will be added to the room or edge lists.

Traps

There will also be a few traps dotted around levels. These will start out as a special, 'hidden trap' tile, and only when a monster or the player walks over them will the game decide what trap to transform them into.

Monsters and other items

These will be placed randomly throughout the level. For each item and monster type, the static game data contains the probability of the item appearing, and the range of levels it can appear on. This means that the game can easily pick a random number between 0 and the sum of the probabilities, then scan through the type list to find out what item should be spawned. Monsters will have an experience level that increases in relation to the dungeon level. I'm also hoping to include monster inventory information in the static dungeon data; so that when a Stylophone Clan member is spawned, he will automatically be wielding a Stylophone.

3 comments in forum

He discusses whether it is still practical for bedroom coders to write games: "I'm a little skeptical - I hugely think it's a very good idea for people to be able to learn to program at home ... I was very lucky - machines like the Acorn Atom and BBC Micro were very easy to program. I was in the right place at the right time; it's much harder to get started now. So anything that people like Microsoft [XNA] can do to encourage that is a good thing."

We also get to see a PDP-1, a super computer used for space research in the 1960s, which ran one of the earliest computer games, Spacewar, on an oscilloscope.

Seems like the programme was recorded some time ago - they keep mentioning the Wii will be coming out soon, and the exhibition finished in February - but it was broadcast last night and you can watch it again here

12 comments in forum