The History of the Game Engine: Part 8 – Guns, Lots of Guns

One bullet.

That was all you were allowed as you moved your little green turret from side to side, attempting to save the planet from invasion. The game was, of course, Space Invaders. Space Invaders was one of the very first arcade games to have ever existed alongside other greats such as Asteroids, Missile Command and Centipede, to make shooting something fun.

Guns and computer games have gone hand-in-hand ever since those early days over forty years ago. It’s not difficult to understand why—games typically present themselves as a threat/defence situation so it fits the flavour, plus aiming and timing are both good skill-based interactions that provide fun and challenge. Certainly, guns aren’t needed for a good game, you only need to look at Super Mario Bros, Gran Turismo or Final Fantasy to see what a variety of range there is, but even those diverse genres like to dip into the pool of armaments every now and then—check out Contra, Crossout, and Mass Effect, for example. Or even this quote from Nintendo supremo, Shigeru Miyamoto, regarding Super Mario Bros:

“During much of development, the controls were A for shoot bullets, B to dash, and up on the control pad to jump. The bullets wound up becoming fireballs later – we originally thought about having a shoot ’em up stage where Mario jumps on a cloud and shoots at enemies, but we dropped it because we wanted to focus on jumping action. The sky-based bonus stages are the remnants of that idea, you could say.” – Shigeru Miyamoto, Famitsu Magazine, 2010.

That would have been quite a different game!

One thing is for sure though—guns play an important role in many computer games and ever since Space Invaders, developers have been trying to get them right.

The One Bullet Problem

For those unfamiliar with the situation, when you shot out your little laser bullet in Space Invaders (and, for that matter, Centipede a few years later), you couldn’t fire again until that bullet had either collided with a ship or travelled so high it disappeared off the top of the screen. This had the effect of your gun firing faster if you had decent aim, and a miss being twice as bad as you wanted, not only avoiding any targets but also effectively jamming your gun controls.

Why was there only one bullet in these games, though? The issue comes down to the game engine. Of course, back in the 1970s no one called it the game engine but sitting behind the scenes of the alien invasion, that’s what was crunching the maths.

Memory and code resources were very limited in those days, and programming was in its infancy. The core of the one bullet problem was tracking. Here’s how it looks, in over-simplified terms, from the computer’s perspective:

1. User presses ‘fire’.
2. Create bullet. Give it coordinates on the screen. We’ll call these ‘bulletX’ and ‘bulletY’.
3. Move bullet up the screen by increasing the amount of bulletY.
4. Has the bullet hit something? If so, delete the spaceship it hit, and delete the bullet. If not, loop round to step 3.

It’s simple enough to understand, but what happens if we press ‘fire’ again? If the engine reassigns values to ‘bulletX’ and ‘bulletY’ then the first bullet will disappear, only to be replaced by bullet number two.

There simply weren’t enough resources to hold multiple bullets. No doubt, the programmers out there are shouting at me now, mentioning arrays, or a myriad of ways that multiple bullets could have been accomplished, but the point was that they weren’t—what the engine didn’t lack in terms of power, the programmers of the day lacked in terms of experience and game design skill.

What was needed was oodles of both.

Focussing on Guns

The 1980s, both in the arcades and on home systems, were absolutely filled with digital bullets. It didn’t take developers too long to work out the multiple bullet problem, and games exploded where you could control some sort of gun and fire on anything and everything.

At the centre of things was the shoot ‘em ups, a genre of games literally defined by the amount of shooting you were doing. It was a decade of gun-toting decadence!

Defender, 1942, Ikari Warriors, R-Type, Xenon II: Megablast, Turrican, Spy Hunter, Galaga, Jungle Strike, Mercs, Silkworm… the list went on and on, each game trying to outdo its rivals with bigger and better guns. Some tried to keep it ‘realistic’ with soldiers touting nothing more than a pistol that could be replaced later by a machine gun, while others took it to an extreme, featuring screen-filling multi-firing main guns, enhanced by missile launchers, lasers, floating supports with their own independent rapid-fire guns… it was heat-seeking, boss-killing, bomb-dropping bullet hell.

