Keith Burgun

Thoughts on Game Design

Why I Hate the Term “Permadeath”

upright-1Despite the fact that I’m a guy who designed one Roguelike and is soon to release another game that many people will end up calling a Roguelike even if I don’t, you’ll never hear me use the term “permadeath”, unless it’s to explain why another person shouldn’t use it, or with extreme air-quotes around it.  This is because it’s a word with extreme baggage, and it hurts everyone’s ability to make great strategy games.

That’s my claim here:  if we don’t get rid of this horrible terminology and way of thinking, we can never make great single-player strategy games.

Up front, though, let me make clear what I am *not* saying, because I can already picture the top comment saying something like “yeah, permadeath is bad, it’s way too harsh!”  This is not my claim at all.  I am not saying that permanent death is too harsh, at all;  if anything my claim is more like “all competitive strategy games require permanent death“.

 

What is Permadeath?

Just in case I have some readers who don’t know, permadeath is… well, it’s actually hard to explain what it is without all of the videogame baggage.  Like, I can’t even describe it because to do so I would have to make some horribly offensive statements.  So, here’s the Wikipedia definition:

In role-playing video games (RPGs), permanent death (sometimes permadeath or PD) is a situation in which player characters (PCs) die permanently and are removed from the game.[1] … This is in contrast to games in which characters who are killed (or incapacitated) can be restored to life (or full health), often at some minor cost to the character.

In my opinion, that accurately reflects what most people think of as permadeath in videogames.

There are two major problems with this terminology.

1.  It assumes that persistence is and should be the default way that things work

2.  It erroneously mis-characterizes “permanent consequences/persistence” as a non-central “feature”

3.  Minor issue, but still problematic – it presumes/implies that every game has some central, singular avatar.  Like, you wouldn’t call non-persistence in Civilization “permadeath”, would you?  “Death”, everyone should be aware, is a thematic element, not a mechanical one.

 

 

Persistence By Default?

Persistence, just so I’m clear, is this concept that you have some save-game file that never gets erased unless you erase it yourself.  It usually means that your character/avatar/town’s power and resources are growing over time.  Each time you sit down and play, you are adding to your save file.  Very rarely is anything ever taken away, and if it were, you could just load the game to just before that point and do that part over.

I’ve met people – only people who come from digital entertainment backgrounds, mind you – who tend to think of persistence as the default way that everything should go, although with a huge caveat:  only for single player.  Videogamers tend to understand that you won’t generally be carrying stuff from one match in Counter-Strike over into your next match (well, at least, that used to be the case… becoming less and less so, with persistent elements in online FPS games being the new norm).

But when it comes to single-player, a lot of people don’t get the permadeath idea.  I’ve heard some smart people say it’s “some kind of joke rule”, as in, it’s so absurd that you would have permanent death in a game, that it must be a joke.  Of course, Tetris technically has permanent death, and so do multiplayer games, and yet that’s totally acceptable?  Why is this?

 

Types of Systems

Many of my readers probably know about my hierarchy of interactive systems (if not, read about it at Gamasutra, here at my site, or in my book).  Today, though, I’ll be drawing a very specific line in the sand that hopefully won’t be too hard to accept.

For the purposes of this discussion, let’s divide videogames into two categories: Competitive Strategy Games and Non-Competitive, Non-Strategy Games.

 

Competitive Strategy Systems are basically things that can be won and lost, that include decision-making, that you can “get really good at”, and are often long-lasting.  Sports are competitive strategy systems, as well as videogames like Civilization, Tetris, and Counter-Strike.

Note that by “competitive”, I do not mean multi-player, and I recognize that that will sound weird to a lot of people.

This is a point in the article where I almost stopped writing because I have to explain so much to get this point across.  Basically, games like Civilization or Tetris at their core are competitive, despite being single-player.  This is due to the score mechanism, the random generation, and the emergent nature of play.

The way that we need to start thinking about single-player competitive strategy games – games not focused around story or experience, but around skill-building, strategy, and winning – should be more like the sports golf or bowling.  We should think of skill-based single player games as actually asynchronous multiplayer games, even if the opponent we play against is ourselves.  This is a big topic, which I sort of just touched on for a recent Dinofarm Games article, if you want to read more about it there.

 

