List 20 bad habits to avoid in game design

Author: Jorge Diaz

Everyone has bad habits. It can be said that bad habits are part of people's daily lives, and whether we like it or not, they all affect our daily work. In the end how to define bad habits?

Bad habits can refer to those regularly occurring subconscious and subconscious behavior. Game development can be said to be a repetitive cycle or process, but how do we define the bad habits of design? This problem is as difficult as defining a game designer.

We can say that game design is about designing game content and rules, while "content" includes sounds, levels, conversations, and so on. I'll list here 20 bad design habits I know that also apply to some of the creative areas outside the game.

Bad habits of game design (in no particular order):

1. Stubborn in a concept

We can see this issue in many ways. There is more than one reason for this problem. After all, it is always difficult to tell when a function has a greater effect or when we need to remove it. And here we are facing the challenge is that the passion of our own work will have a direct impact on the success of the design.

Tom Cadwell (Design Director, Riot Games) describes this as a "hard-to-break" trap. He believes that risk assessment can help developers make the most appropriate decisions. From the designer's personal point of view, they must be clear that no philosophy (good or bad) will directly determine the final product shape, and these ideas do not reflect their ability to create.

2. not clearly design range

If you can not explicitly design the scope of the beginning, will lead to many unnecessary production process troubles, and ultimately affect the game's formation. This will not only lead to time-consuming, error and other conditions, but also make the entire development process difficult because you do not establish a reference to measure.

If you plan on a standard design pattern in advance, your team members can iterate on a few smaller goals so that you can clearly define the scheduling you need for the previous period. We must measure the time and cost of any task based on a macro or micro level and apply it to all design tasks, not just as a work that is tailored to specific design requirements.

3 proposed unreliable design

For whatever reason, we always need to delete some of the design content during the production of the game. We must ensure that the design flexibility, can be adjusted without affecting the rest of the premise. And we need to invest more effort into identifying the risks and measurable options for the design.

Assuming you are designing a system that does not have more room to change or that directly affects project completion, you need to ensure that the system must be approved by all members of the team, giving it enough attention. And often, over-interdependence is a bad habit that many teams can easily overlook.

4. Lack of self-criticism or criticism

It's always easy to pick something that's helpful to the design, but it's hard to ensure that the design impresses the player. Self-criticism is like a double-edged sword, and sometimes it helps us reach consensus better, but sometimes it also leaves us in deep trouble with some issues.

Especially when time is limited, you need to be more careful about self-criticism because you may not want to waste more time designing and choosing to move on. But sometimes, if you are not fast.

On the other hand, we may also have some critics of the situation, especially in the early stages of development. We must be clear that excessive criticism will lead us to focus too much on something and ignore others. Try to accept any new ideas, especially for those with less risk. If your design meets your expectations, you can compare its earlier content with the more recent one.

Whether it is lack of criticism or criticism, if the content you are facing is too objectionable, you should be able to ask for help from others and listen to the opinions of other people, such as user testers.

5. Forget the design goal

The design goal is like a beacon that will guide us in making the right design decisions, but we often miss the beacon during chaotic development.

When you begin to perform any one task, allow yourself to always follow the design goals. Make sure you find it easily. Discuss design goals with the design team so that they always keep these goals in mind during reviews and presentations. You may decide to change some of the special goals as a result of the test, and you must immediately notify the team members and review the earlier work with them.

6. Design the game for yourself and not for the target user

This is a common mistake in design goals, often caused by people's own sense of presence. And this is not the same as designing a game for a target user because if we design a game for ourselves then the design goals we identified are likely to run counter to the expectations of the intended user. Unless you are the target user of the game yourself, but even then, it's hard to balance the difference between the player and our game habits.

The root of the problem is that creating a game experience is a complex process. It is always difficult to maintain the objectivity of the final game because we always create game content with a bias that may not be what the end user really wants to see.

One big way to correct this bad habit is to better understand the target user's gaming experience. Can be improved through testing, forum discussions, QA exchanges, and expert reviews.

7. completely ignore the competitive products

Understanding competitors and other types of games is a very important process. Sometimes, this kind of research is really thankless chores. Creating research guidelines and evaluating the same type of product can help you achieve your goals better. And doing so can also help you avoid bad habits such as designing games for yourself.

8. Miss new tutorial / introduction

Novice tutorial or introduction is the game mechanics, content to the player's first impression. They will directly affect the player's gaming experience, and the content of the rest of the game there is a difference.

Often these profiles do not appear only once, and they will recur as the game introduces more new features and content. Because this kind of introduction is better able to introduce players into a whole new world (including stories, images and sounds), we must design them more thoughtfully for our target audience.

Many people are deliberately avoiding or ignoring this because designing a novice tutorial / introduction is too cumbersome. To avoid these problems, we must ensure that novice tutorial / profile design tasks are emphasized during game development.

If you neglected a novice tutorial during the planning phase, the potential consequences would no longer be just a bad habit, but rather a lack of critical needs in the pilot process.

9. Design load

Some designers often mistakenly believe that the design is full of great features of the design. The problem is that they have a hard time judging when new features should be added or deleting unnecessary features. Through research, expert review, setting design goals, or prototyping can help designers eliminate unnecessary content and dig out the "fun" core of the design.

We must keep in mind that the design itself will become more and more complicated, especially when some of the functions involve the completion of knowledge in other areas.

Adding more functionality from the start does not guarantee a solution to the mechanics of the game. The only result that this may cause is that developers have to spend more time creating game prototypes. The core goal of the design is to deliver the game content to the player as easily as possible. My friend once told me: "If you can not sum gameplay into 2 lines, then your game is too complicated." I think this is a good guideline.

