Technical issues aside, and against all modern business rules, the Exile game itself was allowed to evolve from little more than having a spaceman exploring a cavern system. We didn't know where it was going in the early stages and really just thought about new experiences for the hero and new technical features (like line of sight vision for inhabitants) as we went. Personally I believe that the best creations occur if allowed to develop at least partly in this evolutionary way rather than completely designed from scratch at the outset. It takes much longer of course to produce something this way and you are in danger of never finishing if you lose sight of the goal, but is worth it in the end.
It is possibly this natural progression of ideas between Smith and Irvin which allowed the game to become so full of features. Peter admits though that from the outset he and Jeremy wanted the game to be as high quality as possible given the technical abilities of the BBC Micro.
The novella apparanlty had some influence in the game's features but only in the final stages of development (see below).
We hit the physical limits of the BBC machine very early on in the game's development and it became a constant battle rewriting or removing code to release RAM yet keeping the speed up (though when writing in assembler it is typically the case that small code is fast code). This was good experience which most programmers learning today won't have because of the current fast processors with piles of RAM and "high level" development languages like C++ that insulate the programmer from what the processor is actually doing.In fact, nobody knew better than Peter and Jeremy about the limitations they faced and any ideas were restricted by the boundaries:
Apart from the novella we really did all of it ourselves. There were probably some useful suggestions from others but the system restrictions we were up against prevented most of these being implementable.
The implementation of the authors' ideas resulted in numerous innovative and ingenious programming routines being developed and Peter describes a number of these. For example, could one generate a map as vast as that of Exile and yet retain space for the rest of the game?
The huge map of Exile was generated by an algorithm which from an input of the xy map coordinates created tunnels, solid rock, or one of the few special blocks that could have manually defined objects in them, like creatures, doors, guns, etc. It took a long time to fiddle with this algorithm to produce a tunnel system that was all linked up and interesting, but the storage required for it was actually tiny.
To my knowledge, speech had never been used as part of a BBC game before Exile. Also, a sophisticated artificial intelligence was incorporated for the objects and inhabitants within the world of Exile which, along with realistic motions and the sound, created the 'immersive' atmosphere that Peter and Jeremy wanted. This is hidden from the player who usually does not appreciate the finer details on the final atmosphere and Peter gives several examples of these routines:
The immersive atmosphere was surely a major thing for the player, but like a swan gliding serenely across a lake, you don't see it's legs flapping away like mad beneath the surface. So it was with Exile with lots of subtle things going on that nobody is aware of. I like to think that there were some quite innovative routines like the creature strategy code that knows about noises nearby, line of sight vision through the caves, memory of where the target was last seen, etc. Oddly, the real time background speech code, which was a quite an innovation for the BBC micro, was quite quick to implement and used little RAM. But then I'm not sure anyone knew what the speech said unless they had been told before hand!
In contrast to many games developers today, software for games development was less common for those wishing to write for the 8-bit machines. For example software houses, one imagines, may have a range of routines which can be used repeatedly for subsequent releases. The most immediate example is the use of '3D engines' at the core of three dimensional games upon which different graphics are overlain depending on the game being developed. The authors of Exile created a range of programs specifically for the creation of the game as Peter explains:
It was all done by us. In those days there were no real development tools available and when for example a nose is one pixel big and one of only 4 colours there was no need for artists. It would have been near impossible to have non-programmer graphics as the interaction with the game code was critical because e.g. of the size of things fitting in holes in tunnels, and saving memory by careful positioning of the sprites in the graphics source area. Besides it was fun doing the graphics too. We had various tools we wrote in the wonderful BBC BASIC. Another example of how we saved memory was that x or y flipped versions of graphics were all reflected on the fly at plotting time, and some shapes were taken from parts of other shapes, particularly the background graphics.
In fact the graphics were a major technical accomplishment in themselves, this is particuarly astonishing when you look at the source in it's compactness (kindly donated by Peter Irvin):
The file illustrates the points Peter makes above with areas being extracted from the total graphics data and being coloured or flipped for final use to generate different forms of creatures and objects.The whole graphics file is 128 by 113 pixels and I think that the lower region including text and status graphics was discarded after the menu screen thus minimising to the extreme the amount of space taken by graphics data and freeing highly limited space for the game engine and less general routines.
This attention to efficient use of space would manifest itself again in the later Amiga versions of the game.
This game gave me HOURS of enjoyment, both in playing it and, later on, in hacking through the code. To this day I still remember (I hope) &78ED as the start address of exilemc :) The disk copy protection was first class. The disk was a dual 40/80 track format with track 1 (or 2, depending on whether 40/80 mode) being "invalid". The disk sector IDs (read using OSWORD 7F if I recall) normally inform the programmer of the number of sectors for the track and what their logical sector numbers are. Track 1 had been formatted strangely with far too many sectors and cryptic looking IDs. The data block containing all this information, when looked at as ASCII, spelt out "Well good evening, I hope you're having fun!" (or words to that effect). That really made me laugh. Following that (ie also part of the sector IDs) was another osword 7F data block which is used as the parameters for loading the next part of the code. This way without this track (which contains no real 'information' except for the sector ids themselves) the game could not be loaded. Hence this fooled virtually all disk copy programs. Alas the OPUS disk drives (have I remembered their names correctly) couldn't cope with the normal 8271 command set and so superior had to release a protection-free version. Pity. There were also 2 variants of the disk, due to a bug (I think) being fixed early on. I'm not sure what the bug was, but that's the story I heard. The result was that the memory addresses within the code were slightly different between the two versions, making cheat programs harder to write. Somewhere I have all 4 versions (2 protection schemes * 2 releases). Yes, I'm ashamed to say it, I did indeed cheat. I wrote the Exile cheat and saved game editor that appeared in BBC Micro User. As I recall they paid me 300 pounds for them! Good money back then - it more than paid for my (2nd hard) BBC Micro and it was the first time that my mother finally started to believe that I wasn't "wasting my time up there, playing those silly computer games" ;-) I did consider writing a map editor, but once I found where the map was "stored" I realised how god-like the programmers were. There's about 1.5K of bitmapped "map", stored in triangular regions. This encodes the complex bits like the ship and a few important locations elsewhere. The rest of it is generated by code. The algorithm takes X and Y as input, and outputs one a tile value (0 to 255, or perhaps less). It accounts for rock strata, water levels, rooms, corridoors, etc. Fantastic!
James was understandably impressed by the mapping code and I'm still trying to get my head around how it could be done!
After pressing him for further details James explains from memory what he was able to do with it, the most visible result being the Micro User Mapper program:
The algorithm is hideous. It has lots of things like: Get X shift left twice (*4) EOR with Y shift right add Y multiply by 2 if < 20 then .... Ghastly! It had a couple of K or code like that. Staggering. I did work out how the graphics were stored, and how to generate maps. Indeed I think I had a scrolling map viewer at some stage, although I forget now whether that was part of the published cheats. One thing is for certain though - all my notes on this are almost certainly long gone and my memory for 6502 code is poor.
He then goes on to explain about the self-modifying code which, if I remember correctly, Peter mentioned to me originally:
The disk loading mechanism was entertaining. After all the clever disk encoding it loaded the program into memory, but the entire thing is encrypted. At the end of this is a decoder routine with self modifying code (it just updates the arguments such as the #40 in LDA #40, not the code itself). This starts low down in memory (&1100 for example) and starts decrypting code byte by byte. It has no check for when it's reached the end though - it just keeps stepping through memory until it reaches itself at which point it "decrypts" the decrypting routine, turning it into a jump statement to start the game proper. To decode it you have to copy the decryption routine elsewhere in memory, but update both your copy and the original so that the decryption works. With PC beeb emulators I'm sure this all becomes trivial as we can just set a break point when the program counter reaches a certain point. Takes half the fun out of it though - to me cracking the code was always a significant part of the fun (sometimes more fun than the game itself). Kevin Edwards was the king of copyright protection and the only game author that truely defeated all my attempts :-) He had the bright idea of encrypting using the 1MHz hardware timer values, the code doing the encryption, and the program counter. This means that the code cannot be modified, it cannot be moved (as it's position dependent) and it cannot be easily simulated due to the real-time nature of the hardware clocks. Truely a genius. It'd be interesting to see if any of the beeb emulators can work with his software.
Even given that emulation-compatible versions exist I'm not convinced that the protection mechanisms are preserved. Also the novella mechanism has been hacked out of one disk image so I wonder if all the data has been preserved or if this clever decryption protection mechanism has been circumvented somehow?
I no longer have the hacked Exile version which worked with !65host for the Acorn Archimedes but perhaps the person who posted this version to the newsgoups back in the mid-'90's ('Dan') had modified the program extensively as !65host was notorious for not being a comprehensive emulation of the BBC Micro!
Finally I'd like to thank James for this information.
The 'immersive atmosphere' of Exile was surely enhanced from the outset by the inclusion of a novella with the package. Extracts will be added to the plot page but briefly this depicts the demise of a crew of a military starship from Earth which is sent to investigate the planet to which an Earth criminal, Triax, was exiled years before. This demise is the work of none other than the evil Triax.
Suprisingly though, the idea for the inclusion of a short story was to discourage piracy of the game. That is, before playing is possible the player is asked to type in an extract from the novella (another feat of programming memory efficiency!). Peter explains the lengths, he and Jeremy went to in trying to combat the piracy issue:
The decision to have a novella came about because it was thought it would reduce piracy and add perceived value to the game. Finding ways to prevent piracy was a big thing at that time for developers. I remember seeing somebody demonstrate how to copy Starship Command (an earlier game of mine) on a national TV programme and was a bit miffed to say the least. We even developed an anti piracy system where we could manually scratch a floppy disk with a needle and had a program that worked out what disk sectors were unreadable and based on this store an encrypted image of the game on the undamaged part of the disk. Unfortunately this would have been a too expensive and perhaps unreliable for production duplication though.
Therefore the novella was written to accompany the developing game which one could argue is less restrictive than attempting to write a game according to an accompanying story. Exile ˜ The Story was written by Mark Cullen in conjunction with Peter and Jeremy. The story, at the time, reminded me of the science-fiction blockbuster film 'Aliens' and I put this to Peter:
The novella also helped us finalise what had to be done to finish the game in terms of design features. The Exile story came about with discussions with a school friend, Mark Cullen, who had done an English degree and written various things including some material for TV. He fleshed out the story and patiently made changes necessary to match what was in the game. Films like Alien did have an impact, I guess, since they were such powerful influences at the time. I guess the plot is really more like "Forbidden Planet", but then this was based on Shakespeare's "The Tempest" - where does it really all start?
Whatever the inspirations behind the story, it almost managed to give the player a sense of 'urgency' about the job at hand! To my knowledge, the only other game released with a story, was the other great BBC epic Elite in its 1984 release.
Although Exile appeared to push the BBC to its limit, the authors indeed had more ideas which they were prevented from implementing. Equally, any suggestions from some of the people credited in the back of the Exile manual were usually non-achievable. I asked Peter if there was anything specific he could remember:
Well I suppose that if we had hires colour graphics and a faster processor and ten times as much memory the game "finish" would have been much better, but then all the other games would have been too. The underlying game play would have remained though. It is difficult to say what Exile would have become with more system resources on the original machine, the BBC mirco. We would have felt obliged to push the machine to it's limits whatever.
It has been mentioned more than once on the Acorn newsgroups that the ending was disappointing and people would liked to have been rewarded with more after such an immense accomplishment.
Certainly by looking at the solution, a huge amount of playing is required just in following the instructions of the fan's who documented their methods. However, the rewards surely come from the learning and overcoming the obstacles.
Peter has also mentioned that given more memory, the terrain variation seen on later 16-bit versions could have been implemented on the BBC given more memory. Still, this is perhaps a minor modification, although it makes one wonder the BBC Master with its greater memory capacity could have achieved this.
In summary, I'll include a few words from 16-bit co-author William Reeve regarding techincal achievements:
My take is that Exile was the pinnacle of what could be achieved with the BBC. [Actually Pipeline was right up there too but in different ways]. It was actually an inefficient process - because so much effort went into optimising the code and being clever. The 6502 is, to this day, an incredibly efficient processor and Exile exploited it to the hilt.
Superior Software really was the best publisher on the BBC by then. They were publishing all the best quality games and had a genuine professional enthusiasm for Exile and could see it's potential. They had back cover or double page adverts in most issues of the magazines for their games releases. We found both Richard and Steve Hanson very supportive.
Back to Exile tribute index page
Last modified 11/02