More war stories from the depths of time! My first job in the industry was main programmer on Amberstar, a big role-playing game by Thalion Software for the Atari ST.

Amberstar was developed in a very interesting way. It was the brainchild of Karsten Köper, who before joining Thalion had developed a role-playing game called Mythos for Atari XL and Commodore 64.

He had spent about eighteen months developing a set of editors in GFA BASIC, a very powerful BASIC for the Atari ST that was quite popular in game and demo development. (Fun fact: Karsten is mentioned alongside Eric Chahi on the GFA BASIC Wikipedia page.) These editors allowed him to create data for any role-playing game in any setting - a bit like GURPS for computer role-playing games. Characters had attributes like "number of ring fingers", for potential sci-fi settings.

So what I received when I started was a description of each screen in the game (typical for this kind of role-playing game, it was very GUI-driven), and a description of the binary data formats of the files that Karsten's tools generated.

And that was it. I spent about a year writing a program on Atari ST that could handle these files while Karsten created all of the maps, quests, items, etc. and the artists created all of the art (from, if memory serves, lists that Karsten made using his tools).

The interesting thing was that a two man team based in Hamburg was doing the exact same thing for the DOS version. I met them at the start of the project, and I talked to them once during development over the phone (to discuss something I was doing in code that was, for once, not coming from the data), but that was the only contact we had.

After a year, we had the same game for two different platforms. I'm still impressed that this worked out so well. Arguably it's an inefficient way of porting, since the DOS version required twice the programming manpower as the ST version, and the Amiga port was done the "traditional" way. But it still feels very different from any normal approach to game development. Of course, these days you can achieve the same effect using RPGMaker.

We used the same system for Ambermoon, the sequel to Amberstar. Ambermoon was developed for the Commodore Amiga, but we kept editing the data on Atari STs.

We made some changes to the underlying system. I came up with a couple of those changes - if I remember correctly I made some improvements to the conversation system.

This time two people created the data for the game. Since we didn't have a network, this meant putting certain core files on a floppy disk, and whoever had the floppy could edit them.

At the end of 93 things were going downhill with the company and people started quitting. The remaining developers, me included, went to Blue Byte (actually we just changed the name on the door). In order to "quickly" deliver a game to them, we decided to make another role-playing game using the same editor system. This turned into Albion, and took two years and an enormous amount of crunching.

(Careful readers may ask: Hey, did you take key technology that represented years of development from one company to another? The answer is: Yes, we did. Yay the 90s.)

Everyone except me switched to PCs for development (and we got a network). Since the game was being developed for the Commodore Amiga, I was using that, until Commodore went bust and the entire project switched to PC and C (from 68K assembler which is what I'd been using since 1991).

But wait, you ask again, you were using PCs, but those tools were written in a custom BASIC for the Atari ST! How could that possibly work?

The answer is: hardware ST emulators. Every developer who used the tools had a special card in his PC, and we switched from DOS to GEM and back. And to make things weirder: the emulator was entirely done in software: the hardware just contained a chip with the ST ROM (TOS) and perhaps a peripheral interface or two.

We made a lot of changes to the system for Albion, often driven by me, to allow us a lot more flexibility in our content. That flexibility was not always used by the scenario designers, which was a very valuable lesson.

After spending the first 5 years of my career doing extreme data-driven development like this, and being a designer as well as a programmer, I have a very special relationship to both data-driven development and hard-coding. I think I am now pretty good at creating data-driven systems, but I am also very aware of the advantages of hard-coding. Or, rather, mixing design and programming.