We love to talk about design theory. There are many design talks about system design, UX, narrative, or new monetization methods. But we often missed the path from design to implementation when you as a designer have to interact with other people in order to implement your ideas.

It all started with a question: “Why some games are better?” I mean, systemically better.

It’s only two examples, but you can see the trend, right?

But what is so special about them? They all have different genres, platforms, different audience and market. There’s one similarity between them: the quality of experience. In other words, these games are good because of their game design!

What is the key to this quality? Ideas, maybe? What do we have here…Indy-style adventure, a zombie movie, generic fantasy, generic sci-fi…I don’t see radically new ideas here, to be honest.

So, perhaps, they have some very special talented people who create all this great design? Good point. But the game industry is full of great talents with the highest quality of their work on the individual level. Besides, if we see at people who left, for example, Blizzard, usually, they do not create new Warcraft or Diablo right away.

Or, maybe, it’s some kind of a special marketing? But we have a lot of financially successful companies who don’t have games with so high quality.

If we dig a little bit deeper and study Blizzard and Naughty Dog post-mortems, we might notice that these two companies have a lot of surprising similarities in their approaches to production culture and game design. Perhaps, this is our secret? Is production culture the key?

And that’s where is my research started. My next question was: “What production culture leads to a successful creative product?” Actually, I was not the first who asked such question. Game design, by its nature and process, is very similar to the process of innovation adoption. And innovation methods is a well-studied topic in other industries.

I’ve studied a lot of things about creativity and innovation and then stopped on two sources of inspiration, two books, to be more exact.

My first source was a book called “Collective Genius.”

It’s a big research about production culture of successful innovative companies, like Pixar, Google, or IBM, and why are they systemically successful at innovation. And this research says that successful innovation is always about people and how they interact with each other. It’s not just about talents, but about talents in proper context.

You can find shorter version of the book in Linda Hill’s TED talk.

Here are these principles:

• Creative Abrasion – ability to create a market of ideas through discussion, using diversity and conflict.
• Creative Agility – ability to test and refine ideas through the discovery-driven learning process, using a mix of scientific method and artistic process.
• Creative Resolution – ability to make decisions in a way that can combine different ideas and approaches to produce a new solution, an integrated decision.

Looks familiar, don’t you think? You can see an application of these principles in many post-mortems of successful creative products. If you ever had an experience of successful implementation of some creative idea working in the team, you used such principles, at least, informally (in many cases, informally).

Another important thing when we talk about creative ideas is knowing how to overcome constraints on the way. My second source of inspiration was a book called “Creative People Must Be Stopped” (and related Coursera course “Leading Strategic Innovations In Organizations”).

It is a book about innovation’s way to success, but I found there a lot of similarities with my game design work when you often have a feeling that all the world works to stop you from the implementation of your ideas. The book shows the most common of such constraints and shows how to overcome them.

Which led me to my next question: “Can we systematize the proper principles and use them for game design?” Yes, our design and games might be new, but all “human factors” are very similar from project to project. Can we learn how they work and then learn how we can overcome them?

For almost 12 years in the game industry I had a lot of different experience, sometimes, successful, sometimes, not. After my research and armed with the new knowledge, I started to analyze all my previous game design and production experience. And came to an interesting conclusion: when I did things right, the process was very similar to the content of these two books. So, I’ve gathered the proper principles from my experience, identify the most common constraints (or obstacles) for good game design and identify the ways of overcoming these obstacles.

That’s how my Game Design Framework was born. In many senses, this is systematization of all my practical game design experience. My game design mindset, if you want.

Framework contains three stages:

• DESIGN – design principles and personal constraints of the designer
• COMMUNICATION – communication principles and teamwork constraints
• IMPLEMENTATION – design implementation and validation principles, technical and process constraints

DESIGN

Our first stage is the creation of the design. And I’d like to start here, perhaps, from the most important thing in any design process and all my framework.

Everything seems right in the picture? We’ve generated our idea, made GDD, went to production and reached GM. But very often, players are not happy. Something missed here, in this scheme, one very important component.

This component is the player experience.

