The History of the Game Engine: Part 10 – Developing Toolkits

Pop into your time machine and jump back to the 1970s. Don’t forget the flares and wide lapels.

Here? Great! Let’s continue.

The Dawn of Computer Game Creations

Writing games in the 1970s was a true labour of love and required a really deep understanding of the computer you were working with. Sure, the technology itself was a lot less advanced than whatever you are reading this article on (unless you printed it out and have a hardcopy on a piece of paper…), but ‘less advanced’ doesn’t mean simple.

Chances are, in fact, that it was fairly complicated.

One of the most important microprocessors of the era was the MOS Technology 6502. This groundbreaking chip is the one you’d find inside an Atari 2600, a Nintendo Entertainment System, the Apple II, BBC Micro, and Commodore 64—quite the list of bad boys of the time.

It was first introduced to the world in 1975 and along with the Zilog Z80 (the competing chip that ran ZX Spectrums, Amstrad CPCs and the Sega Master System), completely revolutionised the computer game industry.

With one of these processors, it was possible to create a computer for a relatively low cost that could be programmed to do wonderful things. For many, ‘wonderful things’ meant games.

Computer processors, however, have never been good at speaking any human language, and that was never more true than back in those heady years.

The Translation Issue

Machines talk binary, people talk English (or German, Japanese, Arabic, etc.), and getting the two to marry up is hard. So hard, in fact, that it’s still never been properly accomplished.

In the 1970s, anyone seriously interested in computer programming had to accept that they needed to be the ones who compromised, learning the machine’s language rather than trying to get it to speak English.

Thus, most early games in the 1970s and 1980s were written by tech-minded geeks in low-level machine-specific Assembly Language, caring deeply about things like correct memory allocation. For anyone who hasn’t seen it before, 6502 Assembly Language looks more complicated and off-putting than the deepest gibberish and requires substantial planning and patience to use. “User friendly” was not a term that had yet been coined!

Of course, there were others working on the problem from a different angle, inventing halfway languages that could be converted into the machine code through compiling or interpretation, and were a lot easier to understand for the humans involved. The most famous of these was BASIC (Beginners All-purpose Symbolic Instruction Code), written by John G. Kemeny and Thomas E. Kurtz in 1964, and developed further for microcomputers by a young Bill Gates with colleagues, Paul Allen and Monte Davidoff for their company, Micro-Soft.

BASIC was great at helping people who didn’t want to approach the migraine-inducing nightmare of Assembly Language to get their computers to do something, but it came with a serious overhead in terms of processing power, such that anything written in it was too slow to really be commercially viable as a game. Having the computer work in the background translating the language into something it understood at a core level took processing time and power.

Thus, the first few waves of computer games stretching from the 1970s to the mid-1980s simply had to be written at a low level. Game development was firmly in the hands of the technically diligent.

Game Development Utilities

By the early 1980s, the computer game industry was thriving. It had had its ups and downs, but there was no doubt that people loved computer games. If only they could make some themselves!

For years, there had been some attempts by various outlets to bring computer game creation to the masses. Magazines of the time often included long printed BASIC programs which you could type into your home computer and make a game of sorts. While typically, any game of this type wasn’t particularly good, it did show that mere mortals were able to have a go and through a little patience, trial and error, and burgeoning understanding, various aspects of those game programs could be adjusted by the home user to make them unique and personal. For the eager, those game examples provided a way to learn a little about programming and there’s no doubt that many future game developers were inspired in this way.

But it was still all sub-standard BASIC-driven games that didn’t hold a candle to the professional titles of the day. Sure, you could knock out some sort of Space Invaders clone, but it didn’t quite have the feel of the original.

Enter Pinball Construction Set. This 1982 game/toolset opened the door to something entirely new—the ability for the user to have a hand in the design of the game without requiring any hardcore programming understanding, and without sacrificing performance. Pinball Construction Set was a proper game, with all the programming technicalities that it involved, but it introduced a new element—an editor that allowed the player to make their own pinball tables.

