Levels of Analysis

Some weeks ago Filip Couliuanos did a piece for Gamasutra about gameplay analysis. Its really good, read it. In very general terms, he looks at two AAA action games (Batman: Arkham Assylum and X-men Origins: Wolverine) and basically looks at what the player is doing and how much time he spends doing it. This system simply adds up the minutes the player spends doing a certain action (be it combat, watching a cinematic, solving a puzzle or moving through the game world) and then plots them in a color coded graph.

With the whole game charted you're then able to analyze its overall pacing. In the example above (the pacing graph for X-Men Origins), we can clearly see that boss battles are all piled up at the end of the game, presenting a large spike in pacing. This method is really good at presenting an overall view of a game's pacing; specially for AAA games, where there are several things to do which can be divided in clearly differentiated chunks.

However, if the chunks are not clearly differentiated (for example, if during a puzzle you also engage in combat) this turns into a problem. Couliuanos tries to solve this using the catch-all term "Special Gameplay" which would include any section where the mechanics deviate from the game's core. Although this does not reflect the true pacing of the section, it does help find where a potential spike or valley in pacing could occur.

A bigger challenge comes from games where there is not a lot of variety in what player's do through out the game. Retro, indie and older titles are a great example of this. Beat 'em ups like Streets of Rage, shooters like Contra or vehicle combat games like Icebreakers (shameless self-promotion, I know) don't have a lot of variety in player actions; however this does not mean they have a flat pacing. How then do we describe it. This will be the subject of our next entry.

An elegant solution

Suddenly you find yourself on the spotlight. You discover a major flaw in your game, and anything you do to try and fix it will start to ripple through all aspects of the game....what do you do? Specially when the game has already had some time in production, the prospect of taking a decision that will (potentially) change several aspects of the core game is scary. However, if you discovered an issue with your core gameplay, its a decision you will have to make. Core design problems are game-breakers, and they should be fixed as soon as they show up.

So Generally, when one finds a game design problem your natural tendency is to go straight to the simplest solution. Overpowered weapon, make the player drop it as he leaves the room; walking around is boring, place random enemies around the level, jumping too high, place a ceiling..... These are simple to implement, and they are (somewhat) isolated from the rest of the design, so they become reeeaaally tempting. However, there lies its problem. They are patches, they are not integrated with the design and they don't really solve the core problem.

On the other hand you could try and implement a whole new design; scrap everything, we're taking it from the top. New design means new programming, new assets, new everything.... but its worth it, to make a fun game. That is until you try to explain the rest of your team why it is that all their hard work is to be scrapped. Iteration is a given in the industry, but with milestones coming up and angry managers demanding to know what's the hold up, you can't restart the project.

So what to do. Well there is a third option....I'll be honest, its tough, its not evident, and it might be tricky to explain. The idea here is to slightly change the environment around the problem so it becomes a non-issue. Its much more subtle, instead of blocking the player from taking an action, you make it riskier, you try and dissuade him. I call this an elegant solution.

An elegant solution is the one that tweaks the game in such a way as to turn the flaw into a choice. Without forcing the player's hand and without redesigning the mechanics, the elegant solution changes the circumstances under which the player makes his gaming decisions. For example: imagine a 2D shooter where the player has a high jump. This is important because it allows the player to jump onto platform, start combos, etc... However, this is also gives rise to bunny-hopping. You find out the player is able to jump all through the level and not even fire a shot. If you're already in production, go back and change the jump height will be a level apocalypse: platforms will have to be reset, art will have to be remade, months of work will go to the recycling bin. On the other hand you could stop the player from shooting while jumping. Then the game looses part of its essence, it looses action, and the problem still persists.

A third option would be to reduce the horizontal speed while jumping. Sure the player can keep avoiding bullets by jumping, but now he won't be able to advance as fast.....he has now a choice. Now the player can choose: slow and safe by jumping, or fast but challenging by running. Of course, for it to be truly meaningful, there must be some risk on both accounts; maybe you could sprinkle some AA enemies throughout the level. This solution only affects the player and enemy positioning, and it creates a new set of meaningful decisions. This would be an elegant solution.

The value of clasics