In IT and the game industry, we love to think using fancy models. Every specialization has its own in the form of pretty documents, perfectly optimized code or an extremely polished content. But very often, these cool models are not assembled into a good game. It doesn’t matter how good are your documents, code, or content; this is still not your final product. The game, as an experience, born at the moment when the player starts to interact.

This is what we really sell. Not software, not disk or box – interaction. This is the primary goal of all this framework – how to pass all of the steps on the way to good game design and build high-quality interactive experience. Now, as we have formulated our goal, we can start our way to good game design.

Let’s assume that we have some idea of the great player experience. How to turn it into design? First, we need to know what kinds of design exist. There are many classifications and approaches, but from the organizational point of view, I would divide the game design into two main types: Macro Design and Micro Design (I’ve used Naughty Dog terminology that was presented in 2002 by Mark Cerny in his THE METHOD).

Each type of design has its goal and abstraction level.

Any feature starts from Macro Design, the high-level vision that describes the player experience on the proper abstraction level. Macro Design should be created before the implementation, and has very few changes during the implementation. The format can be different: Creative Brief, One-Pager, Table with the list of your levels and gameplays, etc.

Macro Design is your answer to question WHAT? What game/feature you’re doing and what is your final goal.

The second type of design is Micro Design, a detailed description of the features that takes in account all technical restrictions and edge cases.

Micro Design is your answer to question HOW? How is your feature should work? What are restrictions?

Usually, Micro Design is creating during the implementation, and might have many iterative changes during feature creation. How it usually happens: you made a document, made the first iteration of the feature, saw that it didn’t work as intended, updated the document, made a second iteration of the feature, and so on.

If we look at the relationship between these two design types, we can easily notice, that the biggest part of the design is Micro Design. The most of the production time, game designer do not “generate ideas”, but answer to the team’s questions such as “How it should work?”, and do it during production, not before (this is, by the way, one of the reasons, why it’s so hard to do game design remotely).

Game Design is about execution! It’s not what you came up with, this is what you have done in the end. And, by its nature, game design is a live and iterative process (which makes it very similar to innovation adoption process).

Let’s look at our two design types in details and what obstacles might be on our way in each case.

Macro Design

What is important about Macro Design that it is, actually, very time-consuming and has an extremely high cost of the mistake. I would put it this way: it is 20% of Design where you make 80% of the biggest mistakes.

It’s very common, and I see it again and again when teams try to “save time” on Macro Design stage. They want to start production right away, without “this useless bureaucracy”, or give Macro Design to some junior designer: “let this junior has its creativity, we have serious stuff to do”. As a result, Macro Design is unpolished, has wrong abstraction level (too abstract or too detailed), and misinterpreted by different team members. The team has no clear vision of the final goal which leads to grave problems with the game scope.

In general, the whole point of investing a lot of efforts in Macro Design is reducing of risks. One of the principles of successful innovation, according to this great lecture of Amy Jo Kim is “Ask important questions in advance”, and that’s why we need the high quality of Macro Design. The key point that you need to achieve is clarity. Do not stop Macro Design stage until it’s crystal clear what is your final goal.

There are three ways that can help you to achieve good Macro Design:

Involvement of the best of your team

Again, “Ask important questions in advance”. You will need all you knowledge and expertise, from the creative, technical and content side, and you need people who know what questions should be asked.

Proper abstraction level

Make sure that description of Macro Design communicates your ideas to the team in a consistent way without a lot of misinterpretations. If you do not have more or less the same understanding of Macro Design inside the team, it might mean that it’s too abstract, and do not communicate an idea clearly. If you have a lot questions regarding implementation of some technical details, it might mean that your Macro Design is too detailed, and the team can stick on discussing of minor details, instead of forming a high-level vision.

How to develop clarity? There is one way that once helped me. Use “Elevator Pitch” technique:

• Write your idea in four short sentences (or less). Imagine that you have ~30 seconds to tell it.
• From these four sentences, the essence of your idea should be clearly understandable.
• If you cannot write it clear enough in four short sentences or less – most likely, your idea is bad, re-write it.

Also, it’s very useful to do visualization of Macro Design (mockups, sketches, storyboards or even animation), it’s more expensive and time-consuming but can help you to achieve clarity easier. Text can be very deceiving, pictures have a much smaller chance to be misinterpreted.