You didn’t need to wonder about the calculations or the physics that controlled the ball, the complexities of memory allocation, or how to utilise input devices to control the paddles—all of that had already been done by its designer, Bill Budge—no, all you needed to do was move the pieces into the places you wanted them to be and you could create your own virtual pinball machine.

To say Pinball Construction Set was revolutionary is an understatement. Here was a tool that used a graphical user interface (GUI) before the term (and its acronym) had even been thought of, offering a visual way to interact with the controls. You didn’t need any programming knowledge to make a pinball table, you didn’t need patience (particularly), or to study indecipherable texts—you could just do it.

In this series so far, we’ve given a lot of credence to the professional level of game engine tools that started to become shared in the 1990s, but really the early days of “make your own computer game” started with Pinball Construction Set.

It was swiftly followed by other toolsets. Adventure Construction Set, Garry Kitchen’s Gamemaker, and game-specific level editors like Thunder Force Contruction.

It was a few years later when the next groundbreaking software emerged, with 1987’s Shoot ‘Em Up Construction Kit.

The Rise of Indie Development

Shoot ‘Em Up Construction Kit, also known with some affection as SEUCK, was incredible. Though the first version for the Commodore 64 saw a lot of praise, it was with the Amiga outing in 1989 that it really came to life. SEUCK appeared when top-scrolling shoot ‘em ups were a thriving genre and brought the tools to the masses allowing anyone to construct their own fully-fledged game.

It was inspiring and it was liberating. Now, with absolutely no programming experience or understanding whatsoever, it was possible to make a fully working, multi-levelled shoot ‘em up game, with graphics you designed yourself and a wide range of settings to really tailor it all to your liking. Not only that, but SEUCK allowed you to share these creations pseudo-professionally, with full game files independent of the creator software that would auto-run on boot-up just like a ‘real’ game.

SEUCK was powerful and made its many thousands of fans feel like true game developers—a situation that was furthered thanks to the many magazines that were always looking for more free content to put out on their monthly cover disks.

The construction kit was responsible for a wave of user-created games flooding the community as titles of varying quality got sent out to magazine subscribers with staggering regularity. Some were good, but most were bad. It was the early days of independent contributions but also the dawn of shovelware!

Independent game development hadn’t really existed before the mid-1980s, not because individual game designers and smaller teams of amateurs didn’t exist, but because all games at the time were pretty much indie—the idea of a massive team of AAA professionals working away with a suite of development tools and marketing deadlines looming was far rarer than the guy in his bedroom developing something cool with his mates.

Slowly, though, the landscape changed, and bigger and bigger businesses stepped in. Games started to become grander affairs and the simpler games dropped from the shop shelves, replaced by towering monoliths by growing corporations.

Bedroom programmers went ‘indie’, but as technology improved and the work between ‘inspiration for a game’ and ‘working software’ widened, something was needed to fill the gap. For many, that was SEUCK, but it wasn’t alone.

STOS and AMOS

As the power of computers improved, the need to write everything in Assembly Language lessened. Sure, if you wanted to squeeze everything you could out of the machine, then talking to it on a direct level was still key, but both interpreted and compiled languages were now becoming established as viable tools for game creation.

While tools such as Shoot ‘Em Up Construction Kit provided a viable way for non-programmers to make a game, they lacked the flexibility of true coding and, as such, felt limiting.

The world was still waiting for a toolkit that would provide the ease of use these game construction programs were offering, but with the sheer developmental power of a true programming language.

In the late 1980s and 1990s one of the projects that gained significant momentum was STOS for the Atari ST, and its sibling, AMOS, developed a couple of years later for the Amiga.

Originally conceived as a BASIC variant that had specific tools for game creation, STOS was redeveloped as a pure game creation tool, utilising many forms of BASIC that were already well-understood by the community but including specific commands and routines for sprite manipulation, collision detection, and similar game-design staples. Added to it was an impressive GUI-driven set of tools for creating in-game graphics, a compiler to take the BASIC code and speed it up three-fold, a music-making tool, and an assortment of ready-to-use graphics and other assets.

