Friday, July 24, 2015

Mechanical Value and Variation


A guide for gameplay variation

Gameplay variation is an important aspect to keep the game experience fresh. There are two different kinds of gameplay variation in video games.

  • Mechanical Variation
  • Numeric Variation

The following article will explain the differences between the two and hopefully provides helpful tips on how to develop gameplay variation for your game design in a structured way.

Gameplay Variation


Gameplay variation is the kind of variation that provides a number of different experiences when it comes to the gameplay of your game. Gameplay variation helps to give players different kinds of experiences when facing the challenges in your game. Every gameplay variation you add to your game should add some kind of value to the possibility space that your players can experience in your game. As long as the player is able to learn, explore and practice new things about your gameplay chances are good that he doesn’t get bored.

Mechanical Value and Variation


Your game will have a gamestate. Players will have a mental model of your game and the current gamestate that tells them how they think your game works and (in the best case) a goal they want to achieve. Usually they try to manipulate the gamestate to their favor until the gamestate says that they have achieved their goal, the game is over or they quit the game before. Players manipulate the gamestate with the their input device to interact or make use of the accessible gameplay mechanics in your game. For example: Lets take a look at a very simple imaginary game, a FPS with conventional controls where players are on a blank field and are able to move, aim and shoot with a single weapon. The goal of the game is to set the hit points of every enemy player to zero by shooting at them. Players will try to use moving, aiming and shooting to manipulate the hit points of their enemies.

Every gameplay mechanic you add to your game should give your players things to consider when it comes to manipulating the gamestate to their favor in achieving their goal. A gameplay mechanic that isn’t relevant in a meaningful way for any of your players through the entire game is a useless mechanic. The more a player has to consider how to make use of specific mechanic the more value it has. Moving, aiming and shooting are very closely related to each other in a FPS. By moving around you can also change your view and make it harder for other players to hit you. With aiming you can control if you will miss or hit your players when you shoot. Every mechanic in those features has to be considered and used almost all the time in relation to each other when players try to manipulate the game state to their favour as they try to win the game.

A lot of FPSs do not have only one level that is a blank field. Usually they have some kind of environment. As you can already imagine, this mechanic also has a very strong relation to every other mechanic. Now players have to consider their surrounding environment all the time. Moving, aiming and shooting can have huge dependencies to the environment so you can say that adding environment may be a mechanic with a lot of potential.

If we want to make the most use of our different mechanics, we have to take a closer look. I guess you already thought that adding environment is in fact not just one mechanic, and you’re right. There are at least 3 mechanics. Let’s take a look on how the environment mechanics affects our player when it comes to the gameplay:

  • He may not be able to walk through
  • He may not be able to look through
  • He may not be able to shoot through

There is a method that I really like when I want to squeeze the most variation out of a single feature like “environment”. I take a look at the dependencies of the different mechanics and think about them as bool variables and combine them in different ways. A bool variable is a variable that has a true/false state. Let’s take a look at the table:



Metal Wall
Wood Wall
Glass
Bulletproof Glass
Fog
??
??
Can shoot through?
No
Yes
Yes
No
Yes
No
No
Can look through?
No
No
Yes
Yes
No
Yes
No
Can walk through?
No
No
No
No
Yes
Yes
Yes

As you can see, here we can come up with ideas that we can definitely prototype and see how they feel and how much value they add to the gameplay experience. Take the most promising combinations first and see how much value they will add to your game. As you can see I left the last two examples blank, maybe you can come up with ideas by yourself? :-)

Bool variables describe mechanical variation and give you a good sense where you can look for promising gameplay elements for your game. It won’t save you from prototyping and iterating but it gives you a methodical approach on how to proceed when looking for variation.

Strong dependencies between different mechanics can lead to a lot more different game states than single mechanic could do on their own, as a well known quote says: “The sum of the parts is greater than the whole”. If the player is able to manipulate the game state he should be able to make a decision based on the currently provided information on how to manipulate the game state to his favour in the most promising way. As soon as the game and the player arrives at the new game state he should get some kind of feedback that provides new information and the cycle repeats itself. The more game states your game can have, based on the mechanics you provide, the more your player is able to explore the different possible outcomes and is confronted with situations with uncertainty where he has to make decisions on how to achieve his desired game state. This is something good, as your game keeps providing something to learn for a long time.