Non-Competitive, Non-Strategy Systems are just the opposite – games that aren’t supposed to be competitive, and aren’t supposed to have deep strategy.  RPGs would probably be the classic example of this, but really most single player entertainment software, especially those driven by a narrative, would fall into this category.

I think that most videogames fit into one of these two categories.  Almost all of the time, “single-player” videogames are in the latter category, with notable exception of stuff like Civilization, abstracts such as Tetris, and also the Roguelike genre.  An example of a non-strategy competitive game, though, would be something like Guitar Hero.

 

Why Competitive Strategy Systems NEED “Permadeath”

For Competitive Strategy Systems, you absolutely MUST have “permadeath”, and I’ll explain why.

  • Reason #1:  Impossible to Balance.  If you have persistence, then numbers and resources are increasing, and the game is getting easier.  If this is a system wherein the player can achieve skill, then you have a two-pronged attack on the difficulty that very few systems can survive.  At the same time the player is getting better, his tools are ever-increasing in power.  In pretty much every system that ever had a chance of being a competitive strategy system but that also allowed loading and saving and persistence, this was the cause of its eventual demise.
If this was a strategy game before, it's dead now due to persistence.

If this was a strategy game before, it’s dead now due to persistence.

  • Reason #2:  Decisions Can’t Survive.  If you can hit undo anytime you want, you never have to make a decision, ever.  You just have to guess-and-check, trial-and-error, slog your way through the entire web of possibilities until you find one that makes you win for any given setup.  In any game where you can just “re-load”, you never have to make choices.

 

What I’m saying is that Civilization should absolutely have “permanent death”.  Tetris and other abstracts already do, as well as roguelikes.

But what bothers me is that people don’t understand that for these kinds of systems, permadeath isn’t some “option” or “feature” that’s nice to have.  It isn’t some personal preference.  In single-player competitive strategy games, permadeath is ESSENTIAL.  The system breaks down into incoherence immediately without it.

This is why it bothers me to hear people say that they “like permadeath” or “dislike permadeath”.  It’s fine to have a preference, but you should understand that if you’re dismissing permadeath, you’re dismissing the single-player strategy game altogether.

Choose-your-difficulty

The “difficulty select” screen from Dungeons of Dredmor actually allows you to turn “OFF” permadeath, as casually as turning on or off the music.  I won’t comment on “no time to grind”.

When Don’t You Want Permadeath?

For non-competitive, non-strategy systems, of course, it’s usually the opposite.  If your system is story based, then you almost certainly want persistence.  You don’t want the player to have to do everything over, you want them to experience the story.  Half-a-story isn’t really worth much to a person, any more than half-a-match of a great strategy game is, so you want them to get through.  It’s no good if you built this amazing story with a fantastic climax if many people don’t even get to that climax.

So, I would say that Zelda should certainly not have permanent death, at all.  In fact, I suspect that Zelda and most RPGs shouldn’t have any kind of death, because these systems cannot support any meaningful consequences.  I expect that in the future, games like these will follow in the steps of Kirby’s Epic Yarn, where death is not possible, instead it’s just that you lose some sort of metagame bonuses for taking damage (note:  you’re still gaining stuff, just gaining LESS stuff).

Other kinds of systems that shouldn’t have permanent death would be “collection” based skinner-box machines, like Diablo, Farmville, or Pokemon.  These aren’t really story based so much as they are just about perpetually adding +1s to your levels.  Since they are always about that – collection – then it doesn’t make sense to really ever reset it.

In short, some systems require permadeath, and some require persistence. It is not like some “cruel joke”, and it’s also not “I LIKE PAIN!!”.  Failure is not punishment, it is a measurement.

So, when I hear that a game has “permadeath”, I feel like the speaker doesn’t really understand what’s going on there.  Like, no one would say that Tetris has permadeath, and not just because of the theme.  To people, it’s obvious that Tetris with persistence would be pretty silly.  It’s also obvious to most (if a decreasing amount of) developers that adding persistence to multiplayer competitive games is a bad idea.

I hope that this article will push the conversation forward, where we can understand what permadeath is in a more holistic way.  If we do, we can realize a lot of stuff, and make better single-player strategy games than the world has ever seen.

Posted in: Game Design

Talk with Richard Terrell turned into interactive presentation

