On the iterative method of product development

Perfecting and prototyping the basic idea

A game from creativity to development, the abstraction can be divided into two major stages: the basic concept of the stage, and iterative development stage. Any game at the earliest time is just one or a group of scattered and uncertain ideas, the planners of this set of ideas, extract the interrelated rules to form a core set of rules, this is the original framework of the product. For example, the original rules of Tetris may include: squares are eliminated and added in one line, the top randomly drops new squares, squares can rotate, and so on.

In general, at this stage, the game developer will seek to use this set of core rules to create a simple demo, to verify the game itself can play. This demo is often a lack of artistic effect and friendly UI, but the main game cycle followed is not much different from the later commercial version.

For example, if you're in a pinball hall, you might start with a demo version of only one shell, one weird map, although the content is simple, but the round rule and the trajectory formula are basically consistent with the later version.

For a preliminary product concept, how much time and energy to do demo? How long will it take to test this demo? Different companies and teams often respond differently to this question.

Here is a very controversial question: the careful idea plus the perfect planning document, can replace for demo development and evaluation? The answer is no.

Why make prototypes? Since the prototype code is basically impossible to use in the commercial finished product, since this is only for a small number of people to see the demo, skip the past why not?

The core reason is that, as human beings, our abilities and experiences are inherently limited and incomplete. And the game is a kind of experiential products, a game of the play, can not be verified by logical and mathematical way, and must pass through the actual game process, subjective to feel and judge. And that's why game design is an art reason.

Many game planners are in the heart of the market and operations are hostile attitude, they said, game is an art, game is my pursuit of the soul, which is more important than vulgar recharge. They are right in the design and evaluation stages of prototypes.

The evaluation of the prototype, in general, is to see whether the core rules of the game is clear and easy to grasp, at the same time, according to the user's operation can get a variety of different selection results, there are technical aspects of the basic verification. For example, a game may be a complex and changing unpredictable, but it takes one months to get started, or a game can be mastered in 3 minutes, but the process of playing it every time is similar. These are the problems that need to be analyzed and judged in the process of prototyping.

If a prototype is done, people don't think it's funny.

Very simple, give up. Throw everything away and start the design again. There's a big misunderstanding here, on the one hand, the game is due to the lack of the content of the demo, counting on the content to increase the ability to play after a good, on the other hand, the demo will give up sooner or later should not put too high cost as an excuse, that "such a small demo can achieve such a standard, if , the game must be good. "In fact, this is the thought and behavior of their own digging pits."

A game, small to Tetris Bubble Dragon, big to the World of Warcraft Tianlong Eight, in essence, have their own core play, the core of large-scale products can be more complex, or even by a group of interrelated child playing together with each other, but regardless of the big game of small works, are by a separate way to build the module , a large MMO, many of which may not be particularly good or successful, but a lot of play modules, but each one is not a good product, it is impossible to rely solely on the function of more than others to win the player.

That is, the success of the game is not necessarily every play is wonderful, but there is not at least a more exciting game play, will fail, no matter how long, regardless of the cost of high, regardless of the process of art planning more efforts. In fact, this is the 1 and 1 after the 0 relationship, No 1, then more 0 Plus is 0.

I have said a simple theory: The core of the game is a game of the longitudinal axis, the increase in content is a game of the horizontal axis, a good longitudinal shaft, can support a wide horizontal axis, like pinball hall or crazy birds, based on their own core play, you can continue to design new maps, and if the longitudinal axis is not strong enough, The more horizontal the extension, the faster the product will die. It's like building a house without putting a beam on it and putting bricks on it, the quicker it collapses.

So, at the beginning of the game, for the core play and demo repeated changes constantly tempered, is to determine how far the product can go the Foundation and foundation, for example, you can design crazy birds or plants vs zombies core rules of play, then the next thing to do is to find a pile of art and level outsourcing work. This is also true of web games and social products, like the world's push-and-fight systems, which should have been sketched and run through the whole product development in the early days.

The core idea and idea of iterative development