Prototypes

It might be not enough to make a good document. You build an interactive experience, and words and pictures are not interactive. To achieve a goal of reducing risks, you may need a prototype. And be ready that there is a very high chance that your idea will fail during prototyping, even if it looks great on paper.

Another frequent question that people ask me is “When to stop Macro Design? How do we know that it’s ready?” Honest answer: it depends. Sometimes, managers decide it, sometimes, the team. On each project, you may have different restrictions and deadlines.

But there is one common method: three iterations principles (people from advertising industry often use it). Usually, if you made three iterations, and your idea is still not good enough, it might mean that it was not good from the very beginning. That is another important function of prototypes: they allow you to cut bad ideas on the early stage before you invested a lot of efforts in the implementation of the feature. The prototype is a part of Creative Agility principle, ability to refine and evaluate different ideas.

Micro Design

Clarity and support of visuals are also important for Micro Design. But there’s is another point: Micro Design is your description of how it works, not how it might be, so it must be as specific as possible, and leave no room for misinterpretation. You need to take in account all the details and edge cases, and must be ready that it will be quite hard and time-consuming to gather all the necessary information and then approve it.

As in the case with Macro Design, frequently asking question here “When can we stop Micro Design and start production already?” I would put it this way: you must be 80% sure how you feature works before giving your Micro Design to the team. After that, you must support and update your Micro Design, and change it accordingly to the team’s requests, if your team needs any additional details.

Timing

Micro Design is iterative and constantly changing, so timing is very important. One of the most common problems with Micro Design is that it’s not ready when the team needs it, which leads to design bottleneck.

Because of iterative nature of Micro Design, there’s no any sense to write detailed and comprehensive documents in advance (in that case, there’s high chance that you’ll have to re-write and re-approve them later).

Designer has to be just far enough ahead of the team:

• It allows the designer to foresee more potential edge cases and risks while both designer and the team still remember all the written and unwritten details of the feature.
• It leads to much higher quality of the feedback. You will be asking people about their current tasks that they’re going to implement now, not about hypothetical future. As a result, you’ll have much more specific feedback.
• It saves time on document writing. Creating of good documents is very time-consuming, and when you’re synchronized with the team and have proper feedback, you’ll have fewer documents iterations.

 

Design constraint: Feature Creep

One of the main and common design constraint and the main source of scope problems is feature creep, when your project has more features than you need and has them more complex than you need. There are two main causes of feature creep, both are related with human factors.

The first cause, is when the team can’t agree among themselves. As a result, there’s no clear vision of the feature, it becomes more complicated, and its design is trying “to take in account all the opinions”, with bad prioritization of these opinions. Which leads to ‘design by committee’ effect.

The second cause is when the team just…like some features and they become more equal than others. Very often, it combines with incorrect estimates: usually, for “cool” features ETA is 1,5-2 times shorter; for “boring” features ETA is 2-3 times longer.

Feature creep may increase the complexity of your project exponentially and ruin your scope.

So, what to do with feature creep? The main principle here is “Less is more”: it’s better to make fewer features but with higher quality and do not afraid to cut bad features. The design is good when you have nothing to cut. But we still have an important question left: how to cut? How to define what features you need? There are two main factors: feature value and feature priority.

Feature value

The first criteria are Return Of Investments of your feature.

Features with High Return have higher priority. If you have time left – you can spend it on polishing features.

Second criteria are risks of your feature.

Low-risk features have higher priority and, sometimes, you may have time left for experiments.

These two criteria can be combined into feature value table:

Feature priorities

By importance, features can be divided into Core, Supporting, and Exotic:

• Core Gameplay Features – those which create the main player experience, the player interacts with core features the most of the gameplay time
• Supporting Features – those which support the core features
• Exotic Features – those which add variety to the game

Efforts for polishing features redistribute accordingly to their priorities. So, even if you have a feature with potentially high value, but this feature is not your Core, perhaps, you should not spend a lot of efforts on it.

You can listen to Patrick Plourde, if you want more details.

Design constraint: Unconscious incompetence