Richard Terrell of Critical-Gaming.com put together this interactive presentation our discussion that we had the other day.  Check it out here on his site, or below!

 

Posted in: Game Design, Game Design Theory, Podcast

GDT Podcast Episode Episode 8: A Talk with Richard Terrell

gdc_page_image

Richard Terrell is a fellow game designer and blogger who runs the site Critical-Gaming.com. I’ve been aware of his site for awhile, and I think he just found out about me in the last few weeks.  Here’s a link to the game he’s working on, BaraBariBall.  Looks cool!

We exchanged some greetings on Twitter (he’s @KirbyKid, by the way), and after a very tiny amount of preparation, thrust ourselves into a friendly Skype conversation about ways of looking at games.

For that reason, this isn’t a normal episode of the Game Design Theory Podcast.  Instead, it’s just a recording of a casual conversation between the two of us.  One thing we talk about is the talk I did at NYFA.  Many disagreements were had!  Enjoy!

DOWNLOAD MP3

(MIRROR if you have any problems)

As always, here’s the link to the RSS if you want to subscribe!

Note – this episode will also be published in a slightly different form over at Critical Gamer.  Will update this post when that happens.

Posted in: Game Design, Game Design Theory, Podcast

Smash Bros: Decapitated

Editor’s Note: Today I’m happy to release the second guest article for keithburgun.net!  This piece is written by lead artist at Dinofarm Games, Blake Reynolds.  Frequent visitors might also know him from the Dinofarm ART BARN articles or from the Game Design Theory Podcast, where he’s a regular.  Enjoy!

psall1I know I’m late to the party, but considering the subject matter, I suspect many have already left anyway.  The party I’m talking about is a rousing discussion about PlayStation All-Stars Battle Royale.  I think the reason so many have departed is because the game was boring and forgettable, but many of these people might not have a full grasp as to what made it so boring and forgettable. Those who are still playing and are trying their very hardest to like or justify this product won’t last much longer, and I’ll explain why.

Most of the flak this game has caught in the past number of months has been quiet little suggestions that it is, well, a little bit similar to Super Smash Bros.  It has features such as Smash Attacks like SSB, directional tilt-attacks like SSB, rolling like SSB, air dodging like SSB, blocking like SSB, double jumps and recoveries like SSB, “A” attacks in four directions on the ground and four in the air,  “B” attacks in four directions, grappling from SSB, projectiles like smash, spiking, items… you know… every single mechanism to the last minute detail.

This complete thievery alone is enough of a blatant, cynical display of utter disrespect for the basic intelligence of the average consumer, and that’s enough to be insulting.  But hey – people re-skin a set of mechanisms all the time.  Re-theme it, tweak a few rules, and voila!  “If you liked original idea X, you’ll love cynical cash-grab Y!”

But plagiarism is not actually the point of this article.  A game can technically be a ripoff of another game and still have longevity, if it’s ripping off something really good and keeping what made the original thing good intact.  The point of this article is to explain why will nobody be playing PlayStation All-Stars next year, yet even Super Smash Bros. 64, the oldest game in that series, is still going strong.  The reason this game will be forgotten in another year is because of what they changed, not what they stole.   Continue reading →

Posted in: Competitive Games, Game Design, Guest Article

The Greater Value of Competitive Games

109698-221223-SC21jpg-620xCompetitive games should be valued by all of us, even those of us who don’t play games competitively.  This is because whether you’re playing a game competitively or not, a competitive game is, put simply, a better, stronger game.  More importantly, a competitive game is more fun to play.

For the purposes of this article, I’d like to define “competitive games” a little bit more specifically than it is colloquially defined, although my definition is still consistent with the definition you’d expect.

 

A competitive game is a multiplayer contest of decision-making that is both deep enough and balanced enough to withstand serious play for at least 10 years.

 

A few notes on this definition.  Firstly, by “multiplayer”, I am mostly talking about two-player games, although I am not discounting games with other quantities of players.  Also, it’s possible that something we’d normally call a “single-player game” could qualify as this if it is score-based.  Tetris, my own AURO, and Golf would be examples of games that could be played competitively, assuming any of them hold up in terms of balance and depth. Continue reading →

Posted in: Balance, Competitive Games, Complexity, Game Design

Alfred MacDonald defends my work