All right, next, let's get the art out of the loop, and we're going to go to the stage of iterative development.
What is an iteration? Grand before there is a very image of the description, called Small steps run.

The following text comes from Baidu: iterative development. It is almost impossible to capture the user's needs completely and accurately at the early stages of software development. In fact, the problem we often encounter is that demand is often changed throughout software development projects. Iterative development allows for changes in requirements during each iteration, deepening the understanding of the problem through refinement. Iterative development can not only reduce the risk of the project, but each iteration process can be implemented to end the release, can inspire the developers.

In fact, China also has an old saying, called take a step to see. In essence, iterative development acknowledges that developers ' current understanding and mastery of user needs is incomplete, developers do not pursue the product requirements of a one-time, global understanding and grasp, but for each product details, collect user behavior and feedback, propose possible solutions to implement and verify that the problem is resolved, And then move on to the next loop.

So to speak, the starting point for iterative development, is to start with a release: release, through data statistics and analysis, as well as direct user surveys and inquiries, to obtain user behavior direct feedback; Based on the feedback analysis reason and propose the possible solution and the verification method, the development completes this solution, Observe whether the user's behavior has improved. If there is no improvement, try another solution, repeat the cycle, and if proven to be improved, continue with the next development process.

In a typical iterative development process, there are three key principles: the shortest iteration cycle, the explicit validation method, and the low cost correction scheme.

The shorter the iteration cycle, the better, without having to worry about users and operations. This requires a larger version of the plan to be cut into several iterations, respectively, for a specific problem. In essence, each iteration cycle is equivalent to a conversation cycle between the developer and the user/market, and the more frequent the conversation, the deeper the understanding and grasp of the market. A pair of friends who only talk once a year will not be as intimate as the friends who eat together every week, and the more alienated the relationship between the developer and the market, the farther away the road to success is not visible.

Clear method of effect validation. This is the vast majority of product development process will make mistakes, is intentionally or unintentionally omitted the validation of the effect. Found a problem in the product, such as a high loss rate link, discussed, proposed an improvement program, production completed on-line. And then...... It's gone.

In fact, I've been stressing that the subtext of iterative development is acknowledging our ignorance of users and markets. Only a validated method can be called "experience", and this accumulation of experience represents the improvement of the level and competitiveness of the game team. There is no particular meaning in itself to be satisfied with the proposal or completion of some kind of improvement program. Because you have no idea whether the improvement plan is right or wrong?

We tend to use cost and duration as justification, take their own or leadership's take for granted, to replace the complex but reliable operational data and user behavior analysis, and plausibly said that this is my level, in fact, this only led to a result, is that the mistakes have been made, must be repeated at some point in the future. The longer the duration, the longer the gap becomes larger. Like the same company that was founded 5 years ago, what Zynga is really tougher than us is that every year they make a new product with fewer mistakes, and the mistakes we made 5 years ago are likely to be as much as the mistakes we made today.

Low-cost solution design. This means that when we find that a link needs to be improved, we should first evaluate those programs that have the lowest cost of implementation. Because each of the proposals and implementation of the project is a venture capital, in the premise of a clear goal, the less investment, the higher the cost. Low-cost solutions often mean faster development times and shorter iterations. Interestingly, although intellectually we can easily support this, many times such demands are contrary to the human nature of the developer itself.

As creators of products, we often come up with a "new, better, package" solution when we discover the shortcomings of the product, and think that is the perfect answer. This can be called a "creative impulse", but it can also be called an "innovative trap". Practice has shown that this seemingly perfect scenario is often just because the details are not considered sufficient. Most of the time, a little adjustment in the existing scheme can solve the problem of 90%, when the priority choice must be a lower cost solution.

Some people will ask why not invest more energy in the pursuit of product perfection? This is often a very shocking way to ask questions, as if we were in the binding cloth walking little old lady, Wusi Young Street questioned General.