Our next obstacle on the way to good game design is unconscious incompetence. It’s quite common among designers and leads to several problems:

• Wrong risks assessment – especially, if we talk about junior designers when they can’t predict potential consequences of their creativity.
• Outdated knowledge – very common among the designer who don’t know English…or just not curious enough.
• Previous experience bias – this is, on the contrary, common among senior designers, when they start to work on a new genre or platform and trying to use their standard solutions from previous experience.

What to do with unconscious incompetence? The solution here is a team feedback. Play the “Ask the Designer!” game: give feedback on the design as early as possible, the more feedback, the better. Demand clarity from the designer until you get it!

Design constraint: Cloning

Let’s admit, we all love to clone. It often looks like less risky and proven way of design and cloned features might be much easier to “sell” to the team and stakeholders.

But there are pitfalls:

• In reality, there are a lot of factors that have an impact on final design decision, and you might just not know all the competitors restrictions and conditions. As a result, cloned feature may not work for your product.
• There might be a temptation to do ‘lazy design’ and write something like “as in game X” or “in a standard way,” without detailed description. You risks, in that case, might be almost lethal for the project, you just don’t realize it yet.

Cloning is not necessarily bad. The fewer obstacles on the player’s way, the better, and standard solutions are great for that, especially, if we talk about 3C’s or UI. To clone the feature properly, you need to de-construct it, understand how it works in circumstances of your competitor, and then construct it anew, according to your conditions and constraints. That’s where fundamental game design knowledge will be very helpful for you.

Returning to my previous points, it’s important to remember that it’s all about the player experience. It doesn’t matter whether your feature is innovative or not, what matters is how it works for building the player experience.

 

COMMUNICATION

Let’s move on to communication. The first and the foremost principle here is “errare humanum est” (humans tend to make mistakes). People are imperfect, biased and usually bad listeners. The worst: you have no other people, and you can’t change the human nature. Also (you will not believe!), you as a designer is also imperfect. You cannot know everything and can’t plan in advance the full and detailed vision of the game.

Shared Design

So, what to do when everyone is so imperfect? Share design with your team! You team consists of smart people with different experiences, and if you give them an opportunity to participate, it can significantly improve the quality of the design. The thing is, people on the implementation level know much more details that might be non-obvious for the designer. They can complement your vision and help you to reach the much higher quality of design decisions. The big advantage of Shared Design is that your team will become personally invested, it’s their design now, not just someone’s ideas. This is the key to Creative Abrasion principle, the internal market of ideas. Give freedom to artisans!

Cross-disciplinary collaboration

Another big part of Shared Design is cross-disciplinary collaboration. Any design decision consists of the different “parts of the puzzle”. Gather people from different disciplines: technical, artistic, creative – and offer them to participate in a finding of a solution. People who will be implementing your feature know each ‘part of the puzzle’ and can significantly increase the quality of the design. The final result might surprise you and has much higher quality than you could ever imagine. Such collaboration sometimes looks like a pure magic (and they decided everything by ourselves!).

Conflicts

The key components of Creative Abrasion are diversity and conflict. Shared Design and Cross-disciplinary collaboration give you diversity, but they’re also impossible without conflicts. I don’t want to go deeply in conflictology, just would like to stop on the most important things. There are three main types of conflicts on the project: Task, Process, and Personal.

For creative product (such as a game), task conflicts of small and medium size can be considered as a good thing. Especially, if you gathered together people from different disciplines, and they started actively arguing about ways of task completion. A lot of small and medium task conflicts is a good sign that the team is alive and care about the project.

Process conflicts can be good at an early stage. This is your opportunity to improve some of your approaches in general. But if you a lot of discussions about processes on the later stage, it might lead to serious communication problems and even personal conflicts. And, by the way, never get personal!

Integrated Decisions

The ultimate designer’s goal on the communication stage is finding of Integrated Decisions that are combined different ideas and approaches of the team in the best possible solution. Integrated Decisions is a part of Creative Resolution principle. Your team also has creative potential, don’t be greedy, use it!

Communication constraint: Documents

So, documents. They are:

• Become outdated fast
• Hard to maintain in up-to-date state
• People don’t read them (and don’t want to)