This guy Alfred MacDonald, who’s apparently a Gamasutra writer and a writer for his own blog, wrote an article in defense of my work today.

 

http://alfredmacdonald.com/2013/04/07/leave-burgun-alone/

 

I generally feel that it’s on point, with the one exception being that I think he needs to provide examples of times where I was condescending or dismissive in my actual work, since that’s ostensibly what the article is about.  He brings up points where I was dismissive in reddit comments, which is kind of like asking a person “have you ever been dismissive in your life?“, and therefore somewhat unfair.

Yes, I have been dismissive in my entire life, and I shouldn’t have been any of those times.  But I think people have to keep in mind what I’m up against.  It’s very difficult to not be dismissive at a certain point when dealing with certain people who not only are obtuse about the issues, but very proactively follow me around on the internet and ask the same questions that I’ve answered a thousand times already.

Anyway, I thank Alfred for his nice, well written article.  I am particularly impressed given the fact that Alfred strongly disagrees with me on the topic of story and games.

Posted in: News

The Myth of Difficulty

1565.1276479-difficulty_doom_super.png-610x0

“Game Difficulty”, as we’ve always thought of it, manifests in terms of questions like, “how hard should this game be” and features such as difficulty modes.  Unfortunately, I’ve found that this is a fundamentally flawed concept.  It doesn’t actually have any utility, except in systems that already are broken to begin with.

To clarify:  the myth is not that different games have different levels of difficulty; they absolutely do.  The myth is that we can freely scale that with difficulty modes or other solutions.

 

A Balanced Game

Instead of worrying about “difficulty”, I worry about “balance”.  People tend to think of balance most often in multiplayer games, but the same rules apply in single-player games.  I’ve written at length about the topic of balance for Gamasutra, but for now, it suffices to say that a game must be a tightly-woven fabric that is stable, even when vigorously tested.  When players play it, and do their best to abuse it, its fibers pull at each other in such a way that the attempt at an exploit is quickly countered;  not by some external dynamic-difficulty-adjustment meta-resource thing, but by the system itself.  Good gameplay design is self-correcting, but only when there is balance between all in-game actions and resources.

So, balance is very important.  If you don’t have balance, your game is dead.

How does this tie into the concept of “difficulty”?  Well, let’s look at what “game difficulty” normally refers to.

 

Game Difficulty

Usually, “difficulty” determines how “hard” it is to achieve the game’s goals.  Different people have different levels of skill at certain things, or different propensities for gaining skills, so it would certainly make sense if we could offer several different difficulty “modes” to different players.

We’ve always thought that indeed, this hard-ness can be scaled up and down simply by changing some variables:  how many monsters on a level, how many hit points things have, or tweaking other values.

The problem is that this is not possible in a balanced game.

If you have a balanced game, then you do not have the capability of tweaking any variables at all.  Doing so would necessarily imbalance your game.  Increasing the hit points of zombies in Castlevania, forcing you to hit them twice each instead of once with your whip dramatically changes the nature of how the game is played, has huge effects on secondary weapons, and way more.  The system known as Castlevania has an optimal configuration, a point of balance where the game is most interesting.  Moving outside that is necessarily making the game worse, no matter who is playing it.

An extreme example that can highlight this is Bethesda’s RPGs, wherein hit-point scaling is the accepted way of increasing game difficulty as the game goes on.  The problem is, having to hit a bear 50 times may indeed be “harder” in a way, but it’s vastly more boring.  This is an extreme example of how this kind of “scaling” does not work, because you’re moving away from that optimal configuration.

Designers do have control over the hardness of their game while they are designing/balancing it, but once they’ve finally reached a point of “this is now a balanced, interesting, engaging game” (NOTE: Getting to this point AT ALL is extremely difficult and most designers fail to do it even once), they don’t really have control over how hard or easy their game is.  This is a significant thing to realize!

In fact, the only way to create a new “easier” or “harder” game out of an existing balanced game is to take it apart, change some values, and then put it back together again.  Essentially, though, you’re going to have to balance this other gameplay mode.  It is probably most healthy to think of difficulty modes, then, as variants.  This makes sense, because if you changed some values and then rebalanced the game around that, the game is going to have a distinctly different character than it did before you started the re-balancing.

