[Having come off of the complicated and lengthy process of developing and releasing iOS title 100 Rogues to limited success, developer Keith Burgun radically rethought what he wanted to achieve and what was even possible -- and in this article describes the ideas that led to his next game, Auro.]

In my previous Gamasutra article, "The Cautionary Tale Of 100 Rogues", I described the process behind designing, developing and marketing of my 2010 iOS game, 100 Rogues. My team, Dinofarm Games, and I have started working on a new game. While, on its face, it shares many surface-level things in common with 100 Rogues, I'd like to explain how and why I went back to the drawing board and looked at the fundamental aspects of the genre.

The new game in question is called Auro, named after the spoiled prince protagonist. To describe it in a line, it's a "turn-based, hex-based, dungeon-crawling strategy game". Note that it's not a "role playing game", and it's not a "roguelike". Which is funny, because the game's original working title was actually "THE ROGUELIKE".

However, as you'll see, my design process and philosophy stripped away so many elements of these genres that when I stepped back, I realized that what I had on my hands no longer fit that title. Players will decide for themselves, of course, but by sticking to a philosophy, I think I've stumbled upon something entirely new.

Not that it really needs to be said, if you've played 100 Rogues, but I'm a huge fan of roguelikes; Dungeon Crawl and Shiren the Wanderer are two of my all-time favorite games. However, I also think there are inherent problems with the genre. Some are probably thinking, "Yes -- they're too hard and unforgiving". Actually, though, I think that's one of the main things they do right.

The fact that these games are challenging, and your choices actually matter (because if you make a wrong choice, there are consequences that cannot be undone -- imagine that!) are exactly what make them fun and interesting. The problems as I see them with roguelikes are issues that face most video games: over-complexity, unfocused game design, and temporal inefficiency.

Over-Complexity

Before video games, there were still games, of course; board games, card games, sports, word games, and little "don't step on the black tiles!" type-games created by children. However, before computers, games had to be simple for practical reasons -- they were limited by the physical realities of the medium. For example, if you want your sport to catch on, it's very nice if a few friends and I can play with nothing more than a ball and a field. If we need 12 different types of balls, several goal-types, and lots of other equipment, we're just less likely to go to all of the trouble.

Computer games, however, do not have this limitation at all, and developers really take advantage of it. In fact, such great advantage has been taken of this ability to continually add more complexity to games, that we're now completely taken in by a sort of "more is more" philosophy.

I think that this negatively affects almost all modern video games, and with DLC and in-app purchases, the problem is certainly not going away (to put it lightly!)

But more is not always more. When adding "more" to a game you decrease the likelihood of being able to balance the game. If the game is not balanced, then a dominant strategy emerges -- that one weapon or unit or move that everyone uses over and over. Now where did your complexity go?

All of that effort designing, creating and implementing those features was wasted. Your game now effectively contains only a few usable items.

Great games usually don't have a ton of inherent complexity -- that is, the complexity of the rules and content. Great games have a limited amount of inherent complexity, and a great amount of emergent complexity -- the complexity that emerges through play.

For a great example, think of Go or Tetris -- the ingredients of the game are super-simple, but when you put them into action, it unfolds into an awesome array of meaningful choices. This is where we get the (now lost?) mantra that games should be "easy to learn, difficult to master". Many modern video games these days end up feeling more like an asset tour -- look through all the assets, use them all once, and then buy the next game.

Finally, we also want to be very careful when adding "more" to our game designs because the more we add, the more difficult our games are to learn. That's part of why we have this expectation that the first act of our games will be a tutorial -- because if anyone uninitiated by video games tries to play Ocarina of Time or Fable, they'll likely have a hard time picking up all of the complex rules from scratch.

This issue of more being more absolutely affects roguelike design. One could almost say that part of Nethack's appeal is this novelty idea that the game includes almost everything one could imagine (in fact, I believe it even includes a kitchen sink). Dungeon Crawl: Stone Soup has, even by the admission of the lead designer, too much stuff. Early on in the 100 Rogues' development, I noticed that I was trying to add too much stuff as well. We had originally intended for many more weapon and armor types to be in the game, but stumbled into problems.

Unfocused Game Design

The second problem with roguelikes is a bit more fundamental. This means that while you don't see as many resulting surface-level issues, the problems that it does cause are actually more harmful overall. This problem I'm talking about is unfocused game design. Students of the modern era of video games will find this concept truly bewildering, I think, but in my experience it is absolutely true for games and for all arts in all mediums.

A game design should have a specific purpose; one single thing that it is trying to do. The reason is that a game is, at its most basic level, a machine that does a specific task, that manipulates human emotions in just the right way using patterns of tension and release to get a very specific desired effect. Good stories are driven by controlling ideas; good essays are driven by thesis statements; and good game designs are driven by a very specific target gameplay experience.

I teach game design classes at a small local art school, and one of the first things I teach is when designing games, we should first start with the question, "what is the fundamental, essential experience that we want to have?"

