This article was first published on the WeChat public account: Little Ants teach you how to play games. Welcome to pay attention to receive more original tutorial materials for learning to make games, and learn some game development knowledge every day.
Hi! Hello everyone, I am Little Ant.
The day before yesterday I just released a new game work - classic gem cube. It's still a handheld mode, it's still a minimalist style, and it's still a game I'm very satisfied with. Why do you say still? Because it continues the last Tetris game (handheld minimalist style), and I think it is better than the previous one.
Of course, everything I think is considered from the perspective of a game developer.
Yesterday, when my wife was playing a game, she said to me: "Husband, can't you save this game?" When I heard this question, I was a little puzzled, and replied: "My dear, this game does not need to be saved. functional, and what do you want to preserve?". My wife said: "Every time I was playing, and I encountered other things in the middle, I paused the game and switched it out. When I came back, I found that I had to start playing again. I couldn't save the original game. I came back. Can I continue to play at this time?", I thought for a while, and replied: "You see, the WeChat mini-game provides a temporary exit function. Click the small dot in the upper right corner, and the game will be put in the background. Wait for you to finish other tasks. Things, push it up again, select the game, you can switch back, and the game can continue to play.”
Although this is the answer, I have begun to think about the rationality of this approach. Will players know that doing so temporarily puts the game in the background? And will the player choose to do so instead of simply quitting the game?
Then, my wife's words directly confirmed that this method is not feasible. "However, every time I quit like this, when I come back, I have to start again." Yes! It is impossible for WeChat to keep the applet that has retreated to the background in the process. If the applet has not been awakened after a period of time, it will definitely be completely exited. After completely exiting and opening the game, it must be restarted. started.
So, I tried to explain the principle of the above process to my wife. After listening, my wife seemed to understand and asked: "Can this save be realized in the game?" After hearing this question, I finally woke up Yes, "Yes, and this should be implemented in the game." After I finished speaking, I immediately added one item to today's to-do list: Add the function of saving progress. After exiting the game midway, the current game state will be saved. When you enter the game next time, you can continue to play with the previous progress.
So, in today's new version, when you quit halfway (whether it is temporary or completely closed), when you come back next time, "start the game" becomes "continue the game", and you can continue played.
This is in line with our perception of doing one thing. If you stop halfway to do something else, you should be able to continue doing it when you come back. If you need to start from scratch every time you do this thing, That's obviously not normal because it goes against our intuition.
Through this incident, I thought about a question: Why, as a developer, I couldn't think of such an obvious demand? It never occurred to me that this should be needed until my wife brought it up.
This reminds me of a word I've seen before, called Designer Blinders (Designer's Visual Blind Zone) , which roughly means that when a game developer is concentrating on his work, he will miss important details. This is indeed the case. When I focus on the realization of game functions, it is easy to ignore some obvious things, such as will this game player play when he first gets started? Is the game too difficult for beginners? Can players understand certain functions in the game? Will it cause confusion? …
In the process of making games, game developers usually follow their own feelings. But the developer's feeling may be very different from the final player's feeling, because the developer knows too much about the game he makes, and it is likely that what is obvious to the developer is difficult for the player to detect, and for the developer Something very simple, but difficult for players.
Therefore, the game needs to invite players to try it out for testing. In the process of inviting players to try it out, what the developers focus on is not whether there are bugs in the game functions, but how the players experience the game. How do players react when they open the game for the first time? Did you get started smoothly? Will it show doubts? Did the player appear happy when the game was successful? When the game fails, does the player choose to continue the challenge, or lose interest...
All this requires is not technical ability, but observation ability. You need to be a careful observer to observe any clues that a real player reveals throughout the game, so as to infer the player's experience and feelings about the game. Finally, compare it to the experience you want to convey to the player to see where adjustments need to be made.
Fortunately, testing the game is not that difficult, especially for small games of individual developers, you only need to find people familiar with you to try your game. Then, watch how they react in-game as a bystander, and if their reactions match your expectations, then your game should be fine.
In fact, there is a very good way to effectively restrain the developer's "self-righteousness" and help the developer to guard against the visual blind spot, that is, to often ask yourself such a question during the development process:
Who the hell is this game for? ? ?