Original URL:
Http://data.gameres.com/message.asp? Topicid = 174768
Improvement and prototype of Basic Ideas
From originality to development, a game can be abstracted into two stages: the basic conception stage and the iterative development stage. In the earliest days, any game was just a fragmented and uncertain concept. The planners sorted out the concept and extracted the rules of Mutual Association to form a core rule set, this is the initial framework of the product. For example, the original rules of the Russian square may include removing and adding points when the square is connected into one line; dropping a new square randomly on the top of the head; rotating the square, and so on.
In general, at this stage, game developers will seek to use this set of core rules to create a simple demo to verify the playability of the game itself. This demo often lacks the artistic effect and friendly UI, but the main game loop it follows is generally not very different from the commercial version later. For example, if you are doing a bullet show, you may first create a demo with only one shell and one strange map. Although the content is simple, however, the Round rules and trajectory formulas are basically the same as those in later versions. How much time and effort does it take for a previous product idea to make a demo? How long does it take to test this demo? Different companies and teams often have different answers to this question. A controversial question emerged here: Can the well-conceived and well-developed planning documents Replace the development and evaluation of the demo? The answer is no. Why is a prototype required? Since the prototypeCodeBasically, it cannot be used in commercial products. Since this is just a demonstration for a small number of people, why can't we skip the past? The core reason is that, as a person, our abilities and experience are limited and incomplete in nature. The game is an experience product. The playability of a game cannot be verified by logic and mathematical methods. Instead, some people must pass the actual game process, subjective feelings and judgments. That is why game design is an art. Many game planners are disgusted with the market and operation. They say that games are an art and gameplay is the soul of my pursuit, which is more important than vulgar recharge. They are right in the design and evaluation phase of the prototype. In general, the evaluation of the prototype depends on whether the core rules of the game are clear and easy to grasp. At the same time, users can obtain different selection results based on their operations, and then some fundamental verification from the technical perspective. For example, a game may have complicated and changing rules, but it may take a month to get started. Or a game can be mastered in 3 minutes, but the process of playing and playing is almost the same. These are all problems that need to be analyzed and judged during the prototype process. What should we do next if a prototype is made and you do not think it is fun? It's easy to give up. Get rid of everything and design again. There is a big misunderstanding here. On the one hand, the poor gameplay is attributed to the insufficient internal capacity of the demo, and it is expected that the playability will become better after the internal capacity increases; on the other hand, the demo will give up later and should not be put into too high cost as an excuse, believing that "such a small demo can reach such a level, if ...... The game is certainly good. "In fact, this is all the thoughts and actions that you have dug for yourself. A game, from square bubble dragon in Russia to tianlong in World of Warcraft, is essentially a core gameplay of its own. The core gameplay of large products may be more complex, it is even composed of a group of associated sub-games. However, no matter how big a game works, it is built by an independent play module, a large MMO, many of these games may be successful even if they are not very good. However, there are many gameplay modules, but each product is not very good. It is impossible to win players simply by virtue of functions. That is to say, a successful game may not have a wonderful gameplay, but at least one of them will certainly fail, no matter how long, no matter how high the cost, no matter how longProgramI have made great efforts in art planning. In fact, this is the relationship between 0 after 1 and 0. If there is no 1, then the excess 0 is also 0. I have mentioned a simple theory: the core gameplay is the vertical axis of a game, and the addition of content is the horizontal axis of a game. A good vertical axis can support a wide horizontal axis, like a pop-up hall or a crazy bird, you can design and launch new maps based on your core gameplay. If the vertical axis is not powerful enough, the more horizontal expansion, the faster the product will die. This is like building a house without setting up the house beam and putting bricks up. The faster the building, the faster the collapse. Therefore, in the early stages of the game, the constant tempering of core gameplay and demo changes determines how far this product can go, for example, if you can design the core gameplay rules for crazy birds or Plants vs. Zombies, you can simply find a bunch of art and level outsourcing jobs. This was also established in the field of web games and social networking products, just like the chart pushing and combat systems that are proud of the world, it should all be things outlined in the early stage and throughout the entire product development. Core ideas and concepts of iterative development Well, next, let's take the sensibility of art into the stage of iterative development. What is iteration? Before Shanda, there was a very vivid description, called the small-step run. The following text is from Baidu: iterative development. In the early stages of software development, it is almost impossible to fully and accurately capture users' needs. In fact, the problem we often encounter is that the demand often changes throughout the software development project. Iterative development allows the demand to change during each iteration, and the problem can be further understood through continuous refinement. Iterative development not only reduces project risks, but also ends with a version that can be executed, encouraging developers. In fact, there is still an old saying in China, that is, taking a step by step. In essence, iterative development acknowledges that developers do not have a complete understanding and grasp of user requirements, and developers do not pursue a one-time and global understanding and grasp of product requirements, instead, it collects user behavior and feedback for every product detail, proposes possible solutions, implements and verifies whether the problem is solved, and then moves toward the next step. It can be said that the starting point of iterative development is from the release of a version: Version release, data statistics and analysis, and direct user surveys and inquiries, obtain direct feedback on user behavior. Based on feedback, analyze the cause and propose possible solutions and verification methods, develop the solution and check whether the user behavior has been improved. If there is no improvement, try another solution and repeat this loop. If the improvement is confirmed, continue the subsequent development process. There are three key principles in a typical iterative development process: the shortest iteration cycle, the clear effect verification method, and the low-cost correction solution. The shorter the iteration cycle, the better. This requires that a large version plan be divided into several minor versions to address specific problems. Essentially, each iteration cycle is equivalent to a conversation cycle between developers and users/markets. The more frequently the conversations are conducted, the more in-depth the understanding and grasp of the market. For a friend who calls only once a year, the relationship must not be as close as the friend who eats together every week. The more the relationship between developers and the market is, the more distant the road to success is. A clear effect verification method. This is a mistake made during the development of most products, that is, the result verification is omitted intentionally or unintentionally. Discover a problem in the product, such as a high traffic Loss Rate link, discuss, propose an improvement solution, and make the product online. Then ...... No. In fact, I have always stressed that the subline of iterative development is to acknowledge our ignorance of users and the market. Only a verified method can be called an "experience". This accumulation of experience represents an improvement in the level and competitiveness of the game team. It has no special significance to propose or complete an improvement plan. Because you have no idea whether this improvement solution is correct or wrong? We often take it for granted by ourselves or our leaders on the grounds of cost and duration to replace complicated but reliable operation data and user behavior analysis. I can say that this is my level, in fact, this only leads to one result, that is, the mistakes that have been made, must be repeated at a certain point in time in the future. The longer the construction period and the longer the time, the larger the gap. Just like a five-year-old company, Zynga is really better than us. In fact, every year, there are only a few mistakes they need to make a new product, the mistakes we made five years ago may be the same as the mistakes we made today when we made a product. Low-cost solution design. This means that when we find a stage to be improved, we should first evaluate the schemes with the lowest implementation cost. Because every proposal and implementation of a scheme is a venture capital, the lower the investment, the higher the cost-effectiveness. Low-cost solutions often mean faster development time and shorter iteration cycles. Interestingly, although we can easily support this point rationally, many times such requirements are contrary to the human nature of developers. As a product creator, we often propose a "brand new, better, and comprehensive" solution when discovering all kinds of product deficiencies, and think that is the perfect answer. This can be called an "Innovation impulse", but it can also be called a "Innovation trap ". Practice has proved that this kind of solution looks perfect, often because its details are not fully considered. Most of the time, a slight adjustment to the existing solution can solve 90% of the problem. At this time, the preferred solution must be a lower cost. Some people may ask why they do not put more energy into pursuing product perfection? This is often a very influential way of asking questions, as if we were walking in a cloth, the old lady was asked by the young man on the street. 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, that is, irrational reverence and worship for a specific method. Then I think that all people who disagree with this method have problems with taste or ability. However, after a week or two, we found that this was not the case at all. The reason why the previous perfect solution looks so attractive is that we are only willing to see its advantages, rather than facing its shortcomings. When a solution is truly far ahead of the past in all aspects, we should naturally go forward and put it into practice. In my experience, this situation generally accounts for only one tenth of the total. A period of precipitation, discussion of alternative solutions, and extensive listening to the opinions of people around us will help us determine what is real gold and what is empty shells. One sentence: innovation that has been put forward to solve the problem and proved to be useful through facts is the innovation of effectiveness, and the accumulation of a series of innovation of effectiveness, is a successful commercial product. So in general, when we face a bunch of version feedback and data: 1. The first thing we need to do is to extract the marked parts of the product for further improvement; 2. Propose assumptions about the causes and potential modification plans for these fragments; 3. Remove some low-likelihood and feasible solutions through logic and past experience; 4. Then, design verification methods for the effectiveness of the remaining schemes; 5. Try all schemes as much as possible when the cost permits, find the best one, and fix it. Compared with shoot head, this is a much harder process. What this hard process brings is a huge gap between us and truly top-notch R & D companies. Another very practical problem is how to achieve effective demand iteration when a product has not been launched to the market? At present, there are several methods for reference: first, we should try to reduce the development duration in the early stage, so that the product can be oriented to at least a part of the user base earlier. Second, we should look for participants within a limited scope, typical examples include spontaneous organization and testing within the company, as well as controlled small-range closed tests (which 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 was launched. This is a value beyond the specific method itself. In my opinion, rich original ideas/keen market sense, and successful products (including popular products on the market) analysis and Summary of successful practices/templated and iterative development ideas/powerful and rapid execution capabilities, a reasonable combination of these items, it is the genes inherent in a successful game development company. It is true that for us today, these requirements are far away and hard to meet, but at least they tell us the direction of the future. Philosophical improvements If we carefully study the way humans think, you will find that any innovative idea is based on a specific market hypothesis model at the moment it is brewing. This model exists in our minds and cannot be copied to each other. For example, there may be an idea in my mind: hot and sour cucumbers with mustard will be sold. The big sale here is a simulation of a catering market model based on my understanding and cognition of customers in my mind. I put my ideas in this model, then I found that the calculation result was "very optimistic". What should I do next? Change to cook now? And slow. First, I have to ask myself a question. Do I know about the catering industry? As a person who never cooks, can I determine whether a product will succeed by just relying on speculation in my mind? If you read the previous text carefully, you will understand that the market model in my mind is not complete. By the way, you can also understand that there are no models in your mind, which are exactly equivalent to the market. Essentially, our understanding of the real world is always partial, one-sided, and subjective. This is the norm. Of course, people who often learn about and analyze the market tend to have a lower degree of model deviation than I do, so their judgment is relatively more reliable; however, based on our incomplete understanding of the market, the solutions we have designed are inherently imperfect. This is a very philosophical speculation, but in the process of product development, this can almost be used as a warning sentence. We do not know the user's needs well.> the solution we designed is full of defects.> the defective solution is submitted to users who do not know well. Unexpected deviations will inevitably occur. This is almost a fatalistic pessimistic argument. If we deduct that the incomplete solution will affect and change users' original needs, it is basically the game development version of George Soros's famous "anti-body principle. However, on the other hand, the lack of perfect solutions leads to opportunities for various game design ideas on the market. If there is no perfect answer, everyone can propose their own solutions, then compete in the market and test its effectiveness. There is only one or more perfect solutions for steel production, so new entrepreneurs are basically unable to launch a steel plant. Every one of us has a chance to make a good game.