Which can be a source of bottlenecks of the project. What to do with the documents? Make them digestible. Usually, people don’t read more than 1 page at a time. So, don’t make documents longer than 1 page! Pictures below illustrate how this problem is solved in other industries.

Can’t make document 1 page long or need to describe something really big? Divide it into ‘digestible’ blocks. Usually, people don’t need all your document, only part of it to get an answer to an important current question. All the clarity principles that were mentioned before work here: clear, polished phrases, supported by visuals. In my practice, one of the best formats for complex Micro Design production documents is Excel table + Mockups.

But you know what? I have bad news for you: it doesn’t work anyway. I’ve always considered my design documents as the main communication tools and really paid attention to their quality (I can even proudly say that I had feedback on some of my docs, such as “this is one of the best design documents I’ve ever read”). But people are imperfect (and you, as a designer is also imperfect).

Which means:

• You’ll never have 100% correct documents (you will forget something, or there will be a new unknown technical restriction).
• Even the best documents people don’t read, and don’t want to (you can get feedback “great document!”…and then the team just don’t read it!).
• Besides, there are many other communication channels (mail, messengers, direct communication, etc.) that the team uses for small decision making.

As a result, you’ll always be criticized for ‘outdated docs’ (in any case, don’t have any illusions).

So, what’s the solution here? Well, we need to admit the problem first. We love to use ‘Agile’, ‘SCRUM’, ‘Kanban’ and other ‘flexible’ methodologies, but I still continue to face an opinion that we may have ‘final’ design or that we should even ‘freeze’ the design at the certain point. The solution appeared on one of the projects: we can treat documents in a similar way as code, like something live that may have bugs. If you have inconsistency between the document and real behavior, it’s a bug that can be created in bugtracker and fixed. Now, you even have KPI that measures the quality of your documents and how responsibly you update them.

As I said before, design is what you’ve done, what player experience you built, it’s not your documents. Documents is just a tool that helps you to communicate the design. And this tool is not made of marble, it should be flexible and adaptable to changes on the project. Which leads us to another magical designer’s tool, aside from the documents, that can help you to communicate the design. You need to talk directly.

Work both ways:

• The programmer didn’t understand you document? Explain it again. Re-write the document, and then ask the programmer again.
• Do not understand how the feature should work? Ask the designer. Then ask again.

Game design is a live process that is based on constant iterations and feedback gathering. Feedback from direct communication is much faster than any other. In reality, many design decisions born as a result of the team discussion on the working place. It is best if your working environment support direct communication and you sit nearby the key people that you need. Fast feedback is the key to Creative Agility, ideas evaluation process.

And the last thing about direct communication will be useful if you work remotely. There is so-called 3rd clarification rule: if the question not answered in three e-mails, you must call. Otherwise, you mail thread might be almost infinite. For one hour of direct talk, you can solve more problems, than for two weeks long mail thread. Get direct feedback if mail is not working.

Communication constraint: Expert Arrogance

Sometimes, design can be blocked by an ‘expert opinion’. Quite often, you as a designer can find yourself in a situation when you ask the programmer to implement quite an obvious feature and get an answer “this is impossible” without any intelligible reason.

It might be fear of responsibility. Fairly often, this feature might be something where the programmer does not have a good expertise. Or it can be just laziness. Especially, if the feature is something boring and time-consuming. Yes, people are imperfect. And sometimes imperfect in a very obvious way. In some cases, it might be personal ( the feature is boring, and the programmer doesn’t like you personally). Or even political (might happen if you work with a remote contractor, and the contractor wants to work less and earn more; I was in a situation once when it killed the project). As a result, some of your features can be unreasonably blocked.

What to do in this case? Remember that almost always, it’s not a rocket science and demand clarity from the expert. In the most cases, the expert is afraid of potential risk (personal or the project) and overvalues the complexity of the feature. Answer on such things is to gather more information about the problem. It can decrease the expert’s lack of confidence, or help you to overcome “laziness barrier” (you need to show the expert that problem is not so complex). Be persistent, ask questions and separate facts from the ‘expert opinion.’ It’s also useful to shift the focus on what you want, not how. If there’s a real risk, the expert can offer you another way to achieve the desired result.