Keep in mind, these essential experiences should usually be something abstract -- some interesting new spacial relationship, or resource-managing pattern, etc. Then we try to figure out what core mechanism would express that experience best.

All gameplay mechanisms should be in direct support and directly related to your core mechanism. Then, the last step should be to choose a theme that makes your game as clear and easy to understand as possible.

With roguelikes, it's rather unfortunate that this is not the path their design takes. They start off with the theme and a whole kit of gameplay mechanisms, which relate to each other only in nebulous ways gameplay-wise.

To name a few, Nethack is about tactics, exploration, resource-management, character planning, as well as simply learning what all the items, monsters, weapons, and armor in the game actually do. For this reason, none of those mechanics are particularly well-developed in the game; it's a Swiss Army Knife game design. And because it doesn't do any one thing particularly well, we get bored more quickly than we would with a game like Super Mario Brothers (NES) or Puerto Rico (board game), both of which do one thing extremely well.

An unfocused game design is also much harder to balance (since mechanical relationships are far less clear). Finally, a messy game design document usually leads to a lot of...

"Temporal Inefficiency"

Games are about making interesting decisions -- this is what defines them. Compare them to something like puzzles or toys or simulators, none of which have the explicit need for decisions (if there are any to be made) to be interesting. But start up most any modern video game, and you'll find that you're usually only making interesting decisions a handful of times in an hour of play.

To test this, have a friend manage two separate stop clocks. The one on the left will go, straight, for 20 minutes, while the one on the right will only count the seconds while the player is making an interesting decision. With most modern video games (particularly single-player ones), most of the player's time will be spent running down a linear corridor, watching a cutscene, pressing "A" because the game told him to press "A", load-times, grinding for stats, or other no-brainers.

In 10 hours of modern video games, I predict we spend nine hours waiting for the one hour of actual fun. This is the rate of temporal inefficiency for a game, and I find a low one to be disrespectful to the audience.

While roguelikes are far from the worst offenders in this regard, wasting the player's time is a huge problem for the genre. Dungeon Crawl has huge labyrinths that you have to explore in order to play, with interesting encounters happening once every 20 or 30 turns. I soon realized that there is an "auto-explore" hot-key: "o". Pressing this button has the computer automatically explore the dungeon in a decently efficient way.

Indeed, I use the o key all the time, because it explores just about as well as I could and it's much easier than moving around via the numeric keypad. However, it's still time I have to waste getting to the interesting encounters, waiting for the decision-making sections. If you ever have a gameplay mechanic that's such a no brainer that it can be automated, it should be cut.

Every roguelike I've ever played has had monsters whose abilities are not made clear to the player. To learn what they have to do, you have to pretty much bump into them and let them do it to you once or twice. So, essentially, it may cost you one game in order to learn what a monster even does, wasting your time further.

100 Rogues

I think by now my positions on all of these topics have by now ever-so-subtly leaked out. Developers should respect their audience and recognize that their time is precious. The fact that they're giving you any of it at all is an amazing gift. Repay them with a slick, well-oiled machine that does nothing but dispense interesting interactions.

To be clear, I'm very proud of 100 Rogues, but it is guilty of all three of the above sins. I approached the game just the same way as most roguelike developers do: "let's make another roguelike game!" And so it came with the entire kit of not-so-related mechanisms (exploration, resource management, character planning, tactics, etc).

And because of this, it also suffered from some subtle kinds of over-complexity. Did we need throwing (meaning, the ability to throw any item in the game as a weapon) to be part of 100 Rogues? I thought we did because other roguelikes had it. But does it really need to be there? Does it help support the core mechanism? What is the core mechanism?

The truth is that I was learning a ton while I was making 100 Rogues, and about halfway through the (long) process, I realized that we did, in fact, need a core mechanism after all. However, it was too late. We'd already invested too much in various functionalities to cut them out.

In hindsight, I think 100 Rogues was my attempt to take the status-quo modern video game philosophy, and see how good I could make it. Well, now I've seen, and the more I learn, the less satisfied I am. So for our next game, we're looking deeper, and targeting all of these problems at their roots.

Auro

I started designing Auro almost a whole year before the game's development actually began. I knew early on that there needed to be a core mechanism, that the game needed to be as simple as possible, and that the game needed to not waste any of the player's time.

I decided that the core mechanism for the game would be tactics. Players would use special tactical skills against the tactical skills of the monsters.

This would make as much of the complexity and interrelationships be right there, on the grid, visually clear and obvious, not hidden away in a series of numeric stats on a menu screen somewhere. The game is about positioning -- positioning yourself, positioning the monsters, positioning your abilities.

I wanted to downplay the role of hidden complex numbers as much as possible.

I wanted to avoid things like, "Oh, that demon has 324 hit points, and he deals 33 damage a turn, and I have 131 hit points, and I deal 42 damage per turn, but I'm using a +3 fire sword, but he's got 10 percent fire resistance, and he also has 20 armor points, and I have 32 armor points, and..."

It's nuts! This is how our games work! Why would we want to obscure our gameplay with complex mathematics?

Auro's game design philosophy