A couple of days ago I bought Archon: classic through steam. This little known gem is a strategy game created in 1983 (one of the first strategy videogames ever created) for the 8-bit consoles of its time (Apple II, commodore 64, NES, etc...). I had never played it before, but beign a nut for strategy games I couldn't resist not playing it. To my surprise I found that, even though the gameplay is quite deep (with different abilties per side, tactical differences depending on the square and global powers for the palyer to activate) it was plagued by technical issues. The version I bought was a modern reskinning, and yet I found it was plagued by bad AI pathfinding, graphical glitches and other technical errors.

At first I was shocked....they surely didn't put much effort into this homage. But then it hit me.....this game came out in the early 80s...what if all those glitvhes are actually PART of the game. It would make sense for a game in the commodore 64 to have bad AI pathfinding; lots of games had those issues. Then I became very exicted as I thought that I was having the "authentic" 1980's experience. The real deal.

This got me thinking....when porting an older game, should the designers update them completely; including their AI, gameplay, etc... or should they leave them as they were? Actually the game offers a solution. They did both. They have the classic version (8-bit graphics and sound, original gameplay, buggy AI) and the modern version (updated graphics, couple new mechanics, but still buggy AI). This what all developers should do if they find themselves rebooting an ancient game, offer both the original and the updated version. I know this means more assets, but considering the original assets are so old they are basically antique that shouldn't be much of a problem. Using this method you are sure to present a contemporary gaming experience AND pay due respects to the original.

Design == Communication

The role of a designer is somewhat fuzzy to define. Truth is, they do lots of stuff that are not always related to each other. From scripting to script-writing and from difficulty curves to HUD design, the designer touches many areas (thou by no means masters any of them completely). What this does is that we have a wide array of "types" of designers. Even if its not a formal position, every designer knows what he is good at and what he enjoys doing most. For example, I've always considered myself first and foremost a system designer (which means I'm good at game mechanics) with story design coming in on a close second. Level design and usability design.....well let's just say I'm working on improving them :)

One would think that this means that different types of designers need different skills, and its true. A hard math base is not as useful for script writing as it is for scripting. However there is one skill that is absolutely essential for any designer. They need to be a good communicator. And I'm not just talking about communicating with the player; this is a given. That's the whole point of designing games in the first place. I'm talking about communicating with your team. As mentioned above, the game designer can't be a specialist in all areas; hence he has to be able to get the whole team to truly understand a project and how what they're doing fits in the big picture.

Failure in this is terrible for moral, as the team stops feeling ownership over the project once they see their work being scrapped due to a misunderstanding. This is the designer's fault, and as such, he has to take responsibility to fix it. Word of advice, make your meetings as clear, as dynamic and as engaging as possible. At first, my meeting with the team consisted of handing out lists of the assets/mechanics/what ever, and together going through them. This (in theory) allowed them to spot troublesome parts right away. However in practice, they lost attention half way through, and found it hard to remember what was said (or even if the meeting took place!). Bad communication. Now what I do is create a simple, graphic, animated PowerPoint presentation that explains the general ideas. It sill analyzes everything one by one, but because they can see it in "action" its easier for them to understand it and remember it. Of course, its more work on my part to create a slide presentation, but its definitely worth it.

When do we face the enemy?

Turn based strategy games have been around for a long, long time. Older than real-time strategy games, older than you and me...heck, even older than the country we live in. Checkers, Go and Chaturanga (the forefather of chess) have existed for millennia, and have greatly influenced our perception of what constitutes a game. It is then no surprise that they are also represented as video games. From the early adopters such as Civilization, to forgotten gems such as Heroes of Might & Magic, many great games have assimilated and expanded the same basic mechanics that were created by their tabletop counterparts.

Thou we can spend another century or two analyzing every aspect of what makes TBS games tick, today we will compare just one aspect, the order the execution of your orders during your turn; in other words how your turn plays out. In most strategy games, the core mechanic consists of issuing orders or moving units in order to achieve a goal (generally killing/eating/ hoping over another unit). However, once you have issued the command, the order in which they are completed changes the strategic importance greatly (and in that sense, the whole game). There are two mayor ways that units can execute their orders: they can be followed immediately after the order is given (as in chess or XiangQi) or they can be done simultaneously with the other units at the end of your turn (as in Diplomacy or the videogame Frozen Synapse).

Games where the units follow their command just after the order is issued are more reactive in nature. Thou a good player will try and predict the opponent's strategy, at a tactical level he will be concentrated in reacting to the current game state (how the unit and board are accommodated at any given time). For example in Risk; because each combat is resolved right after the attack, and due to the random nature of the combat, the player's moves are determined directly by which battles he won or lost. If he is able to enter a new territory, or if he must press an attack....all these are dependent on what just happened. This allows for a (relatively) fast pace, as the game state is very fluid and the changes it takes are incremental.

