Instead of intro

Hello my name is Andrii Goncharuk, but you can call me Andy, I'm a game designer working in Ubisoft, and to be honest... I feel a little bit guilty right now...
I got a feedback about my articles from a person close to me that I don't share enough of actual advices on game design or management. Ouch...

---   *disclaimer*   ---
One of the main reasons why I don't share much of actual advices because, I don't want to project myself onto people and limiting their knowledge only to what I know. Usually I try to provide all resources and direction for people to develop their own skills by themselves. But for this one occasion I decided, ok I can make a list of advices.
---   *end of disclaimer*   ---

Alignment

Before we start we need to align on some terms. I’m not claiming that this terms are correct, it’s my personal view on things. Let’s take a look on who is a game designer or a designer in general and what is a good design. I need to say also that if you strongly disagree on my terms.Then I think, advices below, won't be any good for you.

Designer is an engineer in all ways, the only difference is the field of application of skills.

Here is qualities of engineers and you will get the point:

Engineers talk in blueprints not in vague broad descriptions.
When someone ask engineer to build a machine to fly he(she) is not saying it’s impossible.
Engineer will start asking questions like:

And after getting proper answers he(she) can give a plan or several plans how to handle this problem.

Same way designers should think, it’s not about: "OMG I have seen a cool idea let’s add this to our project!", it’s what problem should we solve, how and for what reasons, what resources we have etc.

And when I say problem to solve I mean all sort of problems in broad term, creating a cool looking memorable transformation animation for character is a problem to solve, but this problem should be outlined beforehand and not just be taken from granted.

I believe that if something was not outlined in list of problems, and after that was not solved by design, it’s a problem on step where you need to outline all problems that you need to solve, not implementation problem.

Good engineer same as good designer should be creative in a way of how can he manage and find solutions to given problems, not bring “cool” ideas that will create even more problems.

Good engineer/designer also need to be able to communicate his ideas properly, and handle all documentation. 

Ok now when we finished with designer part, it’s time to tackle next question, what is a good design and how distinguish good design from bad design?

Design that solve all outlined beforehand problems and not creating any critical new ones that cannot be solved - is a good design.

When I saying problems that needs to be solved I mean all range from design problems to marketing like: audience growth, convey particular philosophical idea, be aligned with narrative style and story and visual style, generate as most revenue as possible, get recognition, test certain mechanic, use only resources that team poses now, etc. When design being created it should take in account as many parameters as it could just like any other linear programming algorithm (Google “Linear programming” it’s not about programming code, good system design is exactly like Linear programming, to be precise simplex method).

There is a notion that good design should have some a r t i s t i c value, the more vague elements we add into design the more problems we will have afterwards. Good design is one that works, period.

Design that have space to be updated/modified to face new problems that will be found in future - example of perfect design.

There is no silver bullet and each design pattern or approach or known technique should be adjusted to given situation so there is no good designs by themselves. It should fit.

Usually when we talk about games we can outline next things that should be taken in account, design should: 

Ok, since we have sorted out basic things, now we can proceed to actual advices that I learned the hard way during my work in the industry.

Number 1
What to consider when you work on a new feature

First step: Focus on problems that this feature should solve and aim to deliver. Try to outline full list of problems that this feature should handle or solve, try it several times, adjust this list according to production terms if needed. Don’t forget that feature should not always solve all problems, it’s a question of balance. 

Second step: Check what additional benefits this feature could create, when you have several features pick one that create more benefits. Sometimes feature can create some additional problems that can be covered by other small features but generate a lot of benefit, this is a case when you need to carefully consider benefits and check rate of investments.

Third step: Make sure feature is interconnected with other features as well as with lore, narration, pacing, player progression, main idea, core pillars etc… There is no any good for game, from feature that make no sense and added as useless appendix (not saying that appendix are useless, it’s actually important for immune system especially in early years...).

Fourth step: Profit.

Number 2
Oh no! We need to cut things! How to handle that.

Don’t panic.
Cutting as important as adding stuff, it helps to keep everything trim and aligned, just like any evolutionary process it will help make product as whole stronger(usually).