Half-Caveat:  Most videogames are not balanced to begin with, due to having far, far too much inherent complexity.  So, in these systems, you can indeed get away with having difficulty modes, but it’s quite like how you can get away with murder on the Titanic.

 

Caveat:  Difficulty in Puzzles

In Puzzles, difficulty makes perfect sense, because puzzles do not have to be “balanced”.  Puzzles can be linear, and the purpose of them is solution, so finding some kind of “imbalanced element” has limited effect on the system.

It’s also worth mentioning that many if not most single player videogames are puzzles of some sort;  very rarely are they games as I define the term.  However, most “obviously puzzle” videogames don’t have difficulty modes anyway.  It’s usually videogames that have some game-like elements to them — with “combat” and such — that have difficulty controls, and this is what I’m objecting to.

 

I hope that I’ve made my point clear:  you cannot scale difficulty in a balanced game.  Learning to play a game is learning a discipline, and not all disciplines are equally easy or hard to learn.  Some are harder than others, by their nature, and that’s OK.  Not all games need to be for all people.

 

 

 

 

Posted in: Balance, Game Design

Introducing: EMPIRE

StyleSketch1Today I wanted to introduce people to a new game that I’m designing called EMPIRE.  In order to do this, I think it makes sense to first talk about what already exists, and then talk about what I’m doing that’s different.

EMPIRE is my take on the so-called “4X Strategy” genre of digital games.  I’ve always been a fan of games like Civilization, and even more so of Master of Magic.  I do have a number of problems with the genre, problems which have not been getting better.  For instance, Civilization V, the latest game in the Civilization series, did not correct most of the games worst problems.  You can read about my problems with that game, which are fairly similar to my problems with just about every game in the genre, here.

Suffice it to say that with EMPIRE, I have an opportunity to do what I did for 4X games what AURO does for roguelikes:  namely, find some kernel of an actual core gameplay mechanism, and build a carefully constructed system around that.  So unlike most videogames, this game will be system-based, not component-based.

Why does that actually matter?  Well, because it means that we can have an elegant design, which in turn means that we can have a system that’s both extremely easy to learn, and equally difficult to master.

In short, EMPIRE is a modern, elegant solution to the problems of 4X strategy games.

 

What Is EMPIRE?

EMPIRE is a game centered around the concept of maintaining a growing set of resources.

I often start with some thematic metaphor to help me in designing a game, and with EMPIRE, that metaphor was one of “the rise and fall of an empire”.  I think it’s very interesting and dynamic how a real life empire can grow more and more powerful, but sort of break under the pressure of its own weight after awhile.

I’ve also been playing a lot of Puzzle Strike, and before that, Dominion, and I feel that the “deck-building” mechanism is a fantastic way to express that.  So, the “set of resources” that you’re maintaining in EMPIRE are digital “cards” that you use in battle and win from victories.

So, in a sense, EMPIRE is the world’s first Deck-Building 4X Strategy game!

Right now, the game is in an early alpha stage, so you should expect some of what’s written here to change in the coming months as more playtesting begins.  Also, keep in mind that all screenshots and such are very early – excuse the temporary buttons and such!

 

Working Alpha prototype.  Forgive the temporary art and menus!

Working Alpha prototype. Forgive the temporary art and menus!

 

EMPIRE In Detail

EMPIRE is not only built to avoid the pitfalls of traditional 4X strategy games, but it’s also built primarily for mobile, and the game is being designed around this.  I’ll explain some of the rules to show you how it works.

Essentially, EMPIRE is a war-game.  This puts it in stark contrast with most other 4X games which have a more toy-like “do whatever you want” feeling to them much of the time.  In this game, you are trying to conquer other civilizations in a constant need to take new territory.  Eventually, your civilization will fall, so it is a matter of surviving for as long as you can and winning as many battles as you can to achieve the highest score possible.  To return to the metaphor, you could say that this reflects entering your empire into the textbooks of history as one of the world’s greatest.

When you start the game, you have enough resources to found one city.  When you do create a city, that city starts sucking up resources from the surrounding tiles each turn.  Eventually – and this is one of the most different things about the game – those tiles will produce fewer and fewer resources, until they finally become “desolation” tiles:  scars on the earth that not only produce no resources at all, but actually spawn dangerous monsters.

