Sunday, April 2, 2023

POWER PLAY magazine: Realtime Games interview

 Fast-paced reality

Where the programmers of »Realtime Games« are at work, the processors smoke. Fast 3D graphics and thrilling games keep home computers busy and players in suspense

In the north of England, a good three hours' drive from London, lies the small industrial city of Leeds. Here you will find coal mining, metal industry and a games software house. Leeds is the home of »Realtime Games«, which recently shone with »Carrier Command». Boris Schneider visited the programmer group during a holiday in England. »That was one of my wildest interviews,« he moaned when he was back in Germany, »the four programmers kept talking at once, contradicting each other and suddenly all agreeing again. It can no longer be reconstructed who actually said what. But it was a lot of fun!.«

The two adjoining offices, which now offer a lot of space for the six programmers, look untidy and chaotic - just like programmers' offices. The four oldest members of Realtime, Andy Onions, Ian Oliver, Graeme Baird and Andy Beveridge, take a long break from work and willingly divulge the history of Realtime Games.

When asked when Realtime was founded, there is an immediate, razor-sharp answer that shouldn't be taken seriously: On May 8, 1984 at half past ten in the morning. At that time, Andy Onions and Ian Oliver had just finished their computer science studies and Graeme Baird still had a few semesters ahead of them.

The three friends were crazy about an arcade tank game that was indexed* in Germany. The game was the first arcade machine to offer smooth 3D vector graphics. Andy, lan and Graeme were dying to write an adaptation of this game for the Spectrum. They started at Christmas 1983 and finished at Easter 1984. When the three wanted to present the game at a trade fair for the first time, they had to come up with a name for the game and the company within a few hours. They called the game »Tank Dual«, the company referring to the fast 3D game »Realtime Games«, translates as »Echtzeit-Spiele«.

The three of them started with just one Spectrum and a simple cassette recorder. Shortly before the end of development of Tank Duel, when the assembly on cassette took up to fifteen minutes and it was so easy to lose patience, they borrowed a hundred pounds and bought a Sinclair Microdrive, a fast endless cassette drive

The three together raised enough money to produce 1000 game cartridges. Enough money came in from the sale of the cassettes to produce another 1000, and another 1000 and more. They were able to sell a total of 7,000 cassettes and earned a good amount of pocket money. They had developed a taste for professional programming: »We then started very quickly. to develop 'Starstrike'.«

Starstrike was again based on an arcade machine, this time the prominent »Star Wars«. In order to be able to write the program quickly, Graeme took a year off from the university. He did not attend the lectures and wanted to make up for the missed material later. However, he never really finished his studies.

It took the three of them a full six months to complete Starstrike, or as the Realtime programmers point out, -only- six months. In order to finish so quickly, they allowed themselves the luxury of a second spectrum with a microdrive. On November 23rd 1984 Starstrike was released for the Spectrum.

Starstrike became a resounding success. There were only positive test reports, the program sold like hot cakes, and Realtime was established as a technically outstanding software house. »Until then we were working in a particularly bad area, where there were dozens of stray dogs, garbage on the streets and other inconveniences. With the money we earned through Starstrike, we first got better offices«. Incidentally, Realtime is still based in the offices they moved into in January 1985.

Next, the three sat down to a CPC version of Starstrike. But the success of the first two programs made things a bit lazy, and it took another six months before the CPC version could be sold in June 1985. Then there was silence around Realtime for a year. It wasn't until April 1986 that we heard from the programmers again in the form of »Starstrike II-, the first game on the Spectrum to use 3D graphics with filled areas. »Why did this take so long?« »We made so much money with Starstrike that we lived off it for months without doing anything big. When we ran out of money, we rushed to write Starstrike II. At first we only wanted to program a line graphics game, but after a month we found out a trick for realizing the filled areas with sufficient speed. So we threw everything in the wastebasket and started all over again. Starstrike II ended up looking very different. than we imagined at the beginning.«