But all this just broad vague terms, how to handle it actually?

My proposition: Points system and points of support of core pillars of the project. 

Give points to each element or feature, based on production time, fun factor, alignment to pillars and core, how feature is interconnected with other elements and how many other features will affect cutting this one.

First to cut features are those:

After cutting, don’t close the door and throw away keys from it, keep features in a form that some of the cutted elements can be brought back, because this is what usually happening all the time during production, features get cut but soon reanimated back all the time, just like zombies.

Number 3
Check for feedback, is all actions in your game have one or some of the features are dead?

Feedback is a most important element in each game project because of nature of games. Arguably one of the most vital elements of developing a good game. All actions, and it is important to remember that ALL actions should have some level of feedback in your game.
Visual or auditory reaction of the game to the player’s inputs. Each action that the player makes, should have a clear reaction. 

This may sound obvious but sometimes people skip some elements focusing only on “important” actions and forgetting about small things, but believe me on that, small things create all the difference. Having a good feedback for all inputs makes the experience much more better for player. The more ‘what do I do now’ moments you have, the more annoyance and frustration you’ll cause. 

When I talking about feedback it is not only input’s as control scheme or 3C, character, camera, controls. When we are talking for example about game with have narration we need to make sure that player will see results of his own actions during game. If in 1st level he saved random NPC, it’s better to have some feedback, giving some reward or making it important later during game. There must be no inputs without feedback, for every action, there is suppose to be an equal and opposite reaction, it’s true not only for physics.

Number 4
Is it ok to “borrow” ideas and mechanics from other projects and games?

Yes, it’s ok. Re-using existing patterns and mechanics, especially well developed ones are not only not a bad thing, but actually a good thing. Here is a list of some reasons:

Your implementation will be different, it should be if you want to create good design.
It saves production time.
While working on something existed, you can improve it and make it better, this is how mechanics grow in quality.
Taking something that already worked somewhere not granting that it will work perfectly in your case, thus forcing you to rebuild it accordingly.

If certain mechanic or system is not a main core feature of the game, it's better to reuse well developed existing one and focus on core features that make your game different and unique. You need always focus on what matter most.

Number 5
Sandbox games and open world games, what to chose, full freedom or hand-holding?

One of the problem that designers usually forget, especially when working on sandbox games is there is a real psychological problem of choice and being busy, one of the points is, the more choice you have the less you gonna pick one.

Even if you have a full freedom sandbox game, it’s up to you to keep player busy and entertained, full freedom and ability to do whatever they want must be an option but not a general approach.

Even mincraft before official release already had some tutorial and achievement based flow to guide player through the game, giving tasks and showing general mechanics.
Your goal should be to keep player busy all the time, make sure that he always have something to do and have no situation where he is not aware of what to do next. 

If you have many multiple goals simultaneously, it’s better to have them arranged in a 1,2,3 way:

Having 10 quest that similar in importance is usually have same value as having 0 guests at all because of the problem of making a decision.

You should hand player's hand as far is it needed, but always give him an option to ditch this hand and return back to it anytime.

Number 6
Is having an overpowered item/skill/system/feature in general, is a good or bad thing?

I personally don't think that being overpowered is a bad thing in general. It just need to be handled right, and balanced but not in same plane of power that it gives. What I mean that if you have a sword with over 9000 damage it should be balanced in a plane of accessibility, timing and other elements but not damage output.

One of the ways how overpowered feature or equipment can be justified is when it goes within next proposed pattern:

Another option is that it can be limited or given for a short period of time, there is always a place for overpowered features, there is no need to avoid them, they just need to be handled right.

Number 7
Right approach to narration and storytelling in a story based game.

One of the problem that I often stumble across in some games is that sometimes games are completely unplayable if you are not paying attention to text, narration or story overall. I know it can sound a little bit weird, why should I play game without being involved with story. But since games are a little bit different compared to other means of media, they must be handled correctly.

Story and narrative design should be done in a way that player will understand it without text and audio, or at least will be able to proceed further and complete game without paying attention to it. Story is a good and certainly important in some cases addition to a game, but if your game is more of a story than a game, maybe it’s better to write a book or make a movie?

