Twin Kingdom Valley

• Title — Twin Kingdom Valley • Developer — Trevor Hall • Publisher — Bug-Byte • Released — 1983 • Genre — Interactive fiction • Modes — Single-player • Platforms — Acorn Electron, BBC Micro, Commodore 16, Commodore 64, ZX Spectrum

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

The main character of this game, referred to as "you" by the game engine, is a treasure hunter. The player starts the game at the 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 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 the kings do not get along with one another. The player is told that the situation has got 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 adds more locations and some new plot twists.

section

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" (by the standards of the day) 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. 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. The elements 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, but beyond this teaser that it is a kind of clone, the similarity ends. The plan changed to "why copy, when you can do better". Rather than just modelling a cave, the challenge was to model a larger world, with many above ground, underground, inside and outside locations. Twin Kingdom Valley features 175 rooms. A somewhat medieval era was chosen for the game, allowing. 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.

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 pixel 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. To draw and fill an outline, 3 basic commands were 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. 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.

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. Them comes 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 of 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").

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