Most monsters in Auro, even late-game, have 1 hit point. Some have two, or even three, but generally most have 1. For the entire game, your attacks deal 1 point of damage (no stat-scaling -- one great side effect of removing this is that it forces me, as a designer, to come up with an interesting role for every monster in the game -- no "demon" and then "super demon" with 2x HP).

Many abilities you have don't deal damage directly; they either change positioning of yourself or monsters, debuff monsters, or deal damage in very special circumstances. Usually, you've got to use more than one ability in concert in an intelligent way to actually maximize the benefit of most skills. This keeps all of the complexity, again, right on the screen.

You can literally see the most important information right on the screen -- the positions of the monsters in relation to yourself. The game's all about taking that information and making decisions about how you're going to move, attack or use skills.

All inherent complexity information should be made easily available to the player. The game has an in-game manual that can be accessed at any time, that contains information about all monsters, mechanisms and particularly the skills. When you start a new stage, it tells you exactly what monster is being added to the mix, and it tells you what he does.

Then, you choose a skill (meaning that there's no need to "save a point" when you level up to see what you might need later). That's right -- you choose a skill every level -- there are no experience points! Of course, just because you know what a monster can do, doesn't mean you'll know how to deal with what he does, in the specific situations you'll encounter.

Speaking of skills, the bulk of the game's complexity is in the "Disciplines" system. Each monster type has one or sometimes two skills, but the player has five discipline trees -- Power, Ice, Fire, Elude, and Guard. Each of these has about five individual skills in it. The player can mix and match skills to create a unique character each time they play. So, you can see that Auro does indeed have a character-planning mechanism, but you can hopefully also see how it very clearly and directly relates to the core mechanism -- tactics.

I also condensed down equipment into the skills system. Instead of there being an "armor" item you pick up once and then it just passively protects you without you having to think about it, now there is a Fortify skill in the Guard tree. This spell requires planning to deploy, however. It defends you from some damage, but it lasts for five turns, and you cannot move while it's on. This means that using it is a tactical choice that must be thought about, rather than just a dull +1 to your character's stats.

Maps don't follow roguelike convention at all anymore. Auro is not about exploration; exploration has nothing to do with the core mechanism. Auro's maps are more like "courses"; they're randomly generated, still, but almost totally linear and shorter than most dungeon maps. This has the added bonus of not needing a mini-map, which smartphone screens simply do not have the real estate for anyway.

You may be thinking that Auro is completely without randomness, but that isn't the case. The maps are random (if linear), the item placement, monster placement, monster selection (levels will have different monsters in it from one game to the next) and more will definitely be random.

With regards to making sure we aren't wasting the player's time, much has already been addressed. Linear, small maps means that from beginning to end, the game is nothing but interesting decisions. But here's a huge one that most developers probably aren't willing to even consider: cutting animations.

Developers of turn-based games need to understand that in a turn-based games, animations do not have any gameplay meaning, as they do in real-time games. Therefore, in any roguelikes where there is animation (there aren't many, 100 Rogues and Shiren the Wanderer come to mind), the player is sitting and watching animations. Auro will still have some animation, but it will be very limited. Characters will slide from tile to tile like game pieces, and spells will happen quickly with nice-looking animated effects. Idle-animations will still be there when you're not moving, so the game will feel alive.

Auro has a very focused, clean design, that still allows plenty of room for players to experiment and become better at playing the game. Whether or not it resonates with players is yet to be seen, of course, but I can honestly say I'm making exactly the kind of game I would want to play as a player, and what more can we do as game developers to ensure our success than create something we really believe in?

What can you take from this?

Even though I arrived at my approach to game design slowly and through much of my own calculation, I think that it is quite similar to a "classical" method of game design. I hope that more game developers consider this approach for their game, regardless of genre. Ask fundamental questions.

Many of the greatest modern games have done this. Spelunky pondered "maybe it makes more sense for a platformer to have randomized maps". Super Smash Bros. pondered "maybe fighters should be less about what moves/combos you're doing, and more about where you are positioned on the screen." Shadow of the Colossus pondered, "maybe we don't need to populate our maps with a bunch of small easy-to-kill monsters; instead, you only fight the Colossus".

We're in a very early immature stage of the history of video games, and there are fundamental problems with just about every genre that need to be addressed. As much as I like 100 Rogues, making games like that is not the job of game designers. You don't need a game designer to make another game like 100 Rogues. You need programmers, artists, musicians and all of that, but you don't need game designers. Regardless of how it's received, I'm proud of my work for Auro, because it is a game that was truly designed.

A few words on Auro's progress

Even though the game design started over a year ago, formal production of the game only began in July 2011. Our production schedule aims to complete the game in three months, but it will likely be at least a little longer than that. Playtesting is of paramount importance, of course, and so one thing we're doing with Auro is starting off with a Flash prototype. Our programmer is most proficient in the language, and it's easiest to test out different ideas and make sure none of them are absurd nonsense.

Of course, you can keep track of our progress via our official site. We'll be needing Beta applicants soon!