Communication constraint: ‘Not invented here’

People love to create something new. Designers want to do their “dream game”, programmers do not like someone else’s code, artists want to draw what they like, not what they have to. Which leads to conflict with business goals.

It’s a big topic by itself, but I’d like to stop on one particular case that I see quite often. If you have a demanding publisher or customer who has very clear requirements that may not leave any room for ‘creativity’, the team with ‘not invented here’ syndrome may perceive feedback from such customer as an attack on ownership. Most likely, you heard something like that before: “we do only what our customer told us to do, and don’t do anything ourselves.”

To be honest, it’s a quite hard problem to overcome (especially, if you have ‘not invented here’ on the level of lead programmers) but sometimes having the player as a common ground might help. Shift focus on the player, and evaluate all the desires of ‘wheel invention’ in terms of their value for the player (clarity of the design vision and feature value evaluation also might help). It may well be that you can use more standard solution and switch the team’s creativity to something more appropriate.

Most likely, it won’t kill ‘not invented here’ syndrome (people are imperfect and won’t change) but can help you to convince the team that with standard solutions, they can create more value for the player for the same amount of time.

Communication constraint: Stakeholders feedback

I think anyone remember this feeling when you just received stakeholders feedback where:

• Stakeholders don’t understand your project
• Stakeholders contradict each other
• Force you to make more than was originally negotiated

All this can ruin your scope, and you will be blamed.

The important thing here that you were reviewed by imperfect people. Stakeholders, as imperfect people, have limited vision and judge based on this vision, not necessarily because they bad.

The solution here is to talk with stakeholders and explain the logic behind your decisions. Stakeholders take risks when they approve your work, and when they don’t understand something, they often tend to select the safest option possible. Additional information may reduce their feeling of ‘riskiness’.

Also, you can use the limited vision of stakeholders! From my practice, a good way is to offer stakeholders several solutions that are acceptable for you, but with some room for participation for stakeholders (you can even give them the cue, what solution you consider the most suitable). In many cases, you will get a solution that is acceptable for you, and stakeholders will be happy that their expert advice actually helped.

And the last thing about stakeholders: there are Hidden Stakeholders, people who can’t help you to approve your design, but can say you NO. There might be some people on the project who are not officially stakeholders, but can block your design for some reasons (processes, technical, etc.). Try to find them on early stage and get their feedback to avoid unpleasant surprises.

Implementation

So, here’s our final challenge. But before we continue, I’d like you to know the truth about players. It doesn’t matter how many problems you have, all your problems with scope, resources, deadlines, whatever else just don’t matter for the player. The only thing that is valuable for players is their personal experience.

“Creature who can fill the Louvre with all the shits he doesn’t give (c)”

The player is like honey badger – doesn’t give a shit. It might look unfair with respect to your efforts, but that’s how you will be evaluated. And you goal at the implementation stage is not just to implement the feature, but build and polish the player experience.

Iterate, playtest, feedback

Game Design is very similar to innovation adoption process, and impossible without many iterations. Almost always, implementation of the design is a discovery-driven learning process. Be ready that your design will fail 1st time (and 2nd, and 3rd), learn from your mistakes, it’s a natural process.

Your main discovery-driven learning tool is playtests. You create an interactive experience, and playtest is the only opportunity to see your real game. You can create a lot of fancy documents and have a great tech, but in game design, you can believe only in things you can interact with. Playtests is a big part of the Creative Agility principle, your another tool of ideas evaluation.

Playtests feedback

Of course, there are ‘big’ organized playtests with using of social science methodologies and ‘official’ reports, but I’d like to talk about methods that can be helpful on the smaller scale.

A little bit about the feedback from playtesting: do not trust too much to what people say. Your playtesters are people (and people, as we already know, are imperfect), and might have very weird ideas how to improve your game. If you ask playtesters what would they improve, most likely, you’ll hear what they liked in the recent 2-3 games they played. Or, you can hear from them mostly polite and positive feedback, just because you entrusted them very important mission – to test the game, and people don’t want to be ungrateful.

You need to see what they really do in your game. You need to look for the player’s insight: see what interactions bring people fun and engagement and what interactions cause one or another emotional feedback. All playtesters’ feedback is a reflection of their interactive experience.