And we loved it!

But while it was a lot of fun, it didn’t really provide any sort of hand-held mano-e-mano action.

Holding the Gun

Enter Duck Hunt.

OK, no, step back a bit. Enter the Seeberg Ray-O-Lite. It’s 1936, and you have your nice and shiny victorian-era old penny ready to spend.

Seriously, that long ago!

People have been looking to have fun by pointing guns at targets since… well… since there were guns. Fairgrounds have tried to replicate the affair with varying degrees of success, and the Ray-O-Lite, for its time, was like some kind of voodoo magic. Although, I’m not sure if UK shores had even heard of voodoo at the time. Hmm.

But when it comes to home console entertainment, Nintendo really got there first. It’s 1985, and the Zapper for the NES is released. It comes with, as mentioned, Duck Hunt.

And it really was magic!

Coding for a light gun wasn’t easy. Not because the programming was particularly difficult (it wasn’t) but because the hardware was not really accurate. It worked on a slightly more advanced version of the tech that drove the Seeberg arcade machine from the 30s, in that it tried to read the light coming off the TV with a photosensitive diode in the tip of the gun. When you pressed the trigger, the NES would momentarily blank the screen and replace the duck targets with bright white blocks for the gun to sense. If the gun detected one of these blocks (timing dictated which block represented which target) then you were all good, and if it just saw black, you missed.

It’s actually pretty clever, but suffered so badly from ambient light in the room (play Duck Hunt in the dark, kids), and a general lack of accuracy, that it never really took off.

What am I talking about! It was huge! Everyone either had one or wanted one. Duck Hunt was awesome!

(But it was also a bit crap.)

The light gun thing developed at a reasonable pace too. Soon arcades were filled with gun games and, because the hardware was relatively easy to get right on a dedicated cabinet but hard to replicate at home, for a time light gun games revitalised the slowly dying arcades. For sure, in the 1990s and towards the turn of the century, House of the Dead and Time Crisis were the biggest draws in any arcade.

While many home systems tried to replicate it, light gun success has really always been Nintendo’s. The original Zapper/Duck Hunt was the second best selling game ever on the NES (beaten only by Super Mario Bros) and when the Wii came out many years later, its controllers were all but designed to revitalise the genre—particular points have to go to House of the Dead: Overkill on that console. Sony did OK too, when in 1997 they released a home version of Time Crisis, with a cool looking gun that turned your Playstation into a reasonable facsimile of the arcade smash hit.

We’re Doomed

And then along came Doom. The First Person Shooter, or FPS game, is the pinnacle of gun games. Enough has already been written about Doom (and its sibling, Wolfenstein 3D) here on UGP—by David in one of the early parts of this series, and by myself as part of the ‘Story of a Game’ series–we don’t need to talk much more about it. Suffice to say, the arrival of this one title changed the way games were perceived, introducing a new genre (the FPS), as well as providing fans, future developers and the world in general with a game engine to build future masterpieces on.

Allowing others access to the Doom engine in order to develop future games was a masterstroke from id Software. From a public perspective, it led to a slew of Doom-clone games in rapid succession, and from an industry standpoint, it opened the door to one of the most important parts of modern game development—allowing game design and creativity to come to the fore in place of programming wizardry and physics comprehension.

Not that there’s anything wrong with a bit of coding magic and applied maths!

For guns, Doom paved the way. It showed us how much fun we could have walking around a maze holding a gun, from a small pistol to the BFG itself. It gave perspective and meaning to the idea. Sure, it’s not quite as tangible as holding the gun in the way the light gun games did, but their gameplay was linear, literally on-rails for the most part. Doom was not just a shooting game, it allowed for exploration, adventure and puzzle-solving, too.

Finally, guns with depth.

An Unlikely Platform

