Twin Kingdom Valley
| Twin Kingdom Valley | |
|---|---|
 | |
| Developer(s) | Trevor Hall |
| Publisher(s) | Bug-Byte |
| Platform(s) | Acorn Electron, BBC Micro, Commodore 16, Commodore 64 and ZX Spectrum |
| Release | 1983 |
| Genre(s) | Text adventure |
| Mode(s) | Single player |
Twin Kingdom Valley is a text adventure game with animated pictures (on most formats) for the BBC Micro, Acorn Electron, Commodore 64, Commodore 16 and ZX Spectrum. It was released in 1983 by Bug-Byte Software.
Gameplay
Twin Kingdom Valley is a work of interactive fiction where the player enters commands such as "take jug" at a command prompt and is told the outcome of their move ("I have it now"). Each such command takes up one unit of time, during which other non-player characters will also move and take actions.
It was one of the first text adventure games to have active non-player characters.[1] The characters are interactive, and have their own personalities: some are friendly, and will follow and defend the player, while others are hostile. Witches and kings are complex characters, whereas gorillas and trolls are simpler. Battle sequences have additional features including weapons which can be dropped, broken, thrown or taken away by enemies.
Plot
The main character of this game, referred to as "you" by the game engine, is a treasure hunter. The player starts the game at southern edge of the forest kingdom, with few possessions. An early encounter with the innkeeper of "The Sword Inn" may persuade the player to rent a small log cabin from him. In the cabin are some very meager supplies, such as a plain jug.
To progress through the game, the player must determine which characters to regard as friends, and which as foes. Some characters, such as a gorilla who attacks the player with a wooden club, are clearly presented as foes, while others are ambiguous.
There are two kingdoms - a forest and a desert - separated by a deep canyon. Each kingdom is ruled by a king, and kings do not get along with one another. The player is told that the situation have gotten worse recently, and a royal from the forest kingdom is missing, the crime being attributed to the desert king. With two rich kingdoms at war, it is suggested that the player could take advantage of this and loot treasure from both sides. As the game progresses, the player finds it a challenge to transport spoils back to the log cabin, and is forced at times to choose between carrying a treasure and carrying a weapon, both types of object being at risk of theft if left unguarded.
The plot develops over time. In the original BBC Micro game, there were a limited number of locations and graphics. Some additions appear in the C64 version, though the plot is largely the same. The modern smartphone edition of the game yet more locations and some new plot twists.
Development
Concept
The game was inspired by the original Adventure by Will Crowther. The original game engine was written in 6502 assembly language. The game was then ported to Z80 for the Spectrum. The newer versions (for Commodore 64 and Spectrum) have an extended game. The game set out to add a level of realism through the addition of images, and complex characters.
The beginnings of the game were more of a "peer pressure challenge" than a commercial venture. At that time, access to the "massive machines" needed to run the original adventure were limited. The thought was: surely this can be done on a "home computer", somehow. The slowness of high level language code (Basic) on home systems ruled that out as a path, and there was no access to a FORTRAN compiler at the time. That's why assembly was chosen. Few people had run the original, and (having graduated) those students who had access to university equipment capable of running the game, had lost that privileged access, and a fading memory. So: The elements recalled (teasingly) resembled the original, with a road, a building (containing useful items, such as keys and a lamp) being repeated. The building is in the forest, with a spring nearby. However, beyond this "teaser" that it is some kind of clone, the similarity ends. The plan changed to "why copy, when you can do better".
Rather than just modelling an underground cave, the challenge was to model a larger world, with many above ground, underground, inside and outside locations.
A "somewhat medieval" era was chosen for the game, allowing elements of mysticism. All combat was designed as basic hand-to-hand style, with the player and other characters taking turns to trade blows, Turns are always initiated by the player's typing, rather than occurring in real time. If the player attempts to flee from combat, the opponent is permitted one attack before the player moves. The player's behavior is modelled in the same manner as the characters. Like similar games, characters have various limits, such as their maximum health and rate of healing, and the carrying capacity.
Graphics
A major section of the software is a custom graphics language, which is an early scalable vector graphics format. Hundreds of images of objects and locations are drawn in the game using this custom tool. Perspective of a limited kind is achieved by permitting images to be drawn "scaled down" within another image. For example, a castle model would be designed for close up view, but could also be drawn as a subroutine for a distant castle in a desert. The graphics speed was about 10 polygons per second, so the game could not afford to write background polygons and over fill. Images are just created by flood fills, such that each screen pixels is filled only once. A modern PC (using an emulator) can paint these pictures instantly, but the original game owners would need to wait three or four seconds for the screen to paint.
The graphics commands had to be heavily compressed, due to the limited memory space budget. Consider a line drawing call, which does a "draw to" from current position, with a color and new x,y coordinates. If you use 6502 to: load register x with the x coordinate, load register y with the y coordinate, load accumulator with a color, and then call "Draw line", you have used up 9 bytes. If there are a total of 1000 such lines in all game images, then that would be 9K gone. The actual memory used for a draw command in the game is 2 bytes.
To draw and fill an outline, 3 basic commands are needed: Move, Draw, Fill. A move (to start of shape) followed by drawing to each point on the outline, until the shape is closed, then filling within the shape. Draw and fill need a color for the line. All of Move Draw and Fill need a coordinate. To decode this efficiently, just 2 bits are needed to resolve "Move, Draw, Fill, "any other instruction" in an assembly language.[2] An extra bit determines if the command has absolute screen coordinates, or a relative position. 3 bits give a choice of 8 colors, and finally 10 bits give two 5 bit x,y coordinates.
The other commands (not needing coordinates) included: Calling a subroutine, ending a subroutine, drawing a circular arc (center at the last moved coordinate) etc. Complex images, such as a cabin made of many logs, use a loop instruction, similar to "for loop" in C, with a constant "loop limit". The assembly language has no concept of variables, and no branching instructions.
Game engine
The game has several "micro databases" of information, representing the locations, objects which can be used, various creatures, and other data. The game engine runs a simulated world for these items. A small AI module allows the non-player characters to make decisions.
The location engine has some features to save memory. In most locations there are just a few words, but a detailed (bit packed) "exit database" is interpreted to make longer descriptions. These descriptions can vary as bits are set and cleared for "locked and unlocked" doors. A location with about eight lines of text describing it may be less than 30 bytes of data. Words used in the game location database are stored as a single byte per word, which look up into a 256 word list, and as a result many words are reused several times.
For example, "You are by a babbling brook, North you can see a stream, South you can see a road, North West is a deep river". The words "You are" are added by the game engine. "by a babbling brook" is just 4 bytes of data, a 5th byte encodes the length (4) of the message in words. The location has 3 exits, which are coded as 2 or 3 bytes per exit. Byte 1 has the compass direction plus up or down (6 bits for N,S,E,W,U,D). An additional bit marks "special exits" such as locked doors. An additional byte then defines various bits for "locked/unlocked" or "can see through, cannot see through" etc. Finally a byte for the destination. The first word of the destination is then skipped, so: If "North" led to "By a stream", the word "By" is omitted, and the words "you can see" are added, giving "North you can see a stream" using just 2 bytes.
All of this compression was needed to fit the game within the 32k limit or the original BBC Micro system. 10k is "lost" as the screen buffer, so the game memory is down to 22k from the start. With some of the memory needed for "variable space" or "stack", the available code are in such as system is nearer to 20k. If the game had 200 locations at 30 bytes per location, this would be 6k. Even this would leave almost no space for game code, especially graphics. The original versions of the game had fewer than 200 unique locations, for this reason. There are roughly 180 locations in early editions (such as that of the BBC Micro), and 190 in later editions (such as the Commodore 64 version). Other game tables (such as those for creatures or objects) are much smaller.
The game has a small "data reset" block, which re-locks doors and other objects when the player starts a new game. In later versions (such as C64), extra memory allowed for some longer messages in "plain text" for special game events and puzzles.
Because creatures can hold objects, all creatures are treated as "special locations" by the game engine. An object has a single byte "location" which can be a "room" or a "creature", and all locations above 200 are reserved for "creatures", or other special location codes (such as "broken").
Continued Development
The game was in active development again in 2006, due to the availability of new platforms. The game engine has been ported, from the original 6502, into Java, with some game design tools in C#.
Reception
Reviews were generally positive. The "World of spectrum" link has many screen captures of magazine reviews of the game. Here is the ratings given by Crash Magazine, for the spectrum version:
- Atmosphere: 9
- Vocabulary: 7
- Logic: 7
- Debugging: 7
- Overall value: 8
That review comments on the peculiarities which occur, when porting games from BBC micro or C64 to spectrum. The original BBC version had been reported to Bug Byte as a "No. 1 hit" by one magazine, reportedly based on sales figures. There is little or no information available on how magazines at the time compiled such charts. However, the sales were clearly significant enough for the publisher to request the various ports listed, and to run many full page adds for the game.
Letters were sent to the game publisher, in a time before "internet review systems" had been created. These are long lost, but did include generally positive comments. Most notable among them was a letter from the father of a blind child, who was able to play the game, thanks to the included speech synthesizer support.
External links
- Official website
- Twin Kingdom Valley at SpectrumComputing.co.uk
References
- ^ Gunness, Jacob. "Interview Trevor". Classic Adventures Solution Archive. Retrieved 1 November 1999.
{{cite web}}: Check date values in:|accessdate=(help) - ^ Gunness, Jacob. "Interview Trevor 2". Classic Adventures Solution Archive: Twin Kingdom Valley - on the move. Retrieved 1 July 2006.