Another little secret: actually, you don’t need a lot of people (and ‘official’ playtests do not have a lot of people, by the way). A group of 8 testers will find 80% of problems (of course, more complex issues might require much more efforts to solve).

Fake it

Even after all the playtests, the design of your feature can fail on the implementation stage for many reasons (in many cases, not because it’s bad). You might realize that your design just can’t be implemented with a proper level of quality with your current technologies or deadlines. Remember, that you goal is the player experience, find another way to implement this feature, or just cut it.

And there’s one secret: Fake it. The player doesn’t see your back-end. In many cases, you just don’t need a sophisticated technology to create the experience for the player. Really, you don’t need a complex AI for things that can be done by the simple script, you don’t need an extremely detailed texture in the place where nobody will see it, you don’t need complex and “fair” math formulas that have a very insignificant impact on the experience, etc. If you can’t implement something, you can fake it!

Implementation constraint: Low flexibility

The main and the biggest constraint on the implementation stage is low flexibility. It’s when you need to wait for eternity to check some design changes (for example, spend 6 hours for compiling every time you moved a barrel and need to test the level). When tools are so horrible that they don’t even have Ctrl+Z function, and author of the editor says “you’ll manage somehow with your complex level design without Ctrl+Z and terrain layers, don’t you?” (real case from my experience). Or when you need to go through bureaucratic hell to approve every small change. All such things can stop design and polishing process.

Fast to test

Fast iterations is a key to good design. The perfect case is when a designer can do everything without programmers involved, and see the results right away. Add new data, run the editor, check the changes, iterate again until you get what you need. Game Design is a way of discovery-driven learning, and if you want good design, all you processes and tools should be focused on making iteration time as less as possible. The faster you can go to playable state, the more iteration you’ve done, the better is your design.

Final player experience appears on the polishing stage after you tested how the player interacts with your game. The quality of the interactive experience comes from polishing, and short iteration time will allow you to reach the polishing stage faster.

Game Design Framework

Let’s try to summarize all our knowledge:

1. It’s all about the player experience. The game, as an experience, born at the moment when the player starts to interact.
2. Aim for CLARITY. Know what design you do (Macro or Micro), choose proper abstraction level and do not start implementation until it’s crystal clear what is your final goal.
3. Game Design is about execution. It’s not what you came up with, this is what you have done in the end.
4. People are imperfect. They make mistakes, they’re biased and bad listeners, and you can’t change it. But you can learn how to overcome people’s imperfection.
5. Share design with your team. They know many important implementation details and will become personally invested.
6. Simplify documents and talk directly. Clear, polished phrases, supported by visuals. The faster the feedback, the better you can evaluate ideas.
7. The player doesn’t give a shit. Players only care about their personal experience and that’s how your work will be evaluated.
8. Believe only in things you can interact with. Iterate, playtest, gather feedback. See what people really do in your game.
9. Fast to test for the better design. The faster you can go to playable state, the more iteration you’ve done, the better is your design.
10. Game Design is about people. Almost all methods of game design execution are about the interaction between imperfect people who create imperfect processes and plans. You can’t change human nature, but you can learn how to overcome it and succeed.

 

Additional sources:

‘Collective Genius’, Linda Hill, Greg Brandeau

‘Creative People Must Be Stopped: 6 Ways We Kill Innovatios’, David Owens

(Coursera) Leading Strategic Innovations In Organizations

(D.I.C.E. 2002) Mark Cerny, THE METHOD

(TED) Linda Hill, ‘How to manage for collective creativity’

(GDC 2010) Designing Assassin’s Creed 2

(D.I.C.E. 2010) Naughty Dog Presentation

(GDC 2010) Among Friends – An Uncharted 2: Among Thieves post-mortem

(GDC 2012) The Last 10: Going From Good To Awesome

(GDC 2015) Hearthstone: How to Create an Immersive User Interface

(GDC 2014) Hearthstone: 10 Bits of Design Wisdom

(GDC 2013) Through the Grinder: Refining Diablo III’s Game Systems

(GDC 2010) Blizzard Design Philosophies