So, this means that you must stay on the move to keep a steady flow of resources coming in.  And if you don’t keep that steady flow of resources coming in, and a nearby Empire does, well, then you can guess that he’ll likely overpower you.  So, there’s a natural struggle for new, un-desolated territory.

 

Cities

I started with the question, “what are cities, really, in a game like this?”  If we can identify that at its core, this is a war game, then cities are a stepping stone towards creating your army.  With this understanding, we can realize that the system for cities is not central, and should be limited in its complexity.

The system for how cities work is extremely simple, yet still has enough resolution to support expressive gameplay choices.  A city is taking in “food” from nearby tiles, and when it reaches a certain threshold, it “levels up”.  When it does this, you can choose between a choice of 2 buildings.  Once you choose one, that choice is permanent.  You can’t go build the other building now.  Eventually, you’ll level up again, and now you get another choice of 2 different buildings.  This is “Tier 2″, and there are 3 such tiers.

So, you basically have 3 rounds of choices to make, which leads to somewhere around a dozen or so possibilities for the city’s configuration (someone else can do the math for this and let me know the exact number!).

Of course, you can also have more than one city.  We’re currently working with a system where the maximum number of cities is 3, but even to have 3 is difficult.  So, having 1 city is tax-free, but when you have a 2nd city, there’s a decently harsh tax on all income.  So, if you’d normally be sucking up 10 food a turn, now it’s reduced to 8 food a turn, or something.  Which might be totally fine while the surrounding resources are good and healthy, but makes the desolation tiles even more of a threat.  3 cities is almost never sustainable for very long due to a significant tax that’s imposed.  If you have 3 cities, you need to either be constantly winning battles (winning some battles can yield some resources) or just moving quickly to new areas (this would probably require winning battles anyway!).

The primary role of cities is to suck up resources from the land, produce new military units, and produce new Action Cards (which I’ll get to in a second).

 

Ignore the text and HUD stuff, it's all temporary!

Ignore the text and HUD stuff, it’s all temporary!

 

Armies

This is probably the biggest area that “it being a mobile game” helped influence the design, but honestly, mobile design is good design, in a way.  What I mean is, you never want a game to be super fiddly UI-madness;  you always want interacting with the game to be as simple as it possibly can.

With armies and units, one thing I wanted to do away with was the concept of “moving units around from city to city”.  It’s extremely fiddley, and even when you have a mouse it’s just annoying.  Grouping units together, waiting for that last swordsman you just produced to walk allll the way over the map to get to the rest of the group, etc.  I didn’t want to deal with any of that.

So in this game, your army is ever-present.  It’s like a resource.  If you attack something, you have your whole army.  If you’re attacked at any of your cities, your whole army defends.  Making an attack on something takes time, by the way – if you want to attack an enemy city, that city is alerted to it, and it takes a certain amount of time (this amount calculated by distance, the terrain covered, and how many Mounted type units are in your army).

This way, we can avoid any fiddling.  It should make for a really pleasing, easy to use, yet still super strategic experience.

 

Combat

It may be surprising to know that cities are not central to this game.  Armies are also not central.  Armies, too, are merely a resource that is used in combat.  So what is central to EMPIRE?

The EMPIRE Action Deck.  In the game, you start with a deck of about 10 Action Cards.  These are used in combat to give your troops commands.   One of them might say “all archers advance”, one might say “soldiers fortify”, or “all units retreat”.  Some of them have special effects, like making one unit invulnerable for a turn, or even summoning monsters.

When a battle begins, the game draws a number of these that you may use on your turn. First, your troops advance on their own, and then you may use an Action Card from your “hand”.  Then, any combat that is possible happens and is resolved.  It’s a really simple system that’s still highly tactical and interesting.  I made a paper mockup of the combat which worked really well.

Here’s where it gets really interesting, though.  Winning fights is of course, the objective of the game.  And when you do, you gain points.  But here’s the rub:  those points are given to you in the form of a Victory Point card, which goes into your action deck.  Players of Dominion are very familiar with what I’m talking about right now – what this means is that your deck is slowly getting clogged up with more and more useless cards. 

Late game, you may have added lots of fantastic, magical, powerful cards to your deck… but you’ve also likely won a good number of battles, and have a good number of Victory Point cards.  This means that on a given turn, it’s increasingly likely that you might just draw 2 or 3 VP cards, severely limiting your combat options!