As the 1990s settled, STOS and AMOS had replaced SEUCK and other similar packages as the go-to game building software of choice. This was further enhanced when AMOS 3D and STOS 3D were added to give a new suite of tools for polygon-based 3D game creation, a previously untouched holy grail.

There were even a few, though rare, commercial successes that came from AMOS, including point-and-click adventure game Flight of the Amazon Queen which had been written on the platform, and side-scrolling shooter Jetstrike, a game that managed good reviews on both on the Amiga and later Amiga CD32.

Choosing the Right Tool for the Job

The nineties saw a burst of game creation tools, some greater than others and many with a focus on a single genre of games. Coming from Japan (with a whole host of piracy and translation problems) was the excellent RPG Maker. Allowing creators the chance to see their story-driven top-down RPG dreams turned into games reminiscent of the swathe of JRPGs that were around in the 90s made RPG Maker incredibly popular. It was a relatively long time before it became properly available in the West, but it lives on today with RPG Maker MZ still providing an extensive set of tools for lovers of the genre.

FPS fans turned to the Game Creation System from Pie in the Sky (sometimes referred to as Pie in the Sky, GCS or 3D GCS). An early DOS version was released first and was soon improved and adapted for the growing Windows market after Windows 95. GCS was quite powerful and gave would-be game creators a strong set of tools that required no programming to use, but it was also laborious and off-putting for beginners, showing the difficulty in finding the middle ground for every game creation tool sought, between providing enough features and overwhelming the user.

Some games, such as The Bard’s Tale Construction Kit and Wing Commander Academy added a substantial level creation system to their core providing yet more game-creation tools if ones that are specifically tied to the main title. While these couldn’t be used to make stand-alone new games, often communities have sprung around them with fans sharing home-made levels with each other. It’s a practice that continues today with top tier titles such as Super Mario Maker 2, Roblox, Minecraft, and Little Big Planet 3.

More generic tools were being developed, too, with the team behind STOS and AMOS going on to make Klik and Play (KnP), a beloved game creation system for Windows that still exists in 2021 as Fusion 2.5. A similar project, Game-Maker by Recreational Software Designs, offered a suite of software applications that came together to provide a full multi-genre design experience.

Perhaps one of the most interesting tools to find its way into the bedroom game-developing community in the 1990s, however, was ZZT. Developed by Tim Sweeney, ZZT was nothing more than a little text-based game where the player controls a little face that can move about and shoot things. Even in 1991, it was hardly something to wow the masses. ZZT, however, had a substantial suite of level editing tools and even its own scripting language (ZZT-OOP) that gave level designers a huge amount of power for their own designs.

A community of ZZT developers grew and grew, giving Tim Sweeney the confidence and financial backing to work on something a lot bigger—a game creation tool that would redefine the way games were made. He went on, some years later, to create Unreal Engine.

The Merging of Ideas

The lines between true game engine, fun game creation tools and level editors have blurred over the years such that in some places it’s hard to see where one ends and the other begins. Major powerhouses such as Unreal Engine and Unity, used by triple-A software houses to create major releases, can legitimately be called ‘game engines’, where others might not have that recognition. Nonetheless, there’s little doubt that their origins can all be dragged back to those 80s days of Shoot ‘Em Up Construction Kit and Pinball Construction Set, and the dreams of young game players looking for a way to be creative without the need to read (and try to understand) reams of text on 6502 Assembly Language.

Next Time…

How much is programming and how much relies on user-friendly drag-and-drop interfaces? Join us next time when we take an insider look at game engines and how to use them.

Refs

GouldFish on Games look at Shoot Em Up Construction Kit

Memories of STOS and AMOS

Games on AMOS

The Museum of ZZT

RPG Maker

With thanks to Reddit users for so many stories and memories.