On the other hand, games where the units move simultaneously are more predictive in nature. As all combat is resolved at the same time (or at least without the player intervening) then the player is forced to think about how all their units will end up after the dust settles. In many games that use the mechanic, the opponent's orders are ALSO executed at this time, so the player has to also try and predict what his enemies will do. This is the case of Diplomacy, where player's write down their orders and then execute them at the same time. Here you really don't know how the map will end up, and hence the importance of allies and betrayal. Here the pacing is slow (-er), as the preparation phase of attacking carries a lot more weight. Even if it changes few times during a game, the game state changes dramatically.However, the moment the orders are enacted are incredibly tense.

There are then hundreds of little variations on the exact issuing of orders, how combat is resolved, etc that change the game's flavor, but those are too many to list here. However, one of the most important decisions on designing a TBS game is this one, when do we face the enemy?

Moving along

A picture can say a thousand words; animated it can say another thousand. Movement adds a whole new dimension to the message sent by an image (time to be precise). This also applies to game design, and its useful to keep in mind at all times. When designing a new enemy, when considering player feedback, even when planning game UI; movement allows the player to better understand your world at a glance.

Now, movement, is not the same as speed. Speed can be baffling; it can confuse and frustrate. Almost always, high speeds signify danger. Sometimes that's exactly what you want :) The eviscerating vertigo that comes from moving rapidly is always exciting. But then again not all games are to be exciting, sometimes you want them to be peaceful and relaxing....even then, movement is important.

Take a game such as Flower for example. The game is meant to be appeasing, to have a zen-like quality to it, that makes very different to what most gamers are used to. The serene skies and colorful grounds make it very easy on the eye. However, its the movement of the blades of grass, the playful tumbling of the flower petals that really sells you the pastoral scenery. Picture if you will, the same colors, the same grass and the same flowers....but all still. As an image in a gallery it would be very pretty to look at, but it wouldn't be alive. It'd be stiff, as a corpse, beautiful but not reachable, as it would follow its own rules, in a world without time. In the end, only death is truly still.

When thinking how to communicate with the player, how to create emotions, remember to play with movement. Be it adrenaline-pumped action sequences, or peaceful reflection, it can all be accentuated by making even the tiniest animations to the tiniest parts of the game. Few images are associated with an apocalypse as much as the sight of paper fliers being carried by the wind. Few scenes accentuate the beauty of nature as much as running water. If possible include movement in all possible aspects of the game, even if its very slight, as this way the world become so much more alive.

Why I want to fail

Last week I started playing Zynga's Empires & Allies. Its a Farmville type game with a little bit of RTS sprinkled above it, such as combat (well a toned down, pick-a-party-and-compare-their-stats type of combat anyway). This does add depth to the game, as finally your resources are spent in something other than more resource-makers. This would, in theory, allow the player to choose over which resources to spend and how to do so, as not all investments are guaranteed returns. If you build a battleship, it may sink, and all those resources go down with it.

This is good; this is a meaningful choice, and that's what good games are made of (more on that in a later post). Yet there is a glitch in Zynga's plan (at least from my perspective); you never fail. In other words, you harvest so many resources with so little effort that you'll be hard pressed to get those counters to zero.

In theory this would be a non-issue. The more resources the player has the more he can spend and the happier he will be. Its this logic that's behind this decision; and for the most part of Zynga's audience (the casuals), it works. They keep spending and they keep happy. However to appeal to a more core audience, the game has to allow the player to f@#$ it up...

This is because, no failure state subtracts from the total depth of the game and the meaningfulness of player's decisions. If there is no punishment for making a wrong turn, then the player is able to keep making those bad calls. It doesn't matter what you decide...you'll keep winning. And if your decision doesn't matter, than the game lacks depth. This is not exclusive of casual games; many MMO have the same problem at high levels. Also GTA had this issue, by the end of the game you had so much cash and so few things to spend it on, that the players just ignored it. There was simply no meaning to it.

Its ok to give the player a helping hand; or to make a game easy. Some people just prefer to play relaxing, unchallenging games. And that's fine. Flight Control, Angry Birds and Bejeweled are great, relaxing casual games; but they all have a point where you can lose the game. Never forget to include it.