Adding new mechanics is easy, adding new mechanics that have a lot value and can lead to a lot of variation in the different game states is hard.

As every new mechanic is something your player has to learn until his mental model is complete enough to make educated decisions in the different game states, it is even more useful to have lesser but stronger mechanics.

Different weapons in FPSs are a common way to add variation. To have a mechanical variation between your weapons you have to take a look at the fundamental mechanics that describe them. There is no mechanical variation between a machine gun and a pistol. But there is a  mechanical difference between pistol and shotgun that fires several projectiles that spread in different directions. Of course you can go always further with mechanical variation like adding mines or other things that work fundamental different than other weapons in your game. But as soon as you add a new feature, think about the fundamental mechanics that describe this feature and think about possible mechanical variations. This is mechanical variation in gameplay. Now let’s take a look at numeric variation in gameplay.

Numeric Variation


As I already said the variation between a pistol and a machine gun doesn't lay in their mechanic it lays in their numbers. The variable numbers that are placed inside the functions of the code make the difference between a pistol and a machine gun and give them their different flavour not their mechanics. Let’s make a list of all the numbers that could be important to describe a possible gun mechanic.

  • Damage
  • Range
  • Projectile size
  • Projectile speed
  • Projectile Weight
  • Shooting frequency
  • Weapon Weight (Slows movement)

As you can see these are at least 5 mechanics in a simple gun that need numeric values and there are a lot of FPS out there that have a lot more mechanics in their guns. These numeric variables are very mighty and can provide variation that is valuable and not as expensive in terms of effort as adding completely new mechanics. This means that as soon as you have enough mechanics that need numeric variables, this could be a good place to take a look when you want to add variation to your game. It is also valuable because players do not have to learn something new. It is just different, but not new: The rules are the same just the numeric values differ from each other.

There is a efficient way to look for possible numeric variation in your variables and it is very similar to the method that I already showed you above. You make a table with all the different numeric variables and add different values.



Weapon 1
Weapon 2
Weapon 3
Weapon 4
Damage
Low
High
High
Very Low
Range
Medium
Low
Very High
Medium
Projectile Size
Small
Very Big
Medium
Normal
Projectile Speed
Fast
Slow
Very Fast
Medium
Projectile Weight
Light
Heavy
Light
Light
Shooting Frequency
Slow
Very Slow
Slow
Very Fast
Weapon Weight
Light
Very Heavy
Heavy
Medium


With this kind of technique you can explore the possibilities of your already implemented mechanics even further in a structured way. This won’t save you from iterating but it helps you to get an overview about the possibilities. The stronger the numbers differ from each other the better are your chances that your guns / units / skills / etc. will feel different in a meaningful way so they will add variation and work as a true alternative to consider for your players when they want to manipulate the game state to their favour. This will make your game experience richer as different players are biased to different types of gameplay.

If you are not able to create meaningful variation within your available mechanics and variables you may consider adding new mechanics. Maybe we have the feeling that our guns are not able to provide gameplay that creates enough value for the gameplay experience. So let’s add ammo and reload mechanics that will add more variables, this time we will see a mix from the bool and numeric variables.
Here are your variables and a few examples:


Weapon 1
Weapon 2
Weapon 3
Weapon 4
Needs ammo?
Yes
Yes
Yes
No
Needs to reload?
No
Yes
Yes
-
Magazine Size
-
High
Low
-
Max Ammo
Low
Medium
High
-
Reload Time
-
Slow
Very High
-

After you have added this mechanic you can look for different combinations and try promising outcomes. If you want to go further you can think about adding a new mechanic to acquire ammo.
This may look like the following:


How to acquire ammo
Weapon 1
Weapon 2
Weapon 3
Weapon 4
Walk over ammo
Yes
No
Yes
No
Regenerate over time
No
Yes
Yes
No
Ammo Regeneration / sec.
-
1 / sec.
0,2 / sec.
-


The number of different combinations grows exponentially. You will develop a feeling on when to add new mechanics and how to play with the different variables that you already have. This tool helps you to stay on track and may discover potential.

Last Words