Worst case scenario is that game must be playable, sound and without text, it can be limited for sure, and maybe some content won't be approachable but it must be playable. You will be surprised how it will drastically it will increase your player base.

Number 8
How to handle creative burnout.

If you have a creative burnout, you need to solve it asap, but in the meantime you also usually still need to deliver work.

If you ideas don't come to you with ease as before or you don't know where to start, just use seed and move from it.

What do I mean when I say use seed? 

Well let’s take an example, you need to come up with a level design for a abandoned factory level filled with traps and deadly zombies in a post apocalyptic world. Get your hands on any actual factory in the world, find a blueprints for them, and recreate with some artistic license in game engine. Convert existing production lines into deadly traps for zombies, etc.

Just pick something one and work on it as long as you could trying to make it valuable design, if you are lucky it will help you to build what you need straight ahead, if not atleast on your way you may stumble across something valuable and will be able to move from there, never stop, do something. You can go for simple and straightforward solutions and ready to use mechanics, just don’t stop working. Procrastination is the worse thing that can happen to you during burnout.

Number 9
It’s a good thing to have frequent cross disciplinary knowledge sharing sessions.

When you work in a big production team it is a good thing to share some ideas and knowledge across disciplines, there is a lot of what can be learned from other fields, programmers can pick up a lot of intersting ideas from art and design and vice versa.

But you need to manage this events really careful, first of all you need to make sure that topic is usually somewhat connected with current production and can be beneficial.

Make sure you invite right people to right events, if it is something about network code and security, inviting a junior concept artist maybe would be a bad idea, but inviting a multiplayer designer on the other hand is a really good one.

Try to make presentation clear and understandable were it possible to all people from different disciplines.

Keep it short, and don’t make it too frequent.

Number 10
Agile or waterfall, what is better overall?

I need to outline one important moment here, we are talking about games here, so this comparison and production flow is true for games, usually big or story based games.

Without any explanation or reasoning I will go directly for advice. Agile is a wonderful option for pre production and concept phase, when you need to iterate ideas fast, agile is a best option. But when production started and 80% of the concept and prototypes are approved, waterfall is more valuable choice due to nature of content production pipeline in games, if it necessary you still can keep agile on a background for fast prototyping new ideas and some features, before integrating them into general waterfall production pipeline.

Agile is great for iteration, but it’s not very predictable, when you have strict development schedules and deadlines, predictability is a much more better option.

Waterfall helps with dependencies, when you have so many elements that depends on each other, waterfall is a best option, due to dependencies of code from design, art from design, audio from design, narration from design and them from each other, it’s better to have something that can be planned and scheduled correctly. 

One of the downsides of this approach is it is hard to handle and require some sick managment skills, but it on a big scale within big production teams it’s totally viable.

In the end, it all depends on team and how it is already worked before and what they adjusted to. It’s always important to remember if you come to new place as manager, you are coming to already leaving breathing organism, dont kill, trying to rewire all production, try to adjust it slightly to make it work as it needed, it’s easy to destroy everything and start from scratch but usually very inefficient.

Number 11
Ok, you have new designers in your team, how to get them on board asap and how not to screw up.

Onboarding is in process, new people coming, how to handle that?

This is a general pattern but each situation is a little bit unique and must be addressed properly. 

Number 12
Unclear expectations and responsibilities.

Since we are still far away from mind reading machines for any new hired or moved coworker it’s hard to understand what are expectations and responsibilities that he has.

You need to work on assumption that all responsibilities and expectations that were not clearly communicated to hired worker, will be not fulfilled. Never, NEVER take something for granted, it’s always lead to confusion and miscommunications.

Never expect more than you ask. If you want more from person you need to ask person about it, waiting from person that he(she) will do something that you expect or think he is entitled to do is a wrong approach that will lead only to problems.

You need to clearly communicate all expectations and maybe even some above expectations if you have some, and oh god, don't ask person why he(she) didnt done something if you didn't asked him(she) to cover that subject. 

There is cases when people overdeliver or manage to do more work than expected, but you never should treat this as given, it can be a nice bonus but not an average. Don’t get used to it.