10. tedious document content

Writing crowded document content or lists is a challenge to people's ability to read and understand. Sometimes the game involves a very large number of files, at a time when it is even more difficult to ensure the readability of the files. As the list of features evolves or changes, all we need to do is keep the content updated in the file.

I found that the picture can make the content of the file more concise, modular also helps to solve this problem, can facilitate different groups to read and use the file. We can break down specifications for features, or make special markup to help different audiences (including programmers, artists, and users) find, rate, or edit the information they need.

When you break the description down into smaller pieces, you must make sure that readers can easily find your design goals (or functional requirements) to help them understand the relationship between the content and the final game.

11. Just test for testing

This is also a bad habit if you test and get the following result:

* Just want to pass the test to confirm an opinion.

* It is not practical to just want to preserve the face or the result obtained.

Get some content or result that is not helpful to the team.

Development teams must regularly test games for prospective users; and it must be kept in mind that the goal of testing is to understand the game experience of a particular player and their perception of the game. The best test results can help you create an optimized finished game.

12. underestimate the target user

Different people will use different ways to experience the game. Do not think that those who do not understand the game function or can not cross some of the testers on the "powerless", "will not play the game." In fact, looking squarely at the constraints these testers encounter makes it possible to further adjust the game to create the end product that is more accessible to the general public.

The downside you really need to get rid of is underestimation of the data provided by the user. According to Jakob Neilsen, a well-known usability expert, according to statistics, the top 5 users out of 15 users can find 85% of the game's usability issues. In my opinion, if the player can not accept or understand the game function, this method may no longer be so effective, but most importantly, do not let your self-esteem impede the objective and fair evaluation criteria, we must face the player's point of view .

13. behind closed doors to design games

One of the bad habits that need to be corrected in order to quickly create gameplay features or content while ignoring content in other areas, including programming and graphics. Other areas of technical goals and aesthetic goals are also important, so further discussion of these elements can help you to strengthen the development team and improve the overall game. As much as possible in the design task with interdisciplinary knowledge and skills designers.

Discuss any possible changes in the design with other members of the team, especially with engineering designers and art directors, to determine differences of opinion in different areas. Remember, the faster does not mean the better.

14. distracted by "research"

Quite often, "research research" is often just an excuse, especially when you say that the target material (such as books, games, or movies) is so appealing that you have delayed other manufacturing efforts.

Sometimes it's always hard to tell when to stop searching and start production. Setting research goals and sticking to a research diary can help us focus more. We do need to release the pressure occasionally. But remember not to let too much "research" affect other work processes, or delay their own development.

15. Avoidance of evaluation

If the team does not set the observation and evaluation policy, developers are easy to run into this bad habit. Evaluation does require that we invest some time and effort, and sometimes there will be rework. Different tasks and projects require people and time involved in evaluation. Post-evaluation can help those who do not understand the iterative process and confuse the final product with the prototype of the early game to better understand the game.

Often, your colleague needs to help you evaluate the job regularly. Tom Cadwell believes it is a major issue that we should value in delaying the evaluation too long. He encourages developers to create an evaluation system as soon as possible in a positive way, and welcomes any attitude evaluation. If you deliberately avoid the evaluation will lead to design flaws, and ultimately affect the quality of the game.

16. Trivia as an excuse

Busy work here refers to a small task that is constantly being recycled and is a trivia that can be done automatically, assigned to other people, or temporarily delayed. And some designers think accomplishing this kind of "busy work" can bring them a sense of accomplishment.

Without the automation process, developers will have to face delays in overall game production, or they may use trivia as an excuse to postpone or avoid some pending tasks or problems.

We should be good at grasping the line between high efficiency and wasting time and distinguish between what is trivial matter. Through process evaluation and time tracking, designers can further clarify which aspects deserve more time and effort.

17. Design stagnation, fear of unknown or failure

Repeat the same type of design for iteration, innovation and optimization. Designers often reuse previous content in order to avoid some unpredictable results (not for games or users).

Any individual or group of members through self-reflection, they will be able to find that over-dependence will seriously delay the game design process. But people are always afraid to change. One trick we use to create prototypes of the game is to follow the maxim of "trying many times to spot problems early." This will allow your team members to find out when they really need to create a new design.

Never play their own game

No one should try too hard to try their own game. Time constraints, lack of interest, loopholes or poor quality can all cause us to be reluctant to play our own games. Designers can easily develop this bad habit, especially in the test hardware or in the face of limited access.

We can solve these problems by managing time or by identifying and removing barriers that affect game access.

19. Self-defense design awareness

Self-defense psychology will further penetrate into all aspects of life, including work. Especially in some critical moments, designers are more prone to such self-defense behavior. And, not very stubborn people will develop this habit. Stress and other elements create an invisible wall in our work that blocks our ability to communicate and cooperate with others.

Improving listening and communication skills can help us better understand and communicate information.

20. ignore the after-examination

In order to further judge the quality of the project, we always need to conduct post-inspection and phase analysis in various stages of development. Because we will always redouble our tensions in handling these problems, we should be careful not to cause hostility or criticism.

And we can not ignore this process of self-assessment on the grounds of inconvenience. Over time, it has always been difficult for us to recall people's memories of past work. If you are working in a larger development team, it can be very effective to record hindsight or group discussions on paper.

Post-examination data are mostly subjective results, so we should not use it as the sole criterion for planning future developments. Vulnerability databases, budget allocations, and time-tracking tools can add more detail to the questions and assumptions found in the discussion.

(This article compiled for the game Bang / gamerboom.com, refused to retain any copy of the reproduced, for reprint please contact: game state)