Old empires can get Action Cards that re-draw hands to help mitigate this, build buildings to increase hand size, and even sometimes trash some old unneeded cards, but these all come at a cost.

Combat is fought until 3 units are killed on either side, OR the base-line of a side takes 5 damage (it can be attacked).

 

Obviously, this is just a conceptual mockup - not artwork at all!

Obviously, this is just a conceptual mockup – not artwork at all!

 

Throughout the game, not only will young new Empires spring up to try to take power away from your old, mighty empire, but Monsters are also spawning with increasing frequency.  It’s always a dangerous, unsafe world in Empire.  When your last city is destroyed, the game ends, and your score is tallied.

 

Production

I should mention that EMPIRE is not a Dinofarm Games game.  Instead, I’m working with a new team, as lead designer.  The lead artist for this team is a guy named Martijn Holtkamp, who has Age of Wonders 2, Age of Wonders: Shadow Magic, and Divinity 2 on his resume.

Concept art by Martijn!

Concept art by Martijn!

The theme for the game is loosely inspired by Conan the Barbarian illustrations by Frank Frazetta and other similar artists, but also blended with a touch of stylized cartoonyness.  This is all really Martijn’s domain, which maybe I’ll get him to write more about in a future post, but for now suffice it to say that I think the game will look unique.

We expect the game to be out Fall of 2013.  As for platforms, the game is being created in Unity, so whereever Unity can exist, EMPIRE can exist.  Certainly iOS, Android, Windows, OSX, just to name a few.

So that’s EMPIRE!  What do you think?  I’d love some feedback on the idea, and I’ve created a forum over at Dinofarm Games to talk about it.  Eventually, we’ll likely start a beta phase, and if you subscribe over at Dinofarm, you’ll be the first to know about it.  Thanks for reading!

 

Posted in: Empire, Game Design, News

Surprises at the PRACTICE 2012: Game Design In Detail Conference

Note: This article was written a few months ago, right after the conference, but kinda got lost in the shuffle.  Anyway, it’s here now!  Enjoy!

This was the second year of the new NYC-based game design conference, run by NYU Game Center staff.  It was also my second year attending.  So, having been there once before, I went in with some kind of idea of what to expect from each of the list of speakers.

For those who don’t know anything about the conference, it’s kind of like a game designer’s dream-conference.  It’s not a game development or game business conference, it’s not a commercial expo – it’s merely a bunch (less than 100) game designers getting together and talking about their practice of game design.  There aren’t a lot of events in the world that focus so narrowly on my field of interest, so it’s something I’ll be attending every year, if I can.

Now, having attended the conference, I think I can pull everything together into a kind of theme of “surprise”, as almost all of the speakers did not quite match my expectations. That might automatically sound negative, but it actually was positive in a couple of cases where I didn’t expect much from the speaker.  For better or for worse, what I expected to hear was often subverted, and that fact in and of itself was probably of value.

Among the speakers were Richard Garfield (Magic: the Gathering), Dan Cook (Triple Town), Christina Norman (League of Legends), Stone Librande (Spore), Kjartan Emilsson (Eve Online), and many more. Continue reading →

Posted in: Game Design, PRACTICE

Game Systems as Engines

In a video I did recently, I talked a bit about these system-types that I originally posited in my book – the four “forms” of Toy, Puzzle, Contest and Game.  This is not a breakdown of how I see things in the current state of game design, but rather a vision for what I think game design should be.

Before we go on – prescriptive definition warning.  I use common words to refer to very specific things, so if you see the chart and think “what the hell is this guy talking about” – simply read below.  I elaborate in detail about what I mean.

The main reason that this system is useful is because it gives game designers an abstract gameplay purpose to start with.  It answers the question of “what should I be trying to do” at the most basic level.

This might sound arbitrary to some – I’ll address that quickly before going in more detail on this new chart.

 

It’s Abitrary!

Why are the systems Toy, Puzzle, Contest and Game, and not some other kinds of systems?  What were these based on?

As far as I can tell, these are the four things that a person can be doing when interacting with a system.  I suppose that my evidence for this would basically be inductive – I cannot “prove without a shadow of a doubt” that these are the systems, but I have observed it, and I continue to observe it.  In other words, every example of play I can think of fits well into this system.  Secondly, even if it is not “the true four ways” in some absolute sense, it is a very useful way to divide things up.