After the first two real-time games were actually just copies of well-known arcade machines, Starstrike II was to become its own game. The basic concept was similar to the first Star-Strike; several action scenes were held together by a background story: »Because the 3D graphics are a bit slow on the 8-bit computers. we puzzled over the individual sequences for a long time. They should be graphically impressive, but shouldn't use too many objects. Otherwise they would have become too slow to be playable.«

As it became more and more difficult for a small software house like Realtime to maintain sales and to supply all dealers, the rights to the CPC version of Starstrike II were sold to Firebird Software. At the same time, Firebird commissioned Realtime to program the implementation of a new ST game: »Starglider«.

»The Spectrum version of Starglider was the first game that we wrote with a professional development system consisting of a PC with a special Spectrum assembler. At first we couldn't believe how fast programming was with this PC.«

Realtime is not the only software house that programs 3D games. Are there other 3D specialists that Realtime admires? »Realtime is not the only software house that programs 3D games. Are there other 3D specialists that Realtime admires? »In our opinion, the only game that makes the best use of 3D graphics is »Driller« by Incentive. The gameplay is well thought out. Actually, Driller is just an adventure, but it's exciting like an action game. Since the reaction is not so important in Driller, the slow 3D graphics are completely sufficient. We're faster, but our games aren't so well matched to the graphics.«

On 8-bit computers, 3D graphics have only gotten faster and better over the years. Has the limit been reached there and can an increase be expected with 16-bit computers?

»We've only been working on 3D routines for a good five years now. We know pretty well what a computer can do in this area. On the Z80 8-bit computers (CPC. Spectrum) we have reached the limit of our abilities. We're currently working on a 3D system for the C64, but that won't bring anything significantly new either. The 3D games market will be fully 16-bit in the next few years.

The graphics at Carrier Command are probably not much faster. We only know a few people who have written fast 3D routines for the 68000, and none of them are faster than us. We could still tune our graphics routines a bit, could also use even more complex objects, but for other reasons we have now reached a limit:

Carrier Command is a real killer program for the ST (and even more so for the programmers). There's so much in it. When you see Carrier Command, you think: My God, is the 3D fast, that must eat up all the computer time. Incorrect. Even if there is nothing to see on the screen, we manage a maximum of 17 frames per second. The rest of the computer time, that is more than 50 percent, goes to the game strategy on it. The enemy carrier's tactics, the island's supply network, the movements of several dozen vehicles, all of this is simulated in real time and takes up about half of the Atari ST. In theory, the graphics could be more than twice as fast.

Well, there will be improvements in 3D graphics, but only very small ones. In a year we'll be maybe 20 percent faster, but we can't expect miracles; Especially not if the game itself is very complex and requires a lot of computer time.

Today we could program an absolutely fluid 3D, 25 frames per second, with many complex objects, but then no process more left for the game at the moment.«

All of this sounds a bit illogical, as it took programmers around the world more than five years to properly exploit the 8-bit computers. The more complex 16-bit computers are supposed to be exhausted after just two years? »The big difference between 1983 and 1988 is that computers in general were still new and the programmers were very inexperienced. Today, most 16-bit programmers have several years of 8-bit experience . You already know a lot about effective programming. There won't be another quantum leap like the one on 8-bit computers.«

What's the real-time programmer's secret to being so at the forefront of 3D? -We all studied computer technology. Many game programmers only have hands-on experience gained from »hacking« on their machine. They only know what they need to know about the computer. We, on the other hand, have a deep theoretical background. This gives us a head start when solving hard math problems such as those encountered in 3D graphics routines great know-how advantage. You can either learn stuff like that at university or you can spend a few years reading the right books, like Jez San did, for example, who programmed »Starglider« on the ST.

Many of the ungraduated programmers want to make life easy for themselves and are looking for programming shortcuts. The Americans are particularly bad at it. With them, every program has to be reloaded. If the program doesn't access the diskette at least ten times, something is wrong. Much of the stuff can be packed into memory without any problems, but the American programmers are simply too lazy to go this somewhat more difficult route and to keep their program as compact as possible. The programmers are particularly lazy on the Amiga. Almost all Amiga games could also be realized on the C64. You use the additional memory and the better sound and graphics chips, but the gameplay still has 8-bit quality. The programmers not only have to make better use of the special chips, but also the processor, write more complex programs, exploit the true potential of the computer.