You may have a game where you have a lot of trigger mechanics, effects, conditions and targets that describe how specific things work in your game (Hello Hearthstone). So you may have more dimensions. In this situation you may have to invent your own approach on how to look for variation in your mechanics. The most important thing is that you get a feeling for possible combinations from the mechanics that you already have. List everything that you have and check all the possible combinations with an systematic approach. How can you recognise the different combinations of your mechanics and how can you add even more variation with their numeric variables? The best thing you can do is to create some kind of tool with your programmers that gives you the possibility to make use of the different mechanics and combine them in an effective way. Just keep in mind to have a systematic approach. It’s cool and fun to just add random effects and triggers and combine them as you like but you run in danger of missing potential and lose a lot of time. You all worked hard on the different mechanics in the game, so why shouldn't you make the most use of them. :-)

After all you still have to know what kind of experience you want to create with your gameplay mechanics. This methodology can help you to take a closer look on how to achieve it with your already implemented mechanics and when you may have to add something new to achieve your desired experience.

Saturday, July 4, 2015

Goals For Your Game Design

Why we need to know what we want

Many disciplines have specific goals in their mind when they approach a new project. An architect would never make a plan for a new building without knowing its purpose. But there are also other criteria that play a part in the design of the building. The same goes for games. This article discusses why we need these goals and elucidates the different kinds of goals that game designers should formulate for their design.

The client's goal: The project


Your game will have a specific goal. Most of the time games are made for profit. They should cost less money than the they gross. But there can be other objectives. Some games are less market-oriented, they want  to educate or they serve as a means of individual expression. Other games want to make profit and add value to an existing brand via high quality. There can be many reasons for a game but it is important to think of the game as a project that has to meet the specific goals of the company you are working for. All your other sub-goals should follow the purpose to accomplish this goal. That’s what your team gets paid for. Almost every game project has restrictions on how to achieve this goal. Most of the time there will be deadlines for when a game should be launched or a budget that defines how much it can cost. These restrictions are more important to your management than they are to you as a game designer but they will play an important role in your day to day work routine. But as we can’t control these, we won’t go into detail on them.

The goals that define the frame of your game


As I already mentioned, goals are all about purpose. At the end of the day your players will have an interactive experience. You should take enough time to define the experience that you’re trying to create and share it with your team. There are different categories of goals that are so essential that you should formulate them no matter what game you are trying to create.


Playtime-budget ratio


I already said that your project will have some restrictions. Most of the time these restrictions will be money and development time. So you have to make a decision about your playtime-budget ratio. What will be the desired playtime of your game? For how long should your players be able to play your game based on the systems and content you provide? How well does your content scale to fit the desired play time? Story-driven games that feature unique scenarios with a strong narrative-driven experience tend to be very expensive when it comes to creating play time. So when you want to have a long-lasting experience that is story-driven and keeps players engaged for years you have to keep in mind that it will be very expensive to produce this content. The games from “Tell Tale Games” are a good example. Even though these games are very successful and have a huge audience they are also weak in their playtime-budget ratio. That doesn’t mean that they are bad games. They give their players what they want: an emotional story-driven interactive experience. But if their goal was to create a long lasting mechanical-driven experience (which it isn’t) you could say that they have failed. Other games have a more mechanical approach where the system that is provided by the game creates enough variation and possible gameplay scenarios that emerge from it that the game stays fresh over and over again so it can be played and enjoyed for years. Counter Strike is a perfect example of a game that has a strong budget-playtime ratio. Its system is so strong and so many unique scenarios can emerge from its mechanics that players can enjoy it for thousands of hours. Of course you can’t compare these games as both have different goals, but just as they did you should formulate your playtime-budget ratio goal for your own game, too.

Business model

What kind of business model is your game going to have? Are you going to be free to play or pay to play? This can hugely impact your decision on how to create the playtime of your game. Free to play games are often very system-driven so it is easier to produce content that is scaleable for a long playtime and doesn’t cost much money. What goals do you have for your business model? Do you want to provide a free to play experience that does not sell power or will power-selling be a motivation driver for the micro-transactions in your game? Think about these aspects and formulate goals that define how you want to make profit with your game.


Gameplay innovation


How innovate will your game be when it comes to gameplay? Again this is nothing you should be hoping for to achieve by accident. You should formulate the different goals that will be innovative in your game and make it stand out compared to other games. You better do some research before you formulate your goals so you can increase your chance that your innovation will be as innovative and useful as needed. A new game needs something new. Otherwise customers can’t figure out why they should buy or play your game instead of the other that is already there, or even worse, already played by them. You can formulate some kind of ratio that describes how innovative your game will be. I love Blizzards approach on dealing with this. I think they always go for some kind of 60/40 - 70/30 ratio when it comes to innovation. In the early years they were very innovative but the in past decade they tend to go for a good and in my opinion very healthy innovation ratio. I’m sure that they formulate their innovation goals for a specific game and try to execute it as good and as deep as possible. That’s the reason why Hearthstone can be played even by players that are new to the CCG genre. They wanted to make a CCG that can be played by a lot of players and they formulated this goal and tried to achieve it. Every card on its own is very easy to understand. The combination of the different cards makes the game deep and complex. But Blizzard made sure that almost every player no matter how new he is to the genre is able to understand the effect of the different cards. And as I already mentioned, this is nothing that happens by accident. Formulate these kinds of goals and try to solve the problems that emerge when you’re trying to achieve them. Communicate them to your team and proof if your game design serves these goals. This way you have a good chance that your game will feature some kind of innovation that provides something new and valuable to the market that pulls players into your game.

Technical innovation


You should formulate if your game will feature a technical innovation. These kinds of innovation can generate a strong value and they will definitely cost you time and money. But these technical innovations do not emerge randomly. They should be part of your formulated goals and you will need good developers to make this innovation happen. Plan how you will achieve your technical innovation and plan enough time to solve all the problems that will rise when you strive for the technical USP in your game. I dare you, I even double dare you to go into production without having a workable prototype that proves that you can achieve your technical goals. Realising in production that you still have to figure out important things on how to solve specific technical problems will cost much more than it would in your concept phase where your team is still small and agile. If you are able to make a breakthrough in a specific technical area it can bring you a lot of new players but as I already said don’t wait for it to become true by accident. Formulate and execute the needed steps to achieve these goals.

Quality

What are the quality goals of your game and how do you make sure that you know when you reached these goals? Do you work with KPI’s to measure the quality or do you strive for a specific rating on metacritic or steam? How will your realize these goals? Try to formulate the goals of your game in quality and think about how to achieve them. If you don’t have an eye on the quality of your game, you run in danger of having no quality criteria at all. Make playtests, do a soft launch of your game, have peer review on regular basis and have a playable version as soon as possible. All these things can help to ensure that you will have the desired quality of your game.



Target Group

Your game will have a target group. Even if you don’t formulate this group there will be a user segment that will be the more interested in your game than any other group. But it is hard to know how big this group will be and if your game satisfies this group as good as possible when you have no idea for who you’re building this game. One of your goals should be that you can fulfill the desires of the players in your target group. So you should better know for who you’re building this game. This will help you even more when it comes to playtests. What kind of people do you invite to your playtests, when you have no idea how your target group looks like?

The high level goals: The experience


In game design you have 2 layers; the systems in your game and their presentation. These two layers create the experience of your game. Some games have a lot of presentation others don’t. To achieve your desired experience you’ll have to define high level goals. These high level goals will be more concrete to the specific game that you’re going to build but still not too concrete when it comes to designing specific systems or features. Do you want an elegant game that is deep and easy to grasp? Do you want mechanics that give your game a pacing that other similar games lack? How should your players feel? How do you want your players to access the content in your game? What will be your core gameplay? What skills will your players need to be good in your game? Define the goals that are elementary to achieve the desired experience. Don’t fall into the trap of thinking that some things are obvious and everybody in your team knows and thinks the same about them. Define and communicate them. Control and communicate the goals that your strive for and the most important values of your game by defining their purpose in relationship to the desired experience. Share these goals with the team. Some studios call these things their “core pillars”. These are the pillars that your game experience will stand on. It is important to create them but it is even more important and difficult to keep them alive during development and make them happen.

Here is a list of presentation examples:

  • Our game should make the player feel like he is powerful pirate captain
  • Our game should look like a next gen title
  • Our game should tell an epic story
  • Our game should make the player feel like he is on an unstoppable rampage
  • Our game should make the player laugh

And here is a list of mechanic examples:

  • Our game should be deep
  • Our game should be interesting for years
  • Our game should have competitive team based multiplayer
  • Our game should have user generated content
  • Our game should be a-symmetrical