Doom not only led to clones utilising its own engine but also to software houses around the globe trying to recreate that near-perfect formula. By today’s standards, those early FPS games might look a little weak, but each one was a stepping stone on a path that would soon be leading to greatness.

One such company was Bungie. Famous now for the Xbox / Microsoft exclusive Halo franchise, Bungie started off as a developer for the Apple Mac.

The Mac was lagging behind in the games department back in the early 1990s. While the machines were impressive, and their capabilities renowned, they lacked any sort of friendliness when it came to coding games. Part of the problem lay in the machine’s operating system which, back then, was known as ‘System 7’.

System 7 was not game-friendly. Lacking any sort of Application Programming Interfaces (APIs) to allow programmers to code for games easily, Mac System 7 was really geared towards developing ‘serious’ software. Great for the Photoshop users of the world, but horrible for any game studio.

Yet games were hot properties. Doom hadn’t just shaken up the game industry, it had been responsible for selling PCs. Hundreds of thousands of them. Apple wasn’t even close to the giant they are today, but they weren’t stupid, and they watched as their main rival (MS-DOS and Windows-based IBM PC clones) began to reach a whole new market—gamers.

Bungie provided a lifeline. Enthusiastic about being the premium game developer for the Mac, and with a long term plan to develop FPSs for the platform, they worked hard to get around the nuances of System 7 and push the Mac as a gaming platform. The first result was called Pathways into Darkness, released in 1993.

To be fair, Pathways into Darkness was never going to rival Doom. It wasn’t as fun to play, for a start, and lacked the visceral oomph of id’s masterpiece, but Mac users were starved of games, especially ones that had any sort of action to them. For years, they had subsisted on a stream of low-budget shareware titles, pretty clones of decades-old arcade games like Asteroids or Frogger, and a few top-end strategy games such as Civilization and Sim City. Pathways into Darkness was a success because it was an oasis in a desert.

Their next title, Marathon, came out in December of 1994 and really was a success. Now Mac users finally had their own FPS series to crow about—the Marathon engine was technically superior to the Doom engine and included an eight-player deathmatch with integrated voice-chat. The game itself also had an engaging storyline that was well-regarded and helped it find success with players more used to story-based adventure titles than shoot ‘em ups.

Marathon was to become a trilogy, with Marathon 2: Durandal the following year, and Marathon Infinity in 1996. Was it possible that Bungie was really going to put Apple Macintosh systems on the map as potential gaming platforms? Yes, it actually was.

So Microsoft did the only thing really available to them at the time—they bought Bungie. The one development studio that could have changed Apple’s fortunes in the gaming industry turned tail in 1999 and ran to the opposition, to work on games for their new console system, the Xbox…

Building 3D Engines

While Marathon was making a name for itself in the Macintosh community, PC users were also enjoying a surge of FPS titles. One game that helped push the gun game genre forward was the irreverent hit, Duke Nukem 3D.

Released in 1996, Duke Nukem 3D was a true example of the connection between the shoot ‘em ups of the 1980s and the new breed of FPS game, coming as the third in the Duke Nukem series, the first two of which had been side-scrolling shooters (and the reason for the ‘3D’ moniker).

It was developed with the Build engine, written by Ken Silverman for studio 3D Realms. Ken had already had some success with his 1993 game Ken’s Labyrinth which looked (and played) like a friendlier, cartoonier version of id’s Wolfenstein 3D. Despite its graphical similarity, Ken’s Labyrinth didn’t make use of the game engine from id’s game and was developed entirely separately. The core of Ken’s Labyrinth would go on to be developed into Build, just as the core of Wolfenstein 3D formed the essence of Doom and the two of them would go their separate ways.

Both the Build and Doom engines weren’t really three dimensional, relying on a two-dimensional grid to define their worlds, although Build was more advanced, allowing for slopes which Doom lacked.