Of course, the naïve question arises as to how Carrier Command could use the ST according to the above criteria when they are currently working on a Spectrum version. The question is initially followed by wild laughter, then the cautious counter-question »Is that a trick question?« and then the detailed explanation: »There is a big difference between converting a game from the Spectrum to the ST and just making the graphics a bit nicer, or converting a subset of an ST game to a Spectrum.

At Carrier Command, we only implement those parts that also work on the Spectrum. At first glance the two versions look very similar, but the Spectrum version is so much simpler than the ST original. On the ST version of Carrier Command, a whole lot of memory goes for details on it. For example, the cannon on the carrier moves, the lock gates open and close and the volcanoes spit out small cubes. The Spectrum version will do without all these funny details. Also, the island network is much simpler. On the ST, we use a realistic, complex model to manage the islands, generate supplies, and ship back and forth. On the ST, this part of the program needs a whopping 64 Kbytes, including all tables. On the Spectrum we squeezed a simple mini version of the island network into 768 bytes. If you only play the two versions for a few minutes, you will immediately see that the Spectrum version is missing a lot.

There will likely also be a C 64 version; it will then even have to do without 3D graphics and will probably become a 2D sprite game. However, we do not program this implementation ourselves.

By the way, the exact opposite can be said of Starglider. We converted the ST version of Starglider absolutely true to the original, with the exception of the voice output, on the Spectrum and the CPC - and then we still had free memory! So we added special missions and even invented new objects and enemies. There is actually more play in the Spectrum version than on the Atari ST.«

Why is the C64 so bad for 3D games? »Mercenary still has the fastest vector 3D on the C64 to date. We are currently working on a special 64 3D system that should be a bit faster. But not much, because the C64 has just half the computing power of a Spectrum. On the Spectrum we manage a maximum of 37,500 pixels per second, the C64 is below 20,000 pixels per second.

But the C64 has other quirks; it takes forever to clear the screen. The fastest screen-clearing routine we can imagine does just 47 times a second. With each image, a 47th of a second is lost just for deleting it. That slows down the whole 3D routine enormously.

Then there is some computing work, an area in which the C64 is not the fastest either. Where are the 3D coordinates? Which lines are hidden? Where are the objects moving to? If you don't program very simple things there, you'll quickly be at one frame per second or slower.«

he fight between ST and Amiga is still raging between computer freaks. Which of the two computers is better suited for 3D games? »In 3D games, the Amiga is no faster than the ST. The blitter can only help us with screen blanking, and the processor that has to do the 3D work is actually slower than on the ST. The Amiga's 32-color mode is useless to us. since 3D would be much too slow. We can use a maximum of t6 colors. So the two computers are practically equivalent.«

What do programmers who strive for »true« 3D think about arcade games like »Space Harrier« and »Out Run«? »This semi-3D, where sprites are enlarged and reduced, is quite OK for certain action games. They couldn't be realized with real 3D. The advantage of semi-3D is. that the objects look much nicer because they are painted and not calculated. On the other hand, you can never fly in all directions or view an object from all sides in a semi-3D game. So the games are very limited. Semi-3D is great for arcade machines, but it probably won't catch on on home computers.«

When asked what the four of them think of Archimedes' new computer, which is said to have incredible properties, there is a veritable muddle of language: »A heap of rubbish - It's damn fast - A very, very, very , very fast computer - Not as good as a decent 80386 processor 24MHz PC - but much cheaper - The best computer when you compare price and performance - The processor isn't great - Yes , they oriented themselves too much on the 6502, took over all the illogical properties.«

To stop the confusion, let's ask how fast Archimedes is in 3D things. The answer: 900,000 pixels per second, with 256 colors at the same time. That's about 25 times faster than a Spectrum, twice faster than ST and Amiga. which then only display 16 colors on the monitor at the same time. »With a reasonably built up screen memory, ST and Amiga would be twice as fast. The hardware developers probably saved themselves some work here and made the graphics chip a bit simpler. But the software now has a harder time. With reasonable screen memory, you could scroll smoothly in all directions, display super-fast, gigantic sprites and program insane action games on the ST. The messed up screen memory slows down the ST by a factor of at least 2, if not 3. The Amiga is no different, by the way«.