In fact, the answer is very simple, because you and I think this moment the perfect solution, often not perfect. People often fall into a misunderstanding of thinking, that is, the irrational admiration and worship of a particular way. It goes to the view that all people who disagree with this approach are having problems with taste or ability. But after one or two weeks, it turns out that it's not. The previous perfect solution looks so tempting just because we see its merits in a one-sided way and are unwilling to confront its shortcomings.

When a program is really far better than it used to be, it is natural that we should go ahead and put it into practice, which, in my experience, generally accounts for only one-tenth of the time. A period of precipitation, alternative discussion, and wide listening to the opinions of the people around us are helpful in determining which things are real and which are blanks.

Bottom line: Innovation that is proven to be useful for solving problems and validated by facts is the innovation of effectiveness, and the accumulation of a series of effective innovations is a successful commercial product.

So overall, when we face a bunch of version feedback and data: 1, the first thing to do is to extract the further improvement of the product has significantly marked the fragment; 2, for these fragments, put forward the hypothesis of its cause and potential modification program; 3. Through logic and past experience, Remove part of the possibility and the less implementation of the scheme; 4, then, for the remainder of the scheme, the design of the validation of its effectiveness of the method; 5, in the case of cost permitting, try all the options possible, find the best one, and fix it.

It's a much harder process than shooting your head. And the hard part of the process is the huge gap between us and the really first-rate research and development companies.

Another real question is how to achieve effective demand iterations when a product has not yet been launched into the marketplace. At present, there are a few ways to refer to: First, as much as possible short prophase development, allowing products to be targeted at at least a fraction of the user base earlier, and secondly, looking for participants in a limited range, typically within a company's spontaneous organization and testing, and also controlled small-scope closed tests (which is almost one of the most common practices) And finally, remember one thing: for a development team, the real development cycle starts with the day the product comes online. This can be said to be a value that goes beyond the specific method itself.
I think that the rich original creative/keen market sense of smell, the logical combination of the analysis and summary/templating, iterative development ideas/powerful and rapid execution of successful practices in previously successful products (including popular products on the market) is the genetic locus of a successful gaming development company. Admittedly, these requirements are remote and difficult to achieve for today's us, but this at least tells us the way forward.

Some of the philosophical aspects of Ascension

If we look closely at the way people think, you will find that any innovative idea is based on a particular market hypothesis in the moment it is conceived. This model exists in our minds and is not replicable. For example, there might be an idea in my head: hot and sour cucumbers with mustard will sell. The big sale here is a model of the catering market that I've modeled on the understanding and perception of customers in my head, and I put my ideas into this model, and then I find out that the results are "very optimistic" and what to do next? Go to the cook now?

Wait。 First I have to ask myself a question, do I know the catering industry? As a person who never cooks, can I decide whether a product will succeed or not, simply by using the guesswork in my head?

If you read the previous text carefully, you will understand that the market model in my mind is not complete. Incidentally, you can also understand that no one in the mind of the model, is completely equivalent to the market. In essence, our understanding of the real world is always partial, one-sided and subjective, which is the norm. Of course, the people who often go to know and analyze the market, the degree of deviation of the model, will be smaller than my layman, so their judgment is relatively more reliable, and we based on the imperfect understanding of the market, the design of the solution, in essence, is necessarily imperfect. This is a very philosophical speculation, but in the process of product development, this can almost be used as a aphorism.

We are not familiar with the needs of users >> we have designed solutions full of defects >> defects of the solution submitted to the users who do not know, will inevitably produce unexpected deviations
This is almost a fatalistic pessimistic argument. If we extrapolate, incomplete solutions will affect and change the user's original requirements, which is basically Soros's famous "reflexive principle" of the game development version.

On the other hand, because of the lack of perfect solution, it leads to a variety of game design ideas in the market have their own opportunities, there is no perfect answer so everyone can put forward their own plans, and then compete in the market and test their effectiveness. The perfect solution for producing steel is one or more, so the new entrepreneur is basically unable to open a steelmaking plant. The idea of making good games is constantly changing, so each of us has our own opportunity.

SOURCE Address: http://www.z-index.cc/201 ... 11/10/13/238/