The other similarity both engines shared was that while the environments they generated looked three-dimensional, the creatures and objects that lay in the world did not. Still reliant on sprite technology, the enemies and items in the FPS games of the time were two-dimensional objects—this is easily seen by the fact that you can’t actually walk around any of the monsters and see them from the side or any unusual angles. There’s a front image, and a back image for when you have come up behind them, but little else. The same is true for ammo boxes, potions, armour drops and everything else.

It wouldn’t be until Quake in 1996 that this changed. The groundbreaking Quake engine, a second triumphant success for id Software, was able to render 3D in real-time and supported 3D acceleration through the cross-platform OpenGL API.

While the impact of Doom and its engine is perhaps more spoken about and well-known, it was the Quake engine that really opened up the fledgling first-person shooter genre to become the titan it is today.

”This Looks Unreal!”

Flickering lights, reflections on the water, items that react realistically to physics?

1998 had arrived, and with it, Unreal and, far more importantly for history, the Unreal engine.

Initially developed to be a lot more ‘Quakelike’, Unreal was Epic Games–the same people responsible for Fortnite and the Epic Games Store–first foray into the FPS genre, and it was immediately a success.

And no wonder. Unreal looked and played beautifully. The lighting blew the minds of the people who saw it, and the creatures, built now from true 3D polygons with no sprites in sight, awed those who looked at them. It was another groundbreaking moment in game development, helped by the huge popularity of the multiplayer-centric Unreal Tournament in 1999.

The Unreal engine was created and developed by Tim Sweeney, who had experience in specific game engine development having concentrated on tool creation for the previous games he had worked on. Three and a half years in development, it was designed with the Doom and Quake engines in mind. A weapon to shoot down the opposition in every way.

The development of Unreal in this series demands more than a short few paragraphs, however, and we’ll be back to take a more in-depth look at it in a few months. For now, back to the guns!

Safety Off, Reload, Aim, Fire

Ask most players about their favourite parts of their favourite FPS games, specifically the game engines, and very quickly people will start talking about graphics. It’s no surprise; the visuals of the game are what we see first, and they draw us in like no other component really can. But a game engine that deals with so many interlocking pieces has a lot more going for it than pretty graphics.

One of these factors is physics.

Fire your gun in a game today and you’re not happy to simply see a patch of red pixels appear around a bad guy, accompanied by a grunting noise. Thirty years of development since those early days of Doom and, as players, we expect some realism.

And we get it.

But it didn’t all come without some effort. Game engines today have decades of incremental development inside them that deals with every aspect of gun physics, and some of them take it to extremes.

Jumping forward a little to 2012 and we have Receiver. It doesn’t have the fame (or fortune) of Doom or Unreal. In fact, most people have never heard of it, let alone played it, but it stands out for one key reason—gun mechanics.

Receiver was written by Wolfire Games as part of the 7 Day FPS Challenge in 2012. Considering what to focus on as their unique selling point for the challenge, the developers decided to work on gun handling mechanics, randomised levels, and unordered storytelling.

While all are somewhat interesting, it’s the first of these three that warrants a mention here. Receiver is one of the most accurate depictions of gun-wielding in any computer game, ever. (One of them; it also has a more modern sequel, Receiver 2 from 2020.)

In Receiver you don’t just have a ‘gun’. You don’t even just have a ‘pistol’. No, this game is specific. You have a Smith & Wesson Model 10 revolver, or a Colt M1911A1 semi-automatic pistol, precisely simulated.

The first sign of this comes when you look at the gun, which accurately represents the visuals of the real thing. This is even more apparent in Receiver 2 with its significant graphical upgrade.

But it’s when you go to use the gun that you realise this is no normal FPS. It’s not as simple as pulling a trigger button, auto-reloading when you’re out of bullets and ducking behind a wall. No, in this game, there’s a button to insert the magazine into the pistol, another to pull back the slide and a third to cock the hammer before you fire. You can toggle the safety, inspect the chamber, release the slide stop and, on the relevant guns, spin the cylinder.

It’s less a quick shooting game, and more a gun simulator, doing for firearms what X-Plane 11 does for light private aircraft.

Plus, when you do go to shoot one of the opposing robot turrets, you need to hit it in the right place. No good shooting at the steel support—if you want this thing to stop firing at you, you need to take out the camera on the top.

Sounds pretty hard, and it is.

But do Receiver and its sequel represent the way FPS games are going to go in the future, or is this level of detail a stage too far? After all, I appreciate that I have to eat food in some games in order to stay alive and healthy, but would having long sequences set in the toilet enhance a JRPG? Probably not.

The same is true here with guns. It’s a great oddity, a one-off that gun fans can enjoy, but it’s a step too far away from playing a shooting game for most of us.

Sniper Rifles, Machine Guns, War

Realism up to a point is desirable though and provided more and more as game engines are polished. In 1997, we left the fantasy-esque caverns of Unreal and the grimy pools of Quake, and found ourselves fighting real people as James Bond in Rare’s megahit Goldeneye on the N64. Two years later, Medal of Honor was released for the PS1 and in 2003, World War II was entrenched in our living rooms thanks to Call of Duty and the updated Quake engine, id Tech 3, that sat at its core. As the years turned, shooting things for fun became less about fantasy guns and bright blue lights and turned into something a lot grittier—killing real people in real wars.

Stepping aside from the moral question of whether this was a suitable pastime for young impressionable teenagers, bringing real wars into the equation also meant bringing real guns. While not quite the level of detail that would come in Receiver, the guns in the games started to become familiar, and with them, the physics that governed them.

There were three main areas:

• Effects that deal with bullets hitting things;
• Code to provide feedback to the player on the weapon’s handling;
• Environmental effects that affected weapon effectiveness.

In the first category, the game and engine developers were keen to have scenery react to you shooting it. In the mid-1990s, no one really cared if a bullet you fired hit a wall, smashed a window, or embedded itself into a wooden post, but as the 1990s gave way to a new millennium, players were clamouring for more.

And they got it. From simple graphical nods of bullet holes in walls, through sound effects to represent the surfaces in the backgrounds, through to chunks of scenery being obliterated.

Interestingly, ricochets still remain rare in FPS games even today. A few games, such as Rust, Escape from Tarkov and ArmA 3 support the feature, but even though it’s accurate, players don’t like the idea that they can be shot and not totally understand where the bullet came from—consequently developers tend to leave it out of their games. Oh well.

The second category, that of providing effective feedback to simulate the different types of weapons, is a little more problematic. Hardware developers, such as Sony, have added rumble features to controllers for years to assist with this, and the current generation of haptic feedback is impressive, even if it’s still vast chasms away from holding a real weapon.

Instead, figures stagger and slip backwards when firing heavier machine guns, or occasionally become burdened from weaponry. Similar to the realism of ricochets, however, it’s an area where simulation-physics often has to take a step back for fun gameplay.

The third is every sniper-rifle-lover’s dream. That time when you pull off a perfect headshot from hundreds of metres away, watching the bullet curve in its path due to a strong headwind, and knowing you calculated it right—perfection.

All thanks to game engine physics development.

Playing with Guns in 2021

Looking for the most realistic gun physics in a game today? Two games stand out above the rest. Escape from Tarkov has some of the most in-depth gun simulations available, allowing you to customise your guns right down the constituent parts. Ballistics modelling is also top-notch, with accurately calculated bullet penetration through every object, and appropriate ricochets as mentioned earlier.

ArmA 3 offers an alternative. It considers itself more of an open sandbox military simulator and, like Escape from Tarkov, has some impressive ballistics physics working in the background.

Both games are quite a long way from the single-bullet of Space Invaders, thanks to four decades of game engine refinement.

Next Time…

Choose your fighter! What goes on behind the scenes when Ryu takes on Ken, or Scorpion snags Sub Zero with his kunai?

Join us next month, when we look at how game engines have shaped the one-on-one fighting arena.