Bad habits can refer to regular and subconscious negative behaviors. Game Development can be said to be a repeating cycle or process, but how do we define bad design habits? This problem is just as difficult as defining game designers.
We can say that game design is about the process of designing game content and rules, while "content" includes sound, level, and conversation. I will list the 20 bad design habits I know here, and they also apply to creative areas outside of the game.
Bad habits of game design are sorted in no particular order ):
Bad-Habits-Study (from teamaltman.com)
1. Stick to a certain idea
We can see this problem in many ways. There are also more than one reason for this problem. After all, it is difficult to determine when a function has a greater effect or when we need to remove it. The challenge we face here is that our passion for work will directly affect the success or failure of design.
Tom CadwellRiot Games design director) describes this as a trap of "hard to give up. He believes that risk assessment can help developers make the most appropriate decisions. From the perspective of designers, they must be clear that no idea, good or bad, will directly determine the final product formation, and these ideas cannot reflect their creative ability.
2. The design scope is not clearly defined
If the design scope cannot be clearly defined at the beginning, it will lead to many unnecessary troubles in the production process and ultimately affect the formation of the game. This will not only lead to time consumption, errors, and other situations, but also make the entire development process difficult, because you have not set a reference measurement.
If a standard design model is pre-planned, the team members can perform iterations based on some small goals, so that they can clearly define the schedule required for the preparation. We must measure the time and cost of any task at a macro or micro level and apply this scope to all design tasks, instead of simply treating it as a task that meets special design requirements.
3. Propose unreliable Design
For whatever reason, we always need to delete some design content during the game creation process. We must ensure the design flexibility and make adjustments without affecting other parts. In addition, we need to devote more energy to identifying the risks and measurable choices faced by design.
If you are designing a system that does not have more space to change, or directly affects project completion, make sure that the system is recognized by all members of the team, give it enough attention. Too often, dependency is a bad habit that many teams can easily ignore.
4. Lack of self-criticism or criticism
It is always easy for us to select some content that is helpful for design, but it is hard to ensure that the design can impress players. Self-criticism is like a double-edged sword. Sometimes it can help us reach a consensus better, but sometimes it will also bring us into some problems.
In particular, when time is limited, you need to be cautious about self-criticism, because at this time you may not be willing to waste more time in the design and choose to move on. But sometimes, the speed is not up to speed.
On the other hand, we may also be criticized, especially in the early stages of development. We must be clear that excessive criticism will cause us to focus too much on some content and ignore others. Accept all new ideas as much as possible, especially for low-risk content. If the design meets the expected goal, you can make a more objective comparison between its earlier content and the latest content.
Whether it's lack of criticism or criticism, if the content you face is too objective, you 'd better ask for help from others and listen to others' opinions, such as user testers.
5. Forget the design objectives
The design goal is like a beacon, which will guide us to make the right design decisions, but in the chaotic development process, we are always easy to miss this beacon.
When you start to execute any task, you can always follow the design goal. Make sure that you can easily find the content. Discuss design goals with the design team so that they always keep these goals in mind during comments and presentations. You may decide to change some special goals for testing. At this time, you must immediately notify the team members and review the previous work with them.
6. design games for yourself rather than for target users
This is a common mistake in design goals, usually caused by the presence of people. The difference between this and designing a game for the target user is that if we design a game for ourselves, the design goals we determine may be contrary to the needs of the expected users. Unless you are the target user of the game, even so, it is difficult for us to balance the differences between players and our gaming habits.
The root cause of the problem is that creating a game experience is a complicated process. It is always difficult for us to maintain the objectivity of the final game content, because we always create the game content with a bias, which may not be the game that end users really want to see.
A major way to correct this bad habit is to better understand the gaming experience of the target user. Improvements can be made through testing, Forum discussions, QA exchanges, expert reviews, and other methods.
7. Completely ignoring competing products
Understanding competitors and other games of the same type is a very important process. Sometimes, such research is really thankless. Creating Research Guides and evaluating products of the same type can help you better achieve your goals. This can also help you avoid bad habits, such as designing games for yourself.
8. Missing beginner tutorials/intro
A beginner's tutorial or introduction is the first impression of the game mechanism and content on the player. They will directly affect the player experience and differ from the content of other parts of the game.
In general, these profiles will not appear only once, but will repeat as the game introduces more new features and content. Because this introduction can bring players better into the new world of game states, including stories, images, and sounds, we must design them more carefully for target users.
Game-tutorial (from androidtapp.com)
Many people deliberately avoid or ignore this content because it is too cumbersome to design new tutorials/introductions. To avoid these problems, we must ensure that the design tasks of newbie tutorials/introductions should be emphasized during game development.
If you ignore the new tutorial in the planning phase, the possible consequences will not only be a bad habit, but will lead to a lack of key requirements in the pilot production process.
9. Design Load
Some designers often mistakenly believe that a design full of many functions is an excellent design. The problem is that it is difficult for them to determine when new features should be added, or to delete unnecessary features. Listing design goals or prototyping through research and expert reviews can help designers eliminate unnecessary content and explore the "fun" core of design.
We must remember that the design itself will become more complex, especially when some functions involve knowledge in other fields.
Adding more functions at the beginning does not guarantee the solution to the game mechanism. The only result of this operation is that developers have to spend more time creating prototype games. The core purpose of the design is to easily transfer game content to players. My friend once told me: "If you cannot generalize the gameplay into two lines, it means that your game is too complicated ." I think this is a good guiding principle.
10. Tedious File Content
Writing contents or lists of confidential documents is a challenge to people's reading level and understanding ability. Sometimes games involve a large number of files, and at this time we are more difficult to ensure the readability of these files. As the function list develops or changes, what we need to do is to keep the content updated in the file.
I found that images can make the file content more concise and modularized, which can help different groups to read and use the file. We can break down the specifications of the feature, or make a special mark to help different objects in the game state Note: including program designers, artists and users) Find, evaluate or edit the information they need.
When you break down a description into a small part of the content, you must make sure that the reader can easily find your design goal or functional requirements) to help them understand the connection between the content and the final game.
11. Just for testing
If you perform a test and get the following results, this is also a bad habit:
* I just want to confirm an opinion through testing.
* It does not actually work to save the face or result.
* Obtain some content or results that are not helpful to the team.
The development team must perform regular game tests for expected users, and remember that the purpose of the tests is to understand the gaming experience of specific players and their views on the game. The ideal test results can help you create an optimized finished game.
12. underestimate target users
Different people experience the game in different ways. Do not think that testers who do not understand the game function or cannot pass certain levels will be "Powerless" and "will not play games ". In fact, if you face up to these limits, you can further adjust the game to create a final product that is easier to use.
The bad thing you really need to get rid of is to underestimate the data provided by users. Jakob Neilsen, a well-known usability expert, believes that the top five of the 15 users can identify 85% of game usability issues. In my opinion, if players cannot accept or understand the game functions, this method may not be so effective, but the most important thing is, do not let your self-esteem hinder objective and fair judgment standards. You must face up to the players' opinions.
13. design games with closed doors
To quickly create game functions or content, ignoring content in other fields, including programming and images, is one of the bad habits to be corrected. The technical and aesthetic goals in other fields are also important, so further discussions can help you strengthen your development team and improve the overall game. Install designers with interdisciplinary knowledge and skills in design tasks as much as possible.
Always discuss any possible design adjustments with other members of the team, especially with engineering designers and art directors, to determine the differences of opinion between different areas. Remember, the sooner it is, the better it is.
14. being distracted by "Research and Research"
In many cases, "Research and Research" is often just an excuse, especially when you indicate that the target material, such as books, games, or movies, is too attractive and leads to your delay in other production work.
Sometimes it is difficult to determine when to stop searching and start production. Setting research goals and keeping a study 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 your development.
15. Withdrawal Evaluation
If no observation and evaluation policy is set in the team, developers are prone to this bad habit. The evaluation requires us to invest a certain amount of time and effort, and sometimes there will be rework. Different tasks and projects require different staff and time for evaluation. Post-review can help those who do not understand the iteration process and confuse the final product with the early game prototype to better understand the game.
In general, your colleagues often need to help you evaluate your work. Tom Cadwell believes that the long delay evaluation is a major issue that we should pay attention. He encouraged developers to create an evaluation system in a positive way as early as possible, and welcomed comments from any attitude. If you intentionally avoid evaluation, it will lead to design defects and ultimately affect the quality of the game.
16. Use trivia as an excuse
Busy work here refers to small tasks that are constantly circulating and can be automatically completed, assigned to others, or temporarily delayed. Some designers believe that the completion of such "busy work" can bring them a sense of accomplishment.
In the absence of automated processes, developers will have to face delays in overall game production, or they will regard trivial matters as an excuse to postpone or avoid some of the upcoming tasks or problems.
We must be good at grasping the boundaries between high efficiency and time waste and distinguishing what is trivial. Through Process Evaluation and time tracking, designers can further clarify which aspects deserve more time and energy.
17. Design stagnation, fear of unknown or failure
The same type of design is repeatedly used for iteration, innovation, and optimization. Designers often use previous content repeatedly to avoid unexpected results rather than for gaming or users.
Any individual or group member can discover that this excessive dependence can seriously delay the game design process through self-reflection. But people are always afraid of changes. One of the tricks we can use when creating a game prototype is to follow the motto "multiple attempts to discover problems as early as possible. In this way, your team members will be able to find out as soon as possible when new designs need to be created.
18. Never play your own games
No one should be busy as an excuse not to try their own games. Time constraints, lack of interest, vulnerabilities or poor quality may make us reluctant to play our own games. Designers can easily develop this bad habit, especially when testing hardware or facing limited access.
We can solve these problems through time management or identifying and removing obstacles that affect game access.
19. Self-defense design consciousness
Self-defense will further penetrate into all aspects of life, including work. Especially at some critical moments, designers are more prone to such self-defense. In addition, not those very stubborn talents will develop this habit. Stress and other elements will build an invisible wall in our work, and block us from communicating and cooperating with others.
Improved listening and communication skills can help us better understand and convey information.
20. Ignore post-event checks
In order to further judge the quality of the project execution process, we always need to perform post-event checks and Phase Analysis in multiple stages of development. Because we are always getting more nervous when dealing with these problems, we should be more careful to avoid hostility or criticism.
In addition, we cannot ignore this self-assessment process on the grounds of inconvenience. As time passes, it is always difficult for us to recall the memories of past work. If you are working in a large development team, it is very effective to record post-event checks or hold group discussions on paper.
After-event checks, data is mostly subjective, so we should not use it as the only criterion for planning future development. The Vulnerability Database, budget allocation, and time tracking tools can add more details to the questions and assumptions discussed.