Of course, some existing systems use a combination of two or more of these types of interaction, but I have yet to find a fifth type of interaction that is unique from these.  If anyone can think of one, or argue that one of the types of interaction that I have listed here is not appropriate, or that two of the types of interaction I’ve listed as different are actually the same, please let me know.

 

Systems As Engines

Late last night, I figured that it might be helpful to see the four engine types laid out in this way:

articleimage

Let me clarify these a bit, because some of these words might have connotations that I don’t mean, but they’re as close as I could get with the words I could find.

Toy – A Toy is any interactive system without a goal / problem to solve.  This is not meant to imply any kind of correlation with “childishness” or anything.  You can also call this a Bare Interactive System.  Many simulators fall into this category.

Play – I mean “play” as in the expression “to play with”, or “to mess with”.  This isn’t to say that this work is necessarily trivial, but rather that it’s exploratory.

Mapping – This is the result of the play I was talking about.  With play, we are finding edges, figuring out how a thing will respond.  Eventually we end up with some kind of mapping of how this thing works.  Interestingly, you could say that the object of a toy is to discover its rules.

HOW CAN WE USE THIS?  A good toy will have a vast amount of rules to discover.  Think Legos, or Minecraft, or a ball.

 

Puzzle – Don’t think about the normal colloquial (and very messy) “puzzle” word.  I simply mean anything with a goal / answer / problem.  So, a math problem counts as a puzzle.

Work – Work has a bad connotation, but think along the lines of a math problem when people say “show your work”.  Essentially, some effort and process towards uncovering the answer must be the input of a puzzle.  (Do not think that this means that solving a puzzle can’t be fun!)

Answer – This is the objective we were searching for.   Once the answer is found, the puzzle is no longer of value to us, because the search for the answer was where the value was.

HOW CAN WE USE THIS?  A good puzzle will have a difficult-to-find answer.  Obvious to most people, yes – but it’s still true.

 

Contest – Thankfully, this definition lines up pretty closely with the colloquial definition, so not much explanation needed here.

Test – Think “stress test”.  We are attempting to find the limits of something.  Note that this is unlike the wide, lateral exploration of “play”.  This is a vertical, straight test of one specific resource.

Measurement – Measurements are inherently relative and can have no meaning without something to measure up TO.  Therefore, all contests compare the measurement (result) to another result, and determine a winner and a loser.

HOW CAN WE USE THIS?  Good contests don’t have a low “cap” on that vertical skill possibility space.

 

Game – This is the most controversial word I use in my system.  Some prefer “decision-contest” and some have suggested “strategy game”.  Either way, the point is that this system, as I define it, is a “contest of decision-making”.  The concept is what’s important here.

Decide – The nature of a decision is very interesting and not trivial.  People have argued to me before that button-inputs in Guitar Hero are “decisions”.  I disagree with this characterization;  I think it would then follow that if you were walking and tripped, that you decided to trip.  “Why did you decide to trip”, only a jerk would ask, because obviously you did not decide this.  To help understand this aspect, perhaps think of decisions, in this context, as conscious decisions.

Games present choices that are ambiguous.  Ambiguous choices are choices that live somewhere between a guess and an answer.  A “guess” would be that you have 0% of the information you need to make a decision, like if I asked you whether I was thinking of the number 1 or 2 right now and you had to make that choice, based on no other information.  An answer would be if I asked you to decide which answer to the following problem is correct:

1+1 = ?

a). 2

b). 9999

The answer is “a”; there’s no ambiguity here, so this does not qualify as what I refer to as a decision.

Understanding – What we gain from a game is a holistic understanding of a set of rules and their ramifications, synergies, and connections.  This is not the same as what we gain from a toy, which is a list of rules.  Instead, this is an understanding of rule relationships, and how to manipulate the system to our benefit.  Obtaining new bits of understanding is of value to us, but once there’s no more understanding to gain, the game is dead.

HOW CAN WE USE THIS?  A game should have a very vast and deep set of rule relationships that we can explore for as long as possible.

 

Anyway, I hope this is helpful for people in understanding my work.  Let me know if anything doesn’t add up!

Posted in: Game Design, Game Design Theory