|
[This is a reprint of an article originally written for Dev.Mag, a South African Web-based magazine. If the contents of this blog interest you, hit the link for similar articles on game development.]
When you sit down to write a book, one of the most important things
to bear in mind is the shaping and formation of your expression: if you
can elegantly express in a single sentence what a lesser writer would
need a paragraph to evoke, then you've got yourself a talent for
writing.
Good journalism, similarly, is all about the brevity of your
expression: a focus on the points that matter — and the arrangement of
said points — to create a concise and informative read for your
audience without leaving anything out. The importance of this is
clearest in news briefs and other environments where every individual
word that you place needs to hold significance.
This advice has been thoroughly rammed into the veteran noggins of
writers, architects, musicians and countless other disciplines which
respect minimalisation when it comes to polishing work. The question of
"Does that really need to be there?" even extends to the field of
programming, where a job not only needs to be performed correctly, but efficiently as well.
This, of course, begs the question: does such advice extend to the
nebulous realm of game design? Is minimalism the mark of a good game
designer? If so, where do we draw the line?
The challenge posed
Antoine de Saint Exupéry, a French writer and aviator, once stated the following:
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
He wasn't talking about game design specifically (the gent was a bit
before our time), but it's interesting food for thought. Does the
additive process harm good game design? Does our job consist of
actively cutting away weaker elements, rather than just adding new
ones? Or is it an alternative concoction that can't be so easily
labelled?
The indie slant
This statement may come across as somewhat myopic, but it seems
logical that indies in particular would have to think about keeping
elaboration to a minimum over the course of a game project. The idea of
"adding this and that" won't fly in a situation where the team's size,
budget and dev time is limited, and one would sooner see a simple,
experimental game taking flight than any kind of successor to World of
Warcraft. An indie's project needs to be smaller, and only the most
important design ideas will survive in the torrid landscape of "cool
things to add to the game".
World of Warcraft succeeded in creating a complex and rewarding game experience. But does this translate well to indie projects?
That said, there's still a wide base of views held by independent
game developers regarding design minimalism. Some support the notion,
others hold that it isn't necessary for a good game at all.
Common consensus holds that minimalism in terms of user interfaces
and information systems is a must. No matter what the complexity of the
system itself may be, the most important information needs to be
selected and put on display for the user. Thus, having a health bar
that changes colour with status effects would be superior to having
both a health bar and a status message next to it (further elaboration
of this concept over here).
But when it comes to that system itself — the rules which the UI, for example, would draw from — what do we do?
A case for simplicity
"look at all that super mario bros. accomplishes with about four
types of blocks ... that's elegant design." This is how Anna Anthropy
(aka. auntie pixelante) responds to Saint Exupéry's quote.
Anthropy is a blogger, game developer and game theory expert who has
a particular interest in the design of platform games, particularly
with old-school classics such as Super Mario Bros. and Monuments of Mars. Her games, like her analyses, pride themselves on simplicity and elegance: When Pigs Fly is a pretty accurate embodiment of this philosophy.
Super Mario Bros. is a classic example of gameplay that stems from a minimised rule set.
"contemporary game design is a victim of clutter," says Anthropy.
"because the games industry is hit-driven (big budget games need to
sell huge amounts just to recoup their costs), games are designed to be
everything to everyone. unfortunately, the result is a game full of
features which all tug in different directions, and which stretch the
idea of the game thin beyond recognition ... they stretch an hour's
worth of ideas over eighty hours of filler."
Adam Saltsman
believes in "hardcore reductionism". The first step in his projects is
to boil a game down to as simple a concept as possible. "Once you have
this atom, this indivisible thing, frequently there are simple or
obvious ways to expand it honestly and faithfully without attaching
whole new mechanics to the thing. If you've boiled it all the way down,
it's usually pretty easy to see what sorts of other gameplay options
will be a good fit."
Saltsman has a rather interesting — and controversial – Gamasutra blog post that touches on this concept.
Gamasutra blogger Gabriel Lievano advocates a similar point of view, and actually makes reference to a very high-profile series which he believes suffered from design bloat at one point.
An example of this type of design
[minimisation] can be watched in Sid Meier's Civilization change from
Civilization IV to Civilization Revolution. Civilization games used to
evolve adding more and more functionality and content in each iteration
... in Civilization IV you had the same game but you could manage
religion, finances, politics, external relationships, a huge variety of
resources, culture, pollution, technology and a lot more ... the
question: is all this functionality really relevant for the player's
experience? And the answer was Civilization Revolution. The difference
between Civ IV and Civ Revolution is enormous: it's like rewinding to
the first civilization but keeping the most fun parts from its sequels
and the cool graphics."
Another point made is that a good game should always be easily
summarised. Often this is for the sake of design itself (Anthropy once
again refers to the case of Super Mario Bros, where the basic idea is
"jump with momentum"), but it's also a good indicator of marketing potential,
as pointed out by Paul Taylor. The ability to craft a single-sentence
description of your game experience is a good indicator of a tight
design, and by extension a tight game.
Jonatan Söderström earns recognition through his rapid development of simple prototypes.
Jonatan "cactus" Söderström,
a rapid game prototyping advocate, is averse to the concept of a
"perfect game design", but he does acknowledge the elegance of
simplicity. "Neither a large amount of content nor variety are vital to
a perfect game," he says, "and I think that experiencing something
interesting in concentrated form can sometimes be better than having it
diluted or prolonged."
The point made by tutorials
Danny Day, one of the names behind South African studio QCF (SpaceHack)
, feels that Saint Exupéry's statement is an important influence on his
game design views. He doesn't adopt quite the same stance as Anthropy,
however.
The elegance and seeming simplicity of
a polished design is obvious when seen at the meta level, but games
themselves aren't actually about elegance or simplicity. A simple game
wouldn't be very engaging because players wouldn't have to create and
revise mental models or manage expectations, it would feel empty and
senseless to play."
Day believes, instead, that playing a game is the process of
finding one's own elegance and simplicity in a complex system. He
highlights the example of tutorials: following Saint Exupéry's advice
dogmatically would result in their removal from a game entirely, and in
a lot of situations this simply cannot be done. But polishing and
minimising that tutorial as much as possible without robbing a player
of vital information is something golden. "As designers we should care
about taking things away that obscure or confuse the player and make
their interaction with the game seamless and empowering. An easily
absorbed tutorial system is hours and hours of work." Player burden
needs to be removed as much as possible: with a complex system, this
becomes more difficult — but not impossible — for a prudent designer.
Anthropy also mentions tutorials, but with respect to classic arcade
games: in an environment like that, the designer often doesn't have the
luxury of a tutorial at all (or has only a few seconds to explain core
concepts to players), and in instances like these a simple premise is
an absolute must.
One example of game complexity stifling the player's experience is offered by Tyler Glaiel,
a developer who learned first-hand the dangers associated with
unnecessary complexity through the problems he had with one of his
Flash games, Blockslide 2.
Blockslide 2, which Tyler Glaiel deems weaker than its simpler, more successful predecessor.
Following the success of the original Blockslide, Glaiel explains
his design philosophy on this particular project. "I was in the mindset
that 'bigger was better', so I invented all sorts of crazy block types
to add into the game with no sort of restraint. Most people didn't
finish the long tutorial. Most people thought the tutorial was the
whole game, considering it very well should have been ... people were
overwhelmed not necessarily by the amount of stuff, but by the
unintuitive ways [in which] things interacted."
Glaiel took this problem into consideration with his next project,
Closure, exercising more restraint on what he added to the game. The
venture was far more successful.
The other side of the coin
"When you consider planes and books, I think it makes more sense."
This is the response that Tarn Adams offers to the idea of subtractive game design. Being the name behind Dwarf Fortress,
which happens to be one of the most miraculously intricate indie games
around, his opinion on the matter is arguably quite important.
"I think I understand the spirit of the quote," he adds, "and it
surely applies to certain situations even in game design, but I've seen
it quite often used to try to force keep-it-simple-stupid thinking that
squashes video game innovation and I tend to think of it rather
negatively when it comes to games."
Dwarf Fortress, a convincing counterbalance to minimised games.
Luke Arntson , a multi-platform developer, recalls his work on a contract project for Action All Stars
called Pitching Ace. The game initially involved a rather complicated
pitching scheme (relying on the mouse to draw an accurate path for a
better throw), but after initial feedback from playtesters, the system
was reduced and simplified for accessibility. He believes that this
move was a mistake.
So the new control scheme was in place
... but our game was getting bad vibes from the higher ups. Another
game was being made at the same time that involved batter pinball like
those old machines, and it was actually pretty fun. So why was our game
failing and the other contracted game doing so well? The truth is our
design was too simple.
"[The game's development] felt like working with a piece of clay,
where every week someone would come by and take away a different sized
chunk, until all you could make were three small clay balls."
Chris Cornell, a developer with experience in both the indie and
mainstream industries, looks at the matter from a more pragmatic
viewpoint. In a world where additional features usually equate to
additional resources (namely money), there's a very strong call to fix
design flaws rather than removing them entirely. He cites his work with
Leapfrog on their Leapster game system.
Leapster developers soon learned the importance of balanced complexity.
The initial round of games that he worked on was handled from a
top-down design perspective: art resources were generated first, a lot
of features were locked and others had to be reduced to meet workflow
demands. This did not end well, and the design paradigm was changed to
allow for a more flexible, additive process.
Over 5 years of working there, the
round I still believe we produced the best games was during the 2nd
year, where by a quirk of planning and schedules, we had a solid base
of prototypes to start from and grow, rather than a large document full
of ideas that we trimmed down."
Switching back to the more restricted process afterwards reinforced
this point, as the games once again suffered from a poor reception —
even though the team had, by then, a lot more experience with the
platform.
Parting notes
It's difficult to state anything conclusive about the idea of
minimal design, and considering the feedback from developers who have
taken a variety of approaches on the matter, it would be naïve to
suggest that any particular philosophy or paradigm is unambiguously
"the one to go with".
Advocates of minimisation have a good point to go with, but it seems
to be a rather romantic trap to stumble into: the idea sounds solid on
the surface, but there's a lot of other factors to consider when going
down this route and what seems to be a good design habit may in fact
harm your project if taken too far.
It seems best, therefore, that each aspect of a game should be
considered intelligently and with due respect for both points of view —
a capacity to "kill your darlings" and cut features when necessary
without pushing your philosophy too far and stripping your game of
something that makes it special. Sometimes players enjoy the challenge
that complexity offers, and if said complexity could be married with
the correct amount of minimisation it is likely that we'd all be
producing superior games.
Draw your own opinion from what you've read here, and remain mindful of the importance of balance. As developer Paul Eres
puts it: "I distrust the idea of 'paradigms' [in game design] — I think
they're unnecessarily gross simplifications of what's really going on.
Like simple rules for people to use to believe they think they know how
something works, when all they know is some simplification."
More things to look at
The TIGSource community has an excellent set of responses
to Saint Exupéry's quote and provide some wonderful insights regarding
the matter. The thread includes a lot of information that wasn't
sourced for the final piece, and comes strongly recommended as
additional reading on the subject.
If you're looking for an interesting advocate of minimalism, have a look at Gabriel Lievano's two-part design series over here and here.
There is also a well-circulated design article
by Anna Anthropy dealing with the level design in Super Mario Bros. Her
blog contains many other entries which make for a good read about
minimalism and other important points for interested developers.
There's also an interesting post on minimalism as more than an aesthetic over at omgphatloots. It mainly discusses design in general, but links this concept elegantly to game creation.
There's a similar blog post over here, applying the concept to MMO design.
|
"Everything should be made as simple as possible, but no simpler."
This is not the case. My project right now (closure) has a few mechanics in it, but had tons of patterns possible for puzzle design, due to the way mechanics interact with each other.
Also, Noah already touched on this, but it is important as a designer to remind oneself that the game is suppose to be simple and accessible to the player, not necessarily easy to develop. Of course it's great when the whole process can be simple for all parties involved, but that is seldom the case.
http://begthequestion.info/
Haha, that's a hilarious site. I might get a shirt!
Another negative example would be the transition from Morrowind to Oblivion. Many many fans of Morrowind feel that Oblivion is too dumbed down (automatic travelling, short dialogues etc) which pretty much destroyed the feeling of being an explorer. Oblivion made me feel like I was playing GTA in a fantasy setting at times.
What I'm saying is that yes, you can and most often should take away things that are in the way of the gaming experience, but you should do it carefully, because some changes can negatively alter the nature of the experience. To me this is more important than having the game be easier to get into.
I'm glad to see that this is generating some discussion. It's not a very black and white topic, so various points of view are always welcome.
Just to note - Exupery specifically said to remove everything that can be taken away. If you cannot take away the tutorial, then it is not following his advice to attempt to take it away. What you should do is find a way to make the tutorial part of the game, that way you don't have a "tutorial" and a "game", you just have a game.
Perhaps the best example of this is Portal, where essentially the game itself is a tutorial.
But doing that "invisibly" is a ton of design work ;)
Basically, if you put in a ruleset into the game, the game should do these two things: first, make sure you use the ruleset to the fullest capability, and secondly, to do no more than that.
Taking "Braid" as an example, almost every level does 1 of 3 things, and only that.
1) Introduction: Introduces a ruleset
2) Concept: Introduces a concept related to said ruleset (or counter-ruleset), and tests the player on said ruleset.
3) Twist: Introduces a counter-ruleset, which changes how current rulesets are played (or experienced).
It is arguable that the last few zones of Braid has no real influence on how the ending is experienced, but each zone is fairly optimized on gameplay and user experience.