In the latest issue of Wireframe magazine, video game pioneer Howard Scott Warshaw reflects on the calamitous E.T. for the Atari 2600. Could it serve as a useful metaphor for real life?
When Julius Caesar ran into Brutus on the Ides of March so many years ago, it changed his life dramatically. I would say the same thing about my life when I ran into the E.T. project, though in my case, the change wasn’t quite so abrupt… or pointed. People say that my E.T. game was ahead of its time, so much so that it didn’t work for many players in its time. Fair enough. But E.T. is more than that. On many levels, that game has served as a metaphor for life, at least for my life. Let me explain, and perhaps it will sound familiar in yours as well.
There was an aura of promise and anticipation on the advent of the E.T. project – much like the prospect of graduating from college and entering the working world as a computer programming professional. This was super-exciting to me. Once I began the challenge of delivering this game, however, the bloom left the rose (no matter how many times I healed it). Similarly, on my entry into the working world, my excitement was quashed by the unsatisfying nature and demands of typical corporate computing tasks. This is analogous to the experience of E.T. players, having just unwrapped the game. They pop the cartridge in, fire it up, and venture forward with innocent exuberance… only to be crushed by a confusing and unforgiving game world. Perhaps the E.T. game was some sort of unconscious impulse on my part. Was I recreating the disappointment of my first foray into corporate life? Highly unlikely, but the therapist in me just had to ask.
In the E.T. game, I spend a lot of time wandering around and falling into pits. Sometimes I find treasure in those pits. Sometimes I’m just stuck in a pit and I need to dig my way out. That costs energy I could have used on more productive endeavours. There’s also a power-up in the game you can use to find out if there is something worth diving in for. Sadly, there’s no such power-up in life. Figuring out the difference between the treasure and the waste has always been one of my biggest questions, and it’s rarely obvious to me.
One of the treasures you find in the game is the flower. The act of healing it brings benefits and occasional delightful surprises. I was at the bottom of a ‘pit’ in my life when I found the path to becoming a psychotherapist (another act of healing). It helped me climb out and take some big steps toward winning the bigger game.
E.T. is all about the pits, at least it seems so for many who talk about it. And they do so with such derision. Many times I’ve heard the phrase, “E.T. isn’t about the pits. It is the pits!” But are pits really so bad? After all, there are situations in which being stuck in a pit can be an advantage – OK, perhaps not so much in the game. But in life, I find it’s unwise to judge where I am until I see where it takes me. There have been times where major disappointments ended up saving me from a far worse fate had I been granted my original desire. And in more concrete terms, during a hurricane or tornado, there are far worse outcomes than stumbling into a pit. Sometimes when I trip and fall, I wind up dodging a bullet.
Yes, in the game you can wind up wandering aimlessly around, feeling hopeless and without direction (somehow, they didn’t put that on the box). But ultimately, if you persevere (and read the directions), you can create a reasonably satisfying win. After finishing development of the game, there was a long period of waiting before any feedback arrived. Then it came with a vengeance. Of course, that only lasted for decades. My life after Atari seemed a bit of a wasteland for a long time too. Rays of sunlight broke through on occasion, but mostly cloudy skies persisted. Things didn’t improve until I broke free from the world in which I was stuck in order to launch the improbable life I truly wanted.
But it’s not like there were no lingering issues from my E.T. experience. It turns out that ever since the E.T. project, I have a much greater propensity to procrastinate, regularly shorting myself of dev time. I didn’t used to do that before E.T., but I’ve done it quite a bit since. I delay launching a genuine effort, then rush into things and try to do them too quickly. This results in a flurry of motion that doesn’t quite realise the potential of the original concept. More flailing and more failing. It doesn’t mean my idea was poor; it means it was unrefined and didn’t receive sufficient nourishment. On reflection, I see there are both challenges and opportunities at every turn. Pits and treasures. Which of those I emphasise as I move forward is how I construct the life I’m going to have, and I’m doing that all the time.
Pits and treasures, this is much of life. My E.T. game has mostly pits. Truth be known, people like to call them ‘pits’, but I’ve always thought of them as wells: a place to hide, to take repose and to weather out life’s storms. For me, that has been the value of having so many wells. I hope it works for you as well. Try it on. It just might fit like Caesar’s toga. And if it doesn’t, you can say what Brutus said on that fateful day: “At least I took a stab at it.”
Get your copy of Wireframe issue 55
You can read more features like this one in Wireframe issue 54, available directly from Raspberry Pi Press — we deliver worldwide.
And if you’d like a handy digital version of the magazine, you can also download issue 54 for free in PDF format.
In game design, freedom can lead to paralysis. But in the latest issue of Wireframe magazine, Stuart Maine explains how game pillars and the iron triangle will help you focus on what’s important.
The flexibility of the medium of video games lets us experience concepts like the non-Euclidean geometry behind Superliminal’s ‘whatever you see is reality’
This article will cover two game development tools that are designed to help decide what’s important in the game you’re making. The iron triangle revolves around the practical realities of making a game, while game pillars cover the creative side, but both relate to the importance of focus. Let’s begin with pillars.
Game pillars
Every game media has its strengths, such as wargaming’s communities, the shared experiences of board games, or the collaboration of RPGs. One of the advantages of video games is their sheer flexibility – we can race across alien worlds, explore Egyptian tombs, or keep fit while going on magical quests. But that infinite flexibility can be a real problem for game creators, because if the game you’re making can include literally anything, then how do you know what to focus on?
A pillar saying your game is a platformer doesn’t really help, it’s what you do or say with that basic framework that matters
Let’s assume you have an idea for a game based on a particular world or character, or a certain type of gameplay. Alternatively, you might have used player types (see Wireframe issue 39) to decide on a particular audience and the features they like, or if you’re working with someone else’s IP, then that brand’s owners might have a type of gameplay in mind. Game pillars help move beyond those starting points and guide you through development.
The basics
A game’s pillars are a list of around three ‘core statements’ created early in that game’s development. You could come up with your pillars before you’ve started development to help narrow down the possible game you might make, or you might do this after prototyping has given you an idea you want to pursue. You can even retroactively create pillars to help rescue a game that’s been in development for a while and has lost its way.
Each statement should be short – no more than a sentence – and each should be phrased as a rule you will follow throughout development.
Use active language. We will, we like, this game is, our audience wants, and so on. Don’t use negative language if you can rephrase the same statement as a positive.
Importantly, make your pillars focus on how your players will feel over the things they will do. This is probably the most important concept here, so let’s explore it further.
During development, Rime began to deviate from its original goals and the team had to take the decision to refocus on their pillars
Dig deeper into the ‘why’
It’s easy to write ‘our game will feature 2D puzzles and platforming’, and technically that is a pillar because you can refer back to it later. But it doesn’t really say anything about what that platforming is for. By that, I mean why are you making a game about platforming? To dig deeper into the ‘why’ behind your pillar, you could rewrite that sentence to one of these:
Explore evocative alien worlds, telling a story through atmosphere and details
It’s satisfying to master deep systems and figure out hidden rules
Our players will achieve a state of flow through challenging, precision gameplay
Those are my example guesses at a pillar each for the platform games Flashback, Spelunky, and Celeste. All are 2D platformers, but they’re ‘about’ very different things.
What to do with your pillars
Note that none of the above examples specifically talk about the gameplay being platforming, because pillars should focus on the feelings and emotions you want your game to evoke, rather than how you’re going to do it. That’s because pillars aren’t a feature list to check off, more a tool to help remember the things that are important when you’re submerged in the day-to-day realities of game development. Pillars are the why of your game, and the actual development process is coming up with the what to match those initial goals.
Another benefit of pillars is they can be used to communicate the game’s vision to the public, helping to balance reality and hype
Print your chosen pillars as large as you can and put them up somewhere you’ll see them every day. That way they’ll become ingrained in your thoughts and you’ll easily be able to refer to them when someone suggests a new feature or change to the game. Will that change help bring your game closer to your pillars (great), not really affect them (neutral), or work against them (bad)?
I’ve seen studios use pillars on struggling games to discard any areas which don’t match them. You particularly see this if a game is taking too long to release (because most professional studios have to get a game out to some sort of deadline – more on this below), with people looking back to their pillars to help work out what to cut. If feature A is cool, but feature B aligns with the pillars, it’ll take a strong argument to keep A.
Establishing pillars
There are a couple of approaches for coming up with a game’s pillars, each with advantages, but also potential problems to look out for. Both of these approaches assume you already know to some degree what the game will be. Your pillars will help guide the eventual game’s details, but they’re a tool for staying on track as you forge ahead, not for coming up with ideas in the first place. If you haven’t agreed on a concept for your game yet, then run game jams, conduct audience and market research, or paper prototype ideas first.
When you’re working with someone else’s brand, involve that IP’s holder in pillar discussions so that they’re onboard with your chosen direction
Second, both approaches assume any business, audience, IP, or technology factors are already agreed and set in stone. For example, you might already know that this will be a multiplayer game, that it must be released within this time frame, or that it must be built on the technology created for your previous game. We’ll talk more about this with the iron triangle, but basically, any real-world issues that are beyond your control must be acknowledged or you risk coming up with pillars that set you up for difficulties later.
Duke Nukem Forever is an example of a major game that suffered for its lack of creative direction
Two approaches
The two approaches are to have the entire team brainstorm potential pillars, or have vision holders dictate them:
ONE: If the entire team is involved, then you run brainstorming sessions where everyone’s potential pillar ideas are stuck up on a wall. Then the group chooses the best pillars or combines a couple of ideas into pillars (remember the point about keeping them short – mashing many ideas into a long pillar is cheating).
The advantage of this approach is that everyone understands and buys into the chosen pillars because they had a say in creating them. The downside is that this process can take time, with potentially conflicting ideas needing to be whittled down until an agreement is reached.
TWO: The other approach is for ‘creative vision holders’ to come up with the game’s pillars and then present them to the rest of the team. Obviously, this is much less collaborative and more about saying, ‘I have a vision for this game which I think could be incredible, will you help me make it?’ The advantage of this is that everyone can rally behind a singular vision that someone is passionate about bringing to the world. As a result, the game’s pillars are likely to be extremely focused and all pointing in the same direction. The downside is that it requires everyone else to get on board with the game’s pillars even though they didn’t help come up with them.
Either way, once the pillars have been created, everyone on the team has to work with them in mind – there’s an implied contract that these rules must be enforced to ensure the game keeps moving in the right direction. Even though it can be unpopular to say no to someone’s idea, that’s what pillars are there to help with (and of course, pillars don’t say ‘that idea is bad’, simply that it doesn’t fit this particular game. Write the idea down and maybe build your next game around it).
Examples
Here are some actual pillars from games I’ve worked on:
Live through the apocalypse by any means necessary. This pillar from a military-themed game establishes that any action is acceptable in order to survive, implying a gritty, survival-of-the-fittest tone.
Does it make me feel loved? A pillar from a game that was designed to appeal to an audience that liked romances and was looking for escapism. This guided our characters, environments, and art style.
Make me feel powerful, and make me say, ‘That was awesome!’ It’s always worth considering a pillar covering who the player is in this game. If you’re making a game about being a giant robot, then ensure players feel big and powerful.
Small actions = epic reactions. From a puzzle game themed around combat. Because the player is making very small actions (tap, drag) we wanted to ensure the game responded with weighty reactions.
Express your own style in a safe way. If you’re working on a game for kids, it’s worth thinking about the challenges and worries in their lives, and whether your game can help them safely explore those areas.
Trust the player – it’s their game, let them play how they like. We used this for a procedurally created game, reminding the team not to create puzzles but to focus on systems that players could use and abuse any way they wanted.
The value of pillars
I realise that game pillars are quite an abstract topic, but in my experience across many games and studios, they have proven their worth. At the start of a project, they help avoid the ‘blank page’ problem of being able to make anything you can imagine, and later they help you say ‘this, but not that’ and avoid wandering in the development wilderness. So however you choose to structure or word your game pillars, I wholeheartedly recommend spending a little time thinking about the why before you launch into the what.
Owlboy: a game that favoured quality over time. It took about nine years to make, but looked spectacular
Speaking of which, let’s take a look at the iron triangle and how it will impact your game, because no matter what you do in the games industry, the triangle will impact you. As a result, it’s important to have an idea of how it works and what it means to your projects. A quick disclaimer: I’m going to simplify a complex area for space reasons, so if it interests you, check out online resources on this and other project management topics.
Art versus business
Have you ever played a game and clearly seen that it was unfinished? Missing features, obvious bugs, and a lack of polish show that you’re playing a game that needed more development time. The iron triangle is the reason games are released in an unfinished state, but it isn’t some malevolent force – it’s simply where reality butts up against creativity in game development.
Although no one sets out to make a bad game, movie licences often feel the pressure of the iron triangle due to their fixed release date
Coined by Dr. Martin Barnes, the triangle applies to premium games as much as free ones, and to indie games as equally as blockbusters. It relates to…
Three areas of game development
Quality: How ‘good’ is your game? Good could mean it has many features, levels, NPCs, and weapons, or that what you have is highly polished and balanced. It also dictates how many bugs you let through into the finished game (no one ever fixes all their bugs, you just choose which are most important).
Time: Implementing all of the above takes time, so this point of the triangle relates to how long your game will take to be released. Most game developers have to release their games to some sort of deadline; see ‘Time = money’ for more on this.
Money: The longer a game’s in development, the more money it costs, with most coming from the wages or living expenses of the team working on it. Money is the most complicated of the three factors because there’s a limit to how much you can throw at a game. A feature that’s going to take a lone developer ten months can’t be done in one simply by paying to put ten developers on it – people get in each other’s way and you have to pay even more because that many people need a lot of management.
Choose your priorities
Now we know the three points of the iron triangle – where things get interesting is that those points are all interrelated, and the rule is you can only control two of the three points. You can select which two points you want to control, but you have no say on what happens to the third. That’s why it’s called an iron triangle – the outcome of the third point is decided by what you do with the two you’ve chosen to control.
Shigeru Miyamoto spoke about delaying The Ocarina of Time until it was of the highest quality, making ‘cost’ the element out of his control
These are the outcomes you can expect based on the two points of the triangle you choose to control:
Controlling time and money is where you see licensed tie-in games. Because they need to release alongside (say) a movie, they must come out on a certain date, and they can’t cost more than a certain amount otherwise it isn’t worth making the game in the first place. The point of the triangle not controlled here is quality, meaning the game will be as big and polished as it happens to be when the time and money run out.
The second choice is to control time and quality, meaning the game must come out on a certain date and be at least ‘this’ good (e.g. large, polished, and bug-free). This option means you relinquish control over the game’s cost – it will simply cost as much as it needs to, to ensure it hits your quality bar and is released on time.
Finally, you can control money and quality, meaning the game will be big and polished, but the team is kept small to limit development costs. This means you have no control over how long the game will take to release because a small team making a polished product can only work so fast.
Business realities
You might be wondering why any of this matters – after all, you could be making a game in your spare time or working at a studio where other people make these decisions. But if you understand which of the points of the triangle your project is trying to control, then you can work more effectively, making choices that work towards those needs rather than against them.
As a side note, if you’re working at a studio and whoever’s in charge insists they can control all three points of the iron triangle, consider that a Big Red Warning. That sort of denial of the fundamentals of project management means overtime – and a game that’s likely to go off the rails.
The iron triangle isn’t about hateful business realities quashing your creative dreams, it’s about choosing and understanding your priorities so that you control your game, not the other way around.
Recap
To recap: choosing your game’s pillars helps you focus on what’s important, and choosing which two points of the iron triangle you want to control helps you focus on the reality of making a game. Both of these are important, because not deciding on a game’s pillars can lead to the end result being a mess of conflicting ideas pulling in multiple directions, and ignoring the iron triangle leads to games spiralling into overtime, delays, and impossible demands. Yes, making games should be fun, but a little focus early in a project’s life can pay off big time later on.
Get your copy of Wireframe issue 52
You can read more features like this one in Wireframe issue 52, available directly from Raspberry Pi Press — we deliver worldwide.
And if you’d like a handy digital version of the magazine, you can also download issue 52 for free in PDF format.
Fire artillery shells to blow up the enemy with Mark Vanstone’s take on a classic two-player artillery game
Artillery Duel was an early example of the genre, and appeared on such systems as the Bally Astrocade and Commodore 64 (pictured).
To pick just one artillery game is difficult since it’s a genre in its own right. Artillery simulations and games have been around for almost as long as computers, and most commonly see two players take turns to adjust the trajectory of their tank’s turret and fire a projectile at their opponent. The earliest versions for microcomputers appeared in the mid-seventies, and the genre continued to develop; increasingly complex scenarios appeared involving historical settings or, as we saw from the mid-90s on, even offbeat ideas like battles between factions of worms.
To code the basics of an artillery game, we’ll need two tanks with turrets, a landscape, and some code to work out who shot what, in which direction, and where said shot landed. Let’s start with the landscape. If we create a landscape in two parts – a backdrop and foreground – we can make the foreground destructible so that when a missile explodes it damages part of the landscape. This is a common effect used in artillery games, and sometimes makes the gameplay more complicated as the battle progresses. In our example, we have a grass foreground overlaid on a mountain scene. We then need a cannon for each player. In this case, we’ve used a two-part image, one for the base and one for the turret, which means the latter can be rotated using the up and down keys.
Our homage to the artillery game genre. Fire away at your opponent, and hope they don’t hit back first.
For this code example, we can use the Python dictionary to store several bits of data about the game objects, including the Actor objects. This makes the data handling tidy and is quite similar to the way that JSON is used in JavaScript. We can use this method for the two cannons, the projectile, and an explosion object. As this is a two-player game, we’ll alternate between the two guns, allowing the arrow keys to change the angle of the cannon. When the SPACE bar is pressed, we call the firing sequence, which places the projectile at the same position as the gun firing it. We then move the missile through the air, reducing the speed as it goes and allowing the effects of gravity to pull it towards the ground.
We can work out whether the bullet has hit anything with two checks. The first is to do a pixel check with the foreground. If this comes back as not transparent, then it has hit the ground, and we can start an explosion. To create a hole in the foreground, we can write transparent pixels randomly around the point of contact and then set off an explosion animation. If we test for a collision with a gun, we may find that the bullet has hit the other player and after blowing up the tank, the game ends. If the impact only hit the landscape, though, we can switch control over to the other player and let them have a go.
So that’s your basic artillery game. But rest assured there are plenty of things to add – for example, wind direction, power of the shot, variable damage depending on proximity, or making the tanks fall into holes left by the explosions. You could even change the guns into little wiggly creatures and make your own homage to Worms.
Here’s Mark’s code for an artillery-style tank game. To get it working on your system, you’ll need to install Pygame Zero. And to download the full code and assets, head here.
Get your copy of Wireframe issue 44
You can read more features like this one in Wireframe issue 44, available directly from Raspberry Pi Press — we deliver worldwide.
And if you’d like a handy digital version of the magazine, you can also download issue 44 for free in PDF format.
Wireframe #44, bringing the past and future of Worms to the fore.
Make sure to follow Wireframe on Twitter and Facebook for updates and exclusive offers and giveaways. Subscribe on the Wireframe website to save up to 72% compared to newsstand pricing!
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.