Creating a field of unclear expectations is a bad thing, if you make hints to your team that you expect from them overall more than they have in contract, and (in some fantastic world) 80% of team will do that, you will have really bad time planning your work and control schedules. 

Having consistent results is much better than have tons of early delivered work. Early done work can hurt production same as not making this work in time.

Also don’t communicate expectations and responsibilities to a team, all this needs to be delivered personally to each team member, because when we are talking about team we are always talking about diffused responsibility, that create a feeling in manager that he communicated expectations clearly but in reality everyone will think that it is responsibility of someone but not them.

Number 13
How solve disputes between designers, and  artists also applicable to programmers sometime.

How to handle dispute about feature with another designer?

Designer can disagree about feature only because of 2 reasons lack of information or personal preference.

If it is because lack of info I would suggest to advocate background and reasons of this feature and will try to listen to his counter arguments. It is important to leave behind all arguments from both sides that based on previous experience on other projects, because each case is unique and one thing that not changing is basic human behavior. 

If it personal preference there is 2 ways, if other option for this feature is working and solving problems same as other I don't care who designed this feature, if it works, it works. 

Second way, if other option provided by another designer is not solving given problems or dispute is blocking production I will suggest to evaluate this problem to a higher manager so he(she) will have last word, so production won't be blocked.

How to handle dispute with an artist?

If artist made an asset that contradict strict descriptions that mean that provided descriptions are vague or not convincing or presented badly, in general that meant that your job were done bad.

Other option is at if artist is not paying attention to documentation, or because of other reasons, but despite reasoning, you need to try communicate to artist needs and problems that needs to be solved with this piece of content. 

Explain needs of mechanics, find common ground where core mechanics will work as needed, design goes first, especially core design, if artist will disagree I will suggest to evaluate problem to a higher manager to have the last word.

Number 14
Why interpersonal skills and ability to work within team are more important than experience.

This advice will be hard to follow but, it’s better to find a team that you can work with or otherwise you will need to adjust yourself to be able to work within a given team. When you get onboard to new dev team try to understand what producers and creative director wants, research their needs and their tastes and don’t try to fight their vision it would be counter productive, try to help them to develop what they want and support their ideas. 

I’m not a big fan of linear organizational structure where there is a superior in each field, but from my previous experience I can say that in terms of effectiveness/time there is no better option for a serious game development studio, unless you are Valve and have almost infinite resources then flat structure could be an option.

I believe that creating a game is like a military campaign:

Planning – where the General Staff define objectives, time, scope and cost of the campaign
Executing – the coordination of forces and resources in logistic and combat operations
Controlling – the monitoring of the progress compared to its baseline plan
Concluding – acceptance or rejection of the outcomes by the directing command structure

Military campaign can be successful only with strict linear structure, where responsibility is always observable and everyone working for one goal, victory.

Number 15
Don’t believe anything, stop asking questions learn from sources, learn by yourself, don’t ask advices.

Don’t waste your time reading advices on internet, learn from the source, explore world around you. Learn at least basic physics, chemistry, biology, history, sociology, psychology, pop-culture, other games. 

You need to use your own free time to increase your knowledge base. To create compelling interesting experience you need to have as much knowledge on as you can find and not only about subject but beyond it, innovations are appear on where different science disciplines collide. 

When researching any materials, go straight for source, instead of wasting time reading distilled articles that people write about look for what they read and seen, look for references. To create their own vision they spend tons of time researching and reading materials, don’t expect that their vision based on that data will match your own. Study and research by yourself and you will be able to create your own vision that will be much closer to you.

So what's now?

In the end, it's always about personal expirience, most of the stuff above is common sense, but you will be surprised how often common sense is not present during production, especially when there is a huge team involved and all teammembers have their own needs and goals. Most of the advices repeat what you already can find roaming internet, but if you found a random advice on internet and it's keep appearing in many palces from different persons, maybe there is something behind that?

In future I will try to keep myself from articles like that, I don't belive that giving stric advices will make game design a better place and result in better games, actually quite opposite, if there will be a stric list of techniqies and methods, there will be less space for innovation.

Summary: