This design article covers how the developer of Affordable Space Adventures reached a feeling of "in distress and slightly overwhelmed" yet comprehensible and usable.
Nicklas "Nifflas" Nygren and KnapNok Games' Lau Korsgaard are developers behind Affordable Space Adventures
Many innovative games are all about establishing one or a few really great mechanics, then exploring and exploiting them to the maximum. With Affordable Space Adventures, however, that was not our train of thought. We wanted to cram as many features into our spaceship as possible, as our idea was to create a complex game where the engineer who operates the ship computer (via the Wii U gamepad) should feel like, well, an engineer.
One of our inspirations was Steel Battalion, on the original Xbox. It shipped with a huge custom controller. Many interface designs try to be as invisible and unobtrusive as possible. The attitude is often that if the player doesn't pay attention to the interface, the designer has succeeded.
Steel Battalion was very different: The interface leaks out, and becomes part of the physical space the player is situated in. It is big and clunky, and very much demands attention. We wanted to explore the same idea, and the Wii U GamePad made this possible for a smaller team without the resources to make a custom controller.
Capcom's Steel Battalion
In Affordable Space Adventures, however, you don't control a big powerful mech; instead, you're in charge of a small, cheap spaceship. The "Small Craft," as we named it, is a horribly unsafe vessel. Push it too hard, and the diesel engine explodes, or the electric engine blows a fuse.
All the same, the game's hostile world is designed to force the player to use uncomfortable and dangerous ship system configurations. Enemies scan for heat, electricity and sound, and during each enemy encounter, the engineer must make sure the ship is configured in a way that doesn't give its position away.
While developing most games, playtesters frequently misunderstand even the simplest mechanics -- ones that seem completely obvious to the designers. Explaining a complex game like Affordable Space Adventures... well, that was bound to be a serious challenge.
The Affordable Space Adventures UI, on the Wii U GamePad
Early on, we didn't know exactly what features the ship should have, apart from two distinct engines (combustion and electric). We set up a debug GUI that would allow us to design and manipulate ship system settings, and then created various systems to see if they were fun. Once we had a relatively satisfying combination of systems, Nicklas Nygren (of Nifflas' Games) created a GUI for the Wii U gamepad that would show every bit of information about what was going on inside the ship to the player.
The early interface
The list of things to communicate was long:
The system power of each individual ship system, like the antigravity system or the thruster.
The status of subsystems to ship systems, like the stabilizer, which was a subsystem to the fuel engine motor.
The current level of heat, electric engine stress, and/or sound. These properties reacted dynamically in response to system power and thrust. We needed to show what affected what, and at what rate. This was indicated with small animated icons under each system.
The temperature of the ship, the outside temperature, how visible the heat signature of the ship is, and the heat sensitivity of the current enemy robot.
The amount of reactor stress, the electric visibility, and the electric sensitivity of the current enemy robot.
The sound level of the ship, the outside noise level, the audio signature of the ship, and the audio sensitivity of the current enemy robot.
On top of this, there were a bunch of systems that didn't work like any of the other systems -- like the landing gear or the scanner. What they did, and their status, needed to be communicated as well.
All this was great fun and very interesting; the problem was that nobody understood what was going on.
Players felt that the interface didn't indicate what information was important to them; the thing was, all of the information was important. Removing any of it would damage the game. At one point, however, that seemed to be the only way out. The entire ship was dumbed down: All systems were Boolean, and could only be on or off. This wasn't the grand vision, but at least it would be understandable.
The final interface
Luckily, Simon Nielsen (of Knapnok Games) came up with a new design for the interface that didn't make these sacrifices. The two engines were placed within thumb-reach at the edges of the gamepad. The primary thing the player manipulated, the system power, was clear and visible. The heat/electricity/sound relationships were by default hidden, but exposing these connections was always just one tap away. Tapping the heat output gauge would, for example, show an overlay with cables connected to all the systems producing heat.
The output gauges were placed in the center, like a car dashboard, and clear, understandable metaphors were selected to communicate functionality. If the needle reaches the orange zone, you are in danger! Other pieces of information were made context-sensitive, and showed up with big warning signs only when they were relevant.
Most importantly, players were no longer completely confused about everything in the game.
An important thing is that designing the GUI for the ship systems was a two-way process. Simon's interface only worked because it used the space on the GamePad really well, but this imposed strict restrictions on the ship features. He put the fuel engine's controls on the left side, and the electric engine's controls on the right.
The symmetry was essential to this design, because it meant that if we introduced the fuel engine to the player and later unlocked the electric engine, the players would feel comfortable with using all this new stuff right away. Of course, to achieve symmetry, both engines needed exactly three configurable sub-systems, so at this point Nicklas had to redesign the functionality of the spaceship to fit that constraint.
We're pretty sure that if we had a different attitude, where the GUI was subservient to the design of the spaceship itself, and the game was designed without compromise to include the ship features we initially wanted, the game would have been terrible.
Once we had a good foundation for the ship GUI, there was a second challenge that took us months to solve: We needed to explain the stealth part of the game.
It turned out to be incredibly hard to communicate that "your electricity output must be under this threshold if you are within this range of this enemy, which you can only know if you scan that enemy first."
In an early iteration, we had dedicated only one level to explain this: The scanner would become unlocked. Players had no problem using it to scan an enemy. The instructions would state that the player needed to stay under a threshold that we indicated on the GamePad, but something didn't connect. Nobody paid attention to the orange threshold, even though we had just pointed it out. They saw it, but considered it completely unimportant. Then they'd get really frustrated that enemies would seemingly randomly decide to kill them.
The first instinct as a game developer to explain something complex is often to try to break it apart into smaller pieces, and explain them one at a time. So, we created a separate level that explained how to scan an enemy and stay out of its area. Then, in a later level, we introduced the detection thresholds. We were sure players would get it now... but nope. It wasn't possible to break the teaching process down into any smaller pieces, either. After months of further hopeless iterations, we just decided, "Hey, let's just make a video."
It's very weird how well this solved the problem. There's a bit of information overload in the video, and a lot of players felt they couldn't keep up with it. Yet when they actually had to use the knowledge taught in the video, they had no problem figuring out what to do.
In a game that's about being in distress and slightly overwhelmed by a complicated spaceship, this was perfect. It was also a nice reminder that while it's generally nice and elegant to teach game mechanics entirely through level design, it's not a universal solution that will always save the day.
What you see on the TV as you play Affordable Space Adventures
Affordable Space Adventures taught us a lot of things. We learned that we couldn't just design the ship with any set of features we wanted and then slap a GUI on top of all that, but also that there was a much more elegant way to make the game understandable without dumbing it down.
We also learned that even established game development principles can sometimes be a box that we must think outside, to find a working solution to a problem, and that our idea of what is an "elegant" solution prevented us from seeing the right one earlier.
By the looks of it, we succeeded making the game understandable. Reviews have been really good and we've heard a lot of nice things from the players. A few issues come up occasionally, such as the loading times. Some people also get stuck on a few of the game's puzzles. Maybe that's unavoidable, though; what one player may consider too frustrating, another player enjoys as an interesting challenge. Players, however, rarely mention struggling with figuring out how the game works, and it feels great that all our effort with this paid off in the end.
You May Also Like
