Attached to this post is a computer role-playing game I wrote on my BBC Micro over the course of several years in the late 1980s. It requires a double-sided disk drive, and has only been tested on a 'stock' BBC Micro model B with Acorn DFS. To save your progress, you will need a separate formatted disk (the game disk can be run locked). There are some minor bugs, but the game is complete and winnable. Simply auto-boot (shift-break) to begin - full in-game instructions are included. Note that the name that appears on the first title screen is not mine.
The game is mostly textual, but drops into graphical mode for combat and in some special situations. I (humbly) think it was near commercial quality for the era, but it would never have been possible to sell it for reasons that will be obvious from the first title screen.
Some of the default keys may not make sense in an emulator - they can be redefined on the introductory screen.
I will write some (spoiler encoded) hints, technical details and commentary in additional posts. I look forward to discussion and answering any questions, although I have probably forgotten some of the details of the game. I have an additional disk of utilities, a map, and a disk of VIEW format documentation that I will post separately.
Like many other software developers that had microcomputers at home in their youth, I feel incredibly fortunate to have been born in a window of time when computers were becoming affordable and were still accessible enough that programming was encouraged. This game is therefore dedicated to my parents, whose purchase of a BBC micro proved the genesis of a lifelong hobby and career.
The game attempts to fuse a traditional CRPG with the extensive text and freedom of a text adventure. It is quite difficult to win for several reasons:
- Although the game looks like an RPG, progressing and successfully completing the game requires some text adventure style puzzle solving, with the associated text parser issues.
- The combat can be particularly unforgiving. The last battle is almost unfair in this respect - if you are lucky, it can be easy, but otherwise it is deadly. This is however true to the rules the game is based on.
The game runs in MODE 1, and is written almost entirely in BASIC, except for a small bit of assembly that is used to word-wrap text (this was the only bit of serious assembly language programming I have done - I recall the resulting code was just over 100 bytes). I designed the user interface having only seen a windowing GUI 'over the shoulder' and in magazine screen-shots, so it will seem familiar and yet disjointed. The game uses a lot of low-memory areas for game data (my original motivation for buying the Advanced Programming Guide was to get the memory map!) The disk drive is used extensively to swap code and data in and out of memory, in order to provide an experience that would not be possible otherwise. If your emulator allows it, you will find it beneficial to eliminate simulated disk access delay. I find the game interface to be more responsive at 1.5x or 2x emulator speed.
- The targeting reticle can be left on the screen (e.g. by targeting an empty tile with a spell).
- The opponent in the final battle doesn't use its attacks properly after a few rounds of combat.
- Some of the tiles on the edge of the final opponent's body are not considered part of the body for the purpose of determining if a player is offered the chance to attack after moving.
- Attempting to save a game on a locked disk will display an error and then fall out to the BASIC prompt.
- Some of the special actions don't respond properly to changes in the environment.
- Players that resist fear in a combat round and then wait will be made to pass a fear test again in the same round.
On the first title screen, press the 'R' key to enter debug mode. You will be prompted for the starting room number (by default, this is room number 2 - see the map attached to another post). In debug mode, the game behaves in exactly the same way except that the room number and the turn number are displayed in the title bar.
I would be delighted if anyone was to pursue further development on the game, or wanted to use the game engine to make a new game in a different setting. Some features I would have liked to add are:
- A simplified combat interface - it should be possible to attack an enemy simply by walking into them.
- An alternative (non-combat) interface that removes the menu bar and replaces it with a command-line text entry area, similar to a text adventure. This would also naturally incorporate the existing 'special' commands, and have a terminal-like auto-complete feature.
- AMX mouse support.
- Moving the menu bar to the top of the screen and making it look and behave like a 'proper' GUI menu bar. This would allow the text area to expand to the bottom of the screen. I suspect that sideways RAM would be required to act as a backing store to make the menus display over the text properly.
- Sound and music. I have no ability in this area, and the game currently uses a lot of low-memory areas that are normally dedicated to sound buffers etc.
- A custom font for the in-game text, and a slightly larger line height to ensure that there is always a gap between the descenders on one line and the ascenders on the next line.
- ROT13 minor spoiler: Gur ACPf qb abguvat nsgre wbvavat gur cnegl. Vg fubhyq or cbffvoyr gb gnyx gb gurz, naq gurl fubhyq cebivqr pbagrkghny vasbezngvba.
- There is a 'winning' screen, but no epilogue that ties the events of the game to the larger story. The game was intended to be just the first part in a series, but there is no character advancement like a traditional role-playing game because of the limited time-span that the game takes place in, and because I wanted to shift the game away from numbers and towards an adventure experience.