And here is a list of hybrids:

  • Our game should be fun from the very beginning
  • Our game should be playable for 6 year old children
  • Our game should be very accessible

Do not define too many core pillars and goals that are related to them. Otherwise you can have conflicts and you run in danger that you can’t achieve any of  these goals, so your game becomes a patchwork of ideas and you fail to achieve the goals that are the most important for your desired experience. A well defined and concentrated concept that strives for an unique and raw experience  is a lot better than a fuzzy concept full of loose ideas that isn’t able to shine in one of its many desires.

The mid level goals: Your meta topics

Your game will have topics that will define the gameplay of your game. Shooting, movement, stealth, progression, building or what ever defines the most important actions for your players. It is important that you choose topics that serve your high level goals. For each topic you have to define goals. What are your intentions for each topic? Should your movement be very realistic? Should your shooting gameplay have a very high skill ceiling? Think about the skills your player should need to be good in the different gameplay topics of your game. Should you have some kind of gameplay progression in every topic? Define them again. Try to make them as clear as possible. You do not have to solve this goals in the very beginning, you just have to remember them when you start working on the different subjects. Think about it like a frame that defines the space where you can look for solutions. You can have 1 - 8 goals for each topic and they should be all compatible with each other and your already defined high level goals. Let’s make it clearer with an example.

Think about a shooting system in a tactical first person shooter. Your goals for your shooting system could look like this:

  • Shooting has tactical decision making
  • Shooting is the fall back mechanic that is the most important to win the game
  • Shooting should feel as rewarding as possible
  • Players should be more efficient in shooting when they play as a team
  • The choice of ammunition should be very important
  • Every weapon should have a secondary mode

Maybe you will change your goals during the prototyping phase and that’s totally cool. But without a clear vision for what you’re aiming for it is very hard to create knowledge from your prototypes. How can you rate a feature when you doesn’t know it’s purpose? These goals can help. When you have the feeling that a goal isn’t worth following anymore do not hesitate and replace it with another goal or just cut it completely. But you should at least have one idea for what you’re aiming when you start working for a gameplay system.

But what if you have no idea for what you should aim? That’s cool too. Just find it out. Think about your defined high level goals, they should be able to help finding the topics and goals for your gameplay. If they don’t you may have to rethink your high level goals, as they are not clear enough to provide direction for your mid level goals. Discuss the problem in a group and start a brainstorming. Work on finding your first goals and from there you can come closer to the goals that are worth developing for.

The low level goals: Your features

After you have formulated the goals for your different topics you will have to develop the needed features so your systems and therefor your gameplay can come to life and creates your desired experiences. The different needs for the different features can vary a lot so I won’t give specific information on how to develop the different features. Make sure that everyone who will be working on a specific feature knows its context in the desired experience and topics of the game. Different developers have different skills, give them the possibilities to make use of these skills as efficient as possible by giving clear goals and enough information about the things you’re trying to achieve with the different features. Each animation, texture, mechanic, sound, particle effect, or anything you can think of that will be part of your game should add value to the feature and its purpose. You need clear goals to discuss the different solutions and by defining them you can proof your different results and their capability to serve their desired purpose.

Last words

I know that this way of development sounds a little like over planning everything. But don’t get me wrong, everything I described is something that you should make before your production and the different formulated goals do not have to be as detailed and concrete as you may think. They only have to be concrete enough so that you can start working with an idea of what you’re trying to achieve. Game design is a very fluid and an iterative process, especially in the beginning of development, so your goals may change over the course while you’re exploring the possibilities of your design and that is totally fine and healthy. Working without any intention is very riskful due to the lack of direction. The lower and more specific your goals are the more likely it will be that they will change in some kind of way during the iteration and that is as I already mentioned nothing bad. The high level goals should be well considered and more stable because they are not too concrete so there is still a lot of design space to explore while staying in line with the defined goals.

Summary

In my opinion game design is all about goals. Without goals you can never know what you want to design and therefor you have no possibility to evaluate your results. Designing is coming up with solutions, a problem doesn’t need a solution but a solution needs a problem. Your game design should function as a solution so it needs a problems that it can fix. Formulate your goals so you can see the problems that you have to overcome. This way you can evaluate your solutions and your design can make healthy progress.