You play as Detective Chuck Jones (no relation to the animator of the same name), a rough and tumble LA cop in the year 1976. While involved in a high-speed chase you have a car accident and are heavily wounded. To avoid death you are cryogenically frozen, many years in the future you are unfrozen and must track down and apprehend a dangerous criminal in a strange time by flying around the galaxy in your rocket powered El Camino, meeting interesting characters and solving puzzles.
This article was originally posted on my blog.
Let's start by going back to the late 1970s, shortly after Chuck Jones himself was frozen. In 1977 a bunch of guys at MIT were working on the groundbreaking text adventure game ZORK. ZORK was written originally for the big mainframe computers at MIT such as the DEC PDP-10. Eventually these guys decided to form a company called Infocom in order to sell their games, but they had one big problem: There were very few mainframe computers in the world and the people who owned them were generally not interested in buying Video Games. If Infocom wanted to sell games, they would have to make them run on the small personal computers that were entering the consumer market at the time. However this presented an interesting challenge: the mainframe version of ZORK required 1MB of memory (1 MB = 1024 KB) but the personal computers of the day often had less than 32KB of memory, so how on earth were the going to get the giant world of ZORK on a personal computer!? The answer: A custom scripting language! The guys at Infocom were some seriously smart dudes and realized that most of the core logic of the game could be broken down into a series of game specific instructions such as move object to room, write message, etc. each one of these in game instructions could correspond to tens or even hundreds of machine code instructions making the game tiny. They essentially created a Virtual Machine, which they called the Z-Machine which was highly specialized for playing text adventures. The program to execute the Z-Machine instructions could be very small, and it being the only part of the game that was specific the computer it was running on, made conversions of the game to other systems a breeze. Because writing Z-Machine instructions by hand had many of the drawbacks of assembly code, Infocom also created a compiler for a Z-Machine high level language which made it easy to implement new games.
Now what does ZORK have to do with Chuck Jones? Well everything actually. In Chuck Jones: Space Cop of the Future, I use the exact same approach. I created a Virtual Machine which executes byte-code that is specifically designed to play graphical adventure games and in doing so I save time, memory and disk space. I call this somewhat unimaginatively: The Chuck-Machine! On top of this I built a high level but specialized language for controlling what happens in the game. Well at this point, if you're brave enough, we'd better dive into the implementation details.
The above diagram gives a simplified overview of how my interpreter is structured, we have several processes each with their own set of registers which are cooperatively juggled on the single CPU that the game is running on. Additionally the interpreter maintains a global list of objects, rooms and sounds that are dealt with by the scripts as well as provides 128 global registers for inter-process communication. Now lets move on to the language itself.
Here's a screenshot of me editing one of the scripts in the wonderful Notepad++ editor. The language is very much like a structured BASIC but with quite a bit of influence from C and C++. Because of the design of the underlying Chuck-Machine the language manages to compile to usually one or two byte-code instructions per line (with the obvious exception of macros and procedure calls), this is because complex operations can be built into the Chuck-Machine itself as special instructions.
Once a script is written it is compiled using the somewhat confusingly named BASM tool (the Bytecode ASseMbler), because this tool is actually a compiler and not an assembler. BASM is written in C++, when I wrote BASM I was moving really quickly and as such it's pretty inelegant and is a bit of a hack. Despite this it works.
In summary creating a custom language doesn't have to be that complicated and you can save yourself a lot of time and memory if you do it right.
Check out my new blog, its chocked of technical information for those who are brave enough.
No articles were found matching the criteria specified. We suggest you try the article list with no filter applied, to browse all available. Post article and help us achieve our mission of showcasing the best content from all developers. Join now to share your own content, we welcome creators and consumers alike and look forward to your comments.