From creativity to development, a game can be divided into two major stages in abstract terms: the stage of basic conception, and the stage of iterative development. In the earliest days, any game is just one or a group of scattered and uncertain ideas. The planner organizes this group of ideas and extracts the interconnected rules to form the core rule set. This is the initial framework of the product. For example, the initial rules of Tetris may include: removing blocks and adding points when they are connected in a row; new blocks drop randomly on the top of the head; the blocks can be rotated, and so on.
Generally speaking, at this stage, game developers will seek to use this set of core rules to establish a simple DEMO to verify the playability of the game itself. This DEMO often lacks art effects and friendly UI, but the main game loop it follows is generally not very different from the later commercial versions.
For example, if you are doing a bombing hall, you may first create a demo version with only one type of shell, one monster and one map. Although the content is simple, the round rules and ballistic formula are basically the same as the later version.
For a preliminary product idea, how much time and effort will it take to make a DEMO? How long will it take to test this DEMO? Different companies and teams often have very different answers to this question.
A very controversial question arises here: Can meticulous ideas and complete planning documents replace the development and evaluation of DEMO? the answer is negative.
Why do you want to prototype? Since the prototype code is basically impossible to be used in commercial products, since this is just a demonstration for a small group of people, why not skip it?
The core reason is that, as human beings, our abilities and experience are essentially limited and incomplete. The game is also an experiential product. The playability of a game cannot be verified by logical and mathematical means. It must be subjectively felt and judged by some personnel through the actual game process. And this is why game design is an art.
Many game planners have a disgusting attitude towards the market and operations. They say that games are an art, and gameplay is the soul of my pursuit, which is more important than vulgar recharge. They were right during the design and evaluation phase of the prototype.
For the evaluation of the prototype, generally speaking, it depends on whether the core rules of the game are clear and easy to grasp, and at the same time, a variety of different selection results can be obtained according to the user’s operation, and then some basic verifications from a technical perspective. For example, a game may have complicated rules and changes, but it takes a month to get started; or a game can be mastered in 3 minutes, but the process is the same every time. These are all issues that need to be analyzed and judged during the prototyping process.
If a prototype is made, and people don’t think it’s fun, what should we do next?
It’s simple, give up. Throw everything away and start designing again. There is a big misunderstanding here. On the one hand, the poor gameplay is attributed to the insufficient amount of DEMO content, and it is hoped that the playability will improve after the amount of content increases. On the other hand, the DEMO will give up sooner or later and should not invest too high costs. As an excuse, I think “Such a small DEMO can reach such a level, if…, the game will definitely be good.” In fact, this is the thought and behavior of digging holes for myself.
A game, as small as Tetris Bubble Shooter, as large as the World of Warcraft Dragon Babu, essentially has its own core gameplay. The core gameplay of a large product may be more complicated, and even consist of a set of interrelated sub-games. The gameplay is combined with each other, but no matter the big game or the small work, it is built up of independent gameplay modules. For a large MMO, many of the gameplays may not be particularly good and can be successful; but there are many gameplay modules. But each one is not a great product, and it is impossible to win players by relying on more features than others.
That is to say, a successful game does not necessarily have every gameplay wonderful, but a game without at least one more wonderful gameplay will definitely fail, no matter how long, no matter how high the cost, no matter how hard the program art planning is. In fact, this is the relationship between 1 and the 0 behind the 1, if there is no 1, then the more 0s add up to 0.
I talked about a simple theory: the core gameplay is the vertical axis of a game, and the increase in content is the horizontal axis of a game. A good vertical axis can support a very wide horizontal axis, just like a bomb. Tang or Crazy Bird, based on its core gameplay, can continue to design and launch new maps; and if the vertical axis is not strong enough, the more horizontal expansion, the faster the product will die. It’s like building a house without putting up the beams and putting bricks on it. The sooner it is built, the faster it will collapse.
Therefore, in the early stages of the game, repeated modifications to the core gameplay and DEMO are constantly tempering, which determines how far this product can go. For example, you can design the core gameplay of crazy birds or plants vs. Zombies. Rules, the next thing to do is to find a bunch of art and levels to outsource work. This is also true in the field of web games and social products, just like the push map and combat system of the world, which should be outlined in the early stage and run through the entire product development.
The core ideas and concepts of iterative development
Okay, next, put away the sensibility of art, we are about to enter the stage of iterative development.
What is iteration? Shanda used to have a very vivid description, called small steps and fast running.
The following text is from Baidu: Iterative Development. It is almost impossible to fully and accurately capture user needs in the early stages of software development. In fact, the problem we often encounter is that requirements often change throughout the software development project. Iterative development allows changes in requirements during each iteration, and deepens the understanding of the problem through continuous refinement. Iterative development can not only reduce the risk of the project, but each iterative process ends with an executable version, which can inspire developers.
In fact, there is an old saying in China, which is called one step at a time. In essence, iterative development recognizes that the current understanding and grasp of user needs by developers is not complete. Developers do not pursue a one-time, overall understanding and grasp of product requirements, but collect users for each product detail. Behavior and feedback, propose possible solutions, implement them and verify whether the problem is solved, and then move on to the next cycle.
It can be said that the starting point of iterative development is to start with the release of a version: version release, through data statistics and analysis, and direct user surveys and inquiries, to obtain direct feedback on user behavior; analyze the reasons based on the feedback and propose possibilities The solution and verification method are developed, and the solution is developed to observe whether the user’s behavior has improved. If there is no improvement, then try another solution and repeat the cycle; if it is proven to improve, then continue with the next development process.
In a typical iterative development process, there are three key principles: as short an iterative cycle as possible, a clear effect verification method, and a low-cost correction plan.
As long as it does not cause too much trouble to users and operations, the shorter the iteration cycle, the better. This requires that a relatively large version plan be divided into several smaller versions, each for a specific problem. In essence, each iteration cycle is equivalent to a dialogue cycle between the developer and the user/market, and the more frequent the dialogue, the deeper the understanding and grasp of the market. A pair of friends who only talk to each other once a year is definitely not as close as a friend who eats together every week, and the more distant the relationship between the developer and the market, the further away the road to success will be invisible.
Clear effect verification method. This is a mistake that most product development processes will make, that is, deliberately or unintentionally omitting the verification of the effect. Found a problem in the product, such as a high churn rate link, discussed, proposed an improvement plan, and completed the production and went online. Then… it’s gone.
In fact, I have been emphasizing that the subtext of iterative development is to acknowledge our ignorance of users and the market. Only a proven method can be called an “experience”, and this accumulation of experience represents the improvement of the level and competitiveness of the game team. Just being satisfied with proposing or completing a certain improvement plan does not have any special meaning in itself. Because you don’t know at all, is this improvement plan right or wrong?
We often use cost and construction time as reasons, and replace complicated but reliable operation data and user behavior analysis with our own or leaders’ assumptions, and plausibly say that this is my level. In fact, this has only led to one result, that is, I have committed The mistake you made will inevitably be repeated again at some point in the future. The longer the construction period, the longer the time, the greater the gap. Just like a company that has been established for 5 years, Zynga is really stronger than us. In fact, every year, when they make a new product, they need to make fewer mistakes. And the mistakes we made 5 years ago There may be as many mistakes as making a product today.
Low-cost solution design. This means that when we find that a certain link needs to be improved, we should first evaluate the solutions with the lowest implementation cost. Because every proposal and implementation of a plan is a venture investment, under the premise of clear goals, the less investment, the higher the cost performance. Low-cost solutions often mean faster development time and shorter iteration cycles. The interesting thing is that although it is easy for us to support this intellectually, in many cases such a requirement is contrary to the human nature of the developer itself.
As product creators, we often come up with a “new, better, and packaged” solution when we discover the shortcomings of the product, and think that it is the perfect answer. This can be called an “innovative impulse”, but it can also be called an “innovative trap.” Practice has proved that this seemingly perfect solution is often just because its details have not been fully considered. Most of the time, a slight adjustment to the existing scheme can solve 90% of the problem. At this time, the preferred solution must be a lower cost solution.
Some people may ask why not put more energy into the pursuit of product perfection? This is often a very impactful way of asking questions, just as if we were a little old lady walking around wrapped in a footwear, and were questioned in the street by the youth of the May Fourth Movement.
In fact, the answer is very simple, because the perfect solution you and I think at this moment is often not perfect at all. People often fall into a misunderstanding of thinking, that is, irrational admiration and worship of a particular way. Furthermore, it is believed that all people who disagree with this approach have problems with taste or ability. However, after a week or two, I realized that it was not like this at all. The reason why the previous perfect solution looks so attractive is only because we only saw its advantages wishful thinking and are unwilling to face its shortcomings.
When a plan really outperforms the past in all aspects, we should naturally go ahead and put it into practice. According to my experience, this situation generally accounts for only one-tenth of the ratio. A period of precipitation, discussion of alternatives, and extensive listening to the opinions of people around us help us to judge which things are real gold and which things are empty bombs.
In a word: innovations that are proposed to solve problems and have been verified by facts and proved to be useful are effective innovations, and the accumulation of a series of effective innovations is a successful commercial product.
So in general, when we are faced with a bunch of version feedback and data: 1. The first thing to do is to extract the segments that are marked to further improve the product; 2. For these segments, put forward the reasons Assumptions and potential modification plans; 3. Through logic and past experience, remove some of the less feasible and implementable plans; 4. Then, for the remaining plans, design a verification method for the effectiveness of their adjustments; 5. When the cost permits, try all the solutions as much as possible, find the one with the best effect, and fix it.
Compared to patting the head, this is a much harder process. What this painstaking process has brought about is the huge gap between us and the truly first-class R&D company.
Another very practical question is how to achieve effective demand iteration when a product has not yet been launched on the market? At present, there are several methods for reference: First, try to shorten the pre-development time, so that the product can be targeted to at least a part of the user group earlier; second, find participants within a limited range, typically such as the company’s spontaneous development. Organization and testing, including controlled small-scale closed testing (this is almost one of the most common practices); finally, remember one thing: For the development team, the real development cycle starts from the day the product goes live Count. This can be said to be a value that goes beyond the specific method itself.
In my opinion, rich original ideas/keen market sense, analysis and summary of successful practices of past successful products (including popular products on the market)/template, iterative development ideas/strong and rapid execution capabilities, these A reasonable combination of items is the inherent genes of a successful game development company. It is true that for us today, these requirements are far away and difficult to meet, but this at least tells us the direction of the future.
Some philosophical improvements
If we study the human way of thinking carefully, you will find that any innovative idea is based on a specific market hypothetical model at the moment it is brewed. This model exists in our minds and cannot be copied from each other. For example, there may be an idea in my mind: hot and sour cucumbers with mustard will sell well. The big seller here is a model of the restaurant market that I simulated based on my understanding and cognition of customers in my mind. I put my ideas in this model and found that the calculation result is “very optimistic.” What should I do next? Change your job as a cook immediately?
Wait a minute. First of all, I have to ask myself a question, do I know the catering industry? As a person who never cooks, can I just rely on my guesswork to determine whether a product will succeed or not?
If you read the previous text carefully, you will understand here that, in fact, the market model in my mind is not complete. By the way, you can also understand that there is actually no model in anyone’s mind that is completely equivalent to the market. In essence, our understanding of the real world is always partial, one-sided and subjective, which is a normal state. Of course, people who often understand and analyze the market will have less deviations in their models than laymen like me, so their judgments are relatively more reliable; and we have designed a solution based on our incomplete understanding of the market. The plan is inherently imperfect. This is a very philosophical speculation, but in the process of product development, it can almost be used as an aphorism.
We don’t know enough about the needs of users >> The solution we designed is full of flaws >> Submitting a flawed solution to users who don’t know enough will inevitably produce unexpected deviations.
This is almost a fatalistic pessimism. If we continue to deduct, the incomplete plan will affect and change the original needs of users, then this is basically the game development version of George Soros’s famous “reflexivity principle”.
But on the other hand, it is precisely because of the lack of perfect solutions that various game design ideas on the market have their opportunities. There is no perfect answer so everyone can propose their own solutions, and then compete and test in the market. Its effectiveness. There are only one or several perfect solutions for producing steel, so new entrepreneurs basically cannot open a steel plant. The idea of making good games is ever-changing, so each of us has our own opportunities.