The question of the best computer for 3D games ends in a loud discussion: »If I didn't have to program on the ST, i.e. type in and assemble, I would prefer to write for the ST - I don't know, the ST has hardly any advantages over the Amiga - although an 80286 or 80386 PC with a VGA card and 256 colors would not be bad - no, it's useless. With VGA you only have one screen and can't switch between two screens - Also, I don't like the code segmentation on PCs; so it must be a 68000 computer - An 8MHz 68000 is slower than an 8MHz 80286 - It would be really great to program on the Macintosh II. 16MHz and math coprocessor that makes 3D so much easier - The Archimedes can also calculate very quickly without a math processor - A single T8OO Transputer beats every 80386 and 68000 by far . . .« Finally the four agree on the Macintosh II , closely followed by Archimedes and Atari ST.

But there is no debate about the most difficult machine for 3D games: the MS-DOS computers. »There are simply too many different models on the market, from super-fast, high-performance PCs to home PCs that don't even have twice the computing power of a Spectrum. A program must be written in such a way that it runs on the slowest PC, so it cannot take advantage of the faster ones. In addition, there is the hustle and bustle with the umpteen different graphics cards that are incompatible with each other, but all want to be supported.«

When asked which games they have enjoyed playing in the last few weeks, only a few answers are given. Everyone liked »Dungeon Master« because the operation is so logical and the programmers have thought of every detail. They were also impressed by the demo of »Interceptor« and they were waiting for the finished program. They found the graphics of »Xenon« particularly beautiful, but they said: »If someone would draw us the graphics, we could probably write the program in a weekend.«

They can't think of more titles and the reason for this comes straight away: »We see everything very strongly from the technical side. When we play something, we immediately notice that this isn't properly programmed. Sometimes we don't like the best games because we only look at the technology and say: it could have been done better.

We really love picking apart other people's programs just by watching them. You can say a lot of negative things about a colleague's programming style just by playing for 30 seconds.«

Will Realtime only make 3D games, or could they also program a »normal« game with sprites and scrolling? »Oh yes, we certainly could. We even want to finally write a sprite-oriented 2D game. There's only one catch: we can't draw. In a 3D game, the programmer does not have to be able to draw. But for a sprite game we needed a good graphic artist. But then nothing stands in the way.

However, none of us wants anything other than 3D. And with our good reputation, we get a lot more money for SD programs. With us, software companies know that they don't take any risks when we program a 3D game.«

Carrier Command was a real hit. How will Realtime ever top that? »Next we'll do 'E.P.T'. A space trading action game that will lean a bit on 'Elite'. However, it will be much bigger, nicer and better. It will probably only come to 16-bit computers before the end of the year. We've been at it for well over a year.

By the way, the name has to be changed. We recently saw the movie 'Fatal Attraction' and there's a scene where there's a big box that says 'EPT'. EPT is the American abbreviation for 'Early Pregnancy Test'. And of course we can't call our game that! But E.P.T., or whatever it's called, is going to be great: much more complex and realistic than Carrier Command. Then we think about programming a super fast 3D action game without much strategy, only for 16 bit. It will be a while before the guys are finished with their new projects.

The original German language interview is here.

* Indexed. I kept thinking this was a translation error. It isn't. This is, or at least was a literal index run by Germany's Federal Department for Media Harmful to Young Persons. In the eighties they would assess games and censor media which could be harmful to young people. Censored works were added to an official list in a process Wikipedia tells me was called Indizierung (indexing) and indexed works had limits placed on them in terms of sale and advertising. Atari's Battlezone arcade game must have been indexed along with Operation Wolf (Ocean), Army Moves (Imagine), Falcon Patrol (Virgin Games), and Barbarian (Palace).

No comments:

Post a Comment