From Pixels to Portals (eBook)

Early Tech Stacks

The Language of Love

Technology teaches us that there is nothing we can’t do. A little bit of code goes a long way.

console.log("Hello, World!");

If you’re a game developer and you are reading this: if you know, you know. However, if you’re not a game developer and you haven’t got a clue why I have just quoted “Hello World” in JavaScript, it’s because it’s the most common language. Games are written in other languages like Java—Jagex, the well-known MMO studio of Runescape fame, is named for being JAva Game EXperts.

Hello World is a great way to get us thinking about how to build techstacks for what will become our games and virtual platforms. It's always day one of coding school and being able to produce this in any coding language is an achievement for beginners. How we first approach Hello World is usually indicative of the type of languages we might use as coders of the future. These languages are like any languages, they have to be learned and as with all languages they are culturally involved. That is to say that languages are contextual. We call them GPL which means general programming language, note we have domain-specific programming languages for specific use cases. SQL, for example, is a language used for querying relational databases.

Why I first started writing code and programming; it was Christmas 1982. I was 9 years old. My mum worked 3 jobs: as a cleaner, a shop assistant and a cop. My dad worked as an engineer. Together they bought me a Sinclair ZX Spectrum 16k. The ZX Spectrum, aka the Spectrum, the Speccy and “turn that bloody thing off it is bedtime” became my obsession. Just 16 kilobytes of RAM opened my whole world up to what was possible. I could do anything. But I’d need to read the manual first.

I come from a place in the United Kingdom, called Nottingham. It’s here that we speak a very specific dialect that confounds every Shakespearean actor—such is the timbre and accent of the dialect. Just like how I pronounce the city of Leicester, Sinclair BASIC was also a dialect of BASIC, it was different with its own equivalent timbre and accent. It has 88 keywords, denoting commands, functions and operators and other logical keywords. There was a lot you could do with Sinclair BASIC, and because we played games on the Sinclair ZX Spectrum, it was clear that games could be programmed for the microcomputer. Mined-Out by Quicksilva Games was written by Ian Andrew. When I say ‘written by’ in this context it refers to the idea, the logic and the code. This game, a proto-Minesweeper (it was actually called Minesweeper in some countries) was eventually ported to other computers and code formats.

So how did we make the leap from the white-coated lab technicians of the Turing age, having fun with chess, to Bertie the Brain to Mined-Out (and all of that good Atari and Magnavox stuff in between?) The things they have in common is that the Sinclair Spectrum for all its games on cassettes and beep sound technology was a home computer and the big four labs of 1947 were computer labs. Getting from a computer the size of Leicester city hall to a microcomputer in the family kitchen plugged into a Phillips black and white portable TV with a dial needed a huge advancement in technology.

Big computers in big corporations used mainframe computers to manage applications from data to transaction processing, mainframes were the kind of motherboard of everything computational that took place in any sized organisation that needed high performance. These fast machines that spoke to different departments (via code), were able to shift data seamlessly across functions. They still do in actual fact. The desire for speed and stability throughout the 50s, 60s, 70s and 80s (and even today), gave us powerhouses of operating systems from Lotus to Microsoft. And using those operating systems we were able to distil coding techniques into DOS games, BASIC and Assembly.

Stacking Up

A tech stack requires a little more thought for video games—can you believe that?—than what went into mainframes. The technology infrastructure (the tech stack) has requirements of an almost mainframe kind where the language of the tech has to speak to the infrastructure and its associated transactions. The game tech stack is a bit like a department store, you move through the various stages, mechanics, modes but you can use the cash desk and toilet on any floor regardless of the brand. That means that it’s centrally managed and centrally maintained. When we make video games, especially in the times since 2012, there has been much more of a desire to near- or outsource elements of the development without losing the quality or functionality of the game. That means that as developers and designers, we agree on everything from security to monetisation and the technology we select operates according to the agreed strategy and associated documentation resulting in different cash desks located in different places and different toilets on different floors—not maintained by the original developer, but possibly by the publisher. It’s a practical cost-efficiency that is needed to reflect the changing face of how video games are developed.

I have worked on different Massively Multiplayer Online games, some more than once and the coding language used in the actual game’s development makes absolutely no difference in quality or output. The stack is designed for MMOs to handle players in something called instances. These instances are snapshots of identical gameplay distributed across servers. It is server technology that gives us the most freedom in games and metaverse development because it is here that we can gate, manage and maintain experiences with little impact on the experience (gameplay and narrative or brand and monetisation) overall.

If we look at non-web3 metaverses such as Roblox and YAHAHA, these present an infrastructure focused on the experience first. These experiences, though not necessarily game-focused, are built on a game tech stack. This typical stack may be set out like League of Legends or Runescape with a log-in system which precludes everything, followed by a landing area/page/ready room detailing everything from changelogs to the latest champion skins to buy and play. This section is the call-to-action area, something I’ll cover in later chapters but in order to bring the player through something called a FTUE, or First Time User Experience, we have to make sure the tech works. This stage is critical to keeping the player or visitor to our game or metaverse engaged. Screw that up and the whole thing might as well just take its metaphorical football and go home. For technology, the aesthetics and narrative are important, of course it is, but this is a competitive landscape. For non-web3 metaverses this space is hugely regulated, there are things we have to do, and we have to do them by the letter of the law, there will be no workarounds when we are dealing with under 13-year-olds. This is very important. However, for web3 metaverses, tools and anything decentralised, there is no accepted or recognised statutory or regulatory structure for, well, anything.

In today’s technology climate, cloud server infrastructure beats the in-house server room that we call “on-premise” technology, which decorated every single game studio from Seattle to Seoul. True story, I worked on a game which didn’t launch (what a surprise, you’ll hear a lot more of these anecdotes), but this is a special story because it’s the story of a Darwinian studio, a studio that was determined to die at the hands of its own stupidity. Picture the scene, a hot summer in the 2000s and 2010s where the server room was located in the basement of a glass covered tower (our main studio was on the top floor), cue biblical storms the like of which had not been seen in this place since the previous summer (when none of us lived there) and boom! Every single server was wet, and not wet like a bit of a shower, but rather completely soaked. These things needed to be dried, with hairdryers and everything. It was the CTO’s decision to place the servers in the basement of this building. In his logical mind it was the heat that would put us all in peril, bearing in mind that the average summer temperature from March to October was 35 degrees celsius. “Everyone will be dying of heat exhaustion if we put the servers in the studio,” he said. But that’s the thing. That’s where servers belong. In or at least near the studio. Our game was in development, it wasn’t even live. It wasn’t close to live. It never went live. Ten servers costing possibly $2-5k each fifteen years ago were worth very little after a drenching, and the back-ups? Well, fortunately for the CTO and the whole dev team the servers did dry out—lucky, eh?

The Final Frame

What games and the metaverse need more than anything is a sensible approach to development, something I’ll cover in subsequent chapters. Remember that technology doesn’t just happen, so don’t expect it to. Instead, build your studio with your game as the beating heart of it. Surround yourself with capable problem solvers, curious experimenters, and effective project managers, trust them all and enjoy...