Why in 2018 I use the development method, which is already 30 years old

Making games is hard

And the most difficult part of creating games is preproduction. This statement may seem discouraging. We all heard about very difficult periods of production of games and often saw light, simple and interesting periods of preproduction. Why then do I argue that preproduction is more difficult? Because one of the aspects that can poison production is the preproduction performed during it. No matter how complicated the preproduction is, it is much more difficult (and much more expensive) to perform it at the production stage. Let me explain: in an ideal world, no one would undertake the production of a commercial game that fails. If you intend to create a game for the purpose of making a profit, and you know that the game will not bring profit, then you will not proceed to production.

Despite the obviousness of such an assertion, many projects, including those in which I participated, could not foresee how their appearance, mechanics, sound and level design would be combined until the moment when the game was almost ready. The final stage of production is a terribly inappropriate time to discover what works and does not work in the game. Irritating or tiring mechanics have to be thrown away or recycled, which has an avalanche and costly effect on technology, graphics and sound.

At the time of the connection of all the parts (that is, the creation of the first playable version), you understand whether or not your team really went to the original goal. This is an absolutely inappropriate moment if you have worked on the game for several years.

“But game development itself is a chaotic process,” the straw stuffed by me invented objects. Yes, it is right, everything is so. Innovation takes time, talent, wasted labor and an infinite number of iterations. How to pacify this chaos and get the opportunity to create innovations without risking everything?
')
Remember, as I said, preproduction is more difficult than production? The reason why so many projects have a nightmare development process is that in fact their preproduction hasn’t really finished. They collected concept art, several documents, perhaps even a white box . But all this is very far from complete preproduction, at least according to Mark Cernie.

In accordance with the Cerny method, by the end of preproduction you should have one level of the game, indistinguishable from the completed professional product. You can’t cut corners here. The demo is not the first playable version. Alpha is not the first playable version. The White Box is definitely not the first playable version. Graphics, animations, mechanics, and sound must work together, they must be awesome, and together they must be like being able to beat the competition two years later.

But why?

So why bother creating the first playable version, if it takes so much work? Because, according to Cernie,

"This is the only way to get enough chance to create a good game."

The meaning of Cerny’s method is not to eliminate chaos from production, its meaning is to exclude conservatism and chaotic graphics from preproduction. For games, innovation and experimentation are needed, so you shouldn’t do it when the production locomotive is already running along the tracks.

By deliberately making time for chaotic fast iterations, you allow yourself and your team to come up with new interesting ideas. You can change everything on the fly and try ideas that no one has yet implemented. Nothing is too dangerous, too strange, or inappropriate to the genre, because you do not expect that all this will be transferred to production in its current form.

In fact, you need to work as if you are going to throw it all out later.

Later, when the concept of the game begins to take shape, you take your best ideas and create the highest-quality implementation for them.

Having survived in the flames of preproduction, you will learn about your project as much as the majority of developers do not know even after a few years of production. You already know what works, what does not work, what is interesting, and for what the players will hate you. You know how graphics, animations and sound combine with the mechanics and support it. You know everything your avatar can do, as well as levels, obstacles, and / or enemies.

Probably the best thing is that you have already performed iterations at so many levels, and you know what costs they require, that is, you can plan your schedule and budget precisely. And now you can start creating your game, armed with accurate knowledge of how to do it, how long it will take and how much it will cost.

But there is one huge danger:

Caesar slides his finger down.

The Achilles' heel of the Cerny method is this: not every game will survive the preproduction. If you have 5 prototype levels and there is still no first playable version that can be presented to the public, this bomb, which two years later will be able to tear all competitors, then you killed the project.

"There is no point in following this process if you are not going to maintain a very high standard of preproduction."

It sounds cruel, but do not forget that the whole point of the Zerny method is not to be in the situation described above: you are working with full force on the production of a project, a doomed game that will never work.

Skipping the preproduction stage is how to launch a rocket, and then begin to decide where it should land, calculate its trajectory and calculate the amount of fuel it needs when it is already in the air.

When I look back at my failed projects, I have absolutely no doubt that it would be better if they were canceled after 6 months of preproduction than after 3 years of production.

Easy way

But if you have reached the end of preproduction, got the first playable version of release quality and your game is incredibly beautiful, then congratulations! From this point on, work becomes easy; all you need is to make a game. Cerny puts it this way:

The first playable version of the release level proves that you have achieved exactly what your game is and is not, and you have enough knowledge to make it. It draws a line between preproduction, when you know nothing, and production, when you know everything.

Of course, I'm exaggerating - there is nothing simple in creating a game. But imagine that you have the opportunity to create levels, being 100% sure that the distance of the character’s jump will not change later. Imagine being able to see the intersecting branches of the storyline in a single-page spreadsheet. Imagine that you do not need to constantly rewrite the documentation, throw away resources that are ready for production, and carry on design disputes in the context of an impending deadline.

I do not think that everyone should use the Zern method. There are reasons for this. that it is outdated, many teams are able to use Agile or another iterative method. But for the first time I am doing the game myself and I know that I am not the only one.

A studio is much more likely to recover from a failure than an indie developer who has mortgaged his home. If you are thinking of investing your own money in the game, then for God's sake, first engage in preproduction. Do not wait until 90% of the production budget goes to test the concept.

Restrictions

Exactly following the method of Zern has its limitations. One of them is that after the transition from preproduction to production, you must switch from unlimited creative openness to unshakable conservatism. And this can be seen in the games Zernie. In the later levels of Crash 2, almost nothing new appears, which would not exist in the early forms in various forms. The complexity increases, the obstacles are combined in a new way, but the fundamentals remain more or less the same.

Crash compensates for the problem by what Cerny calls "special mechanics." In Crash 1, a wild boar ride was a special mechanic. But according to the Zern method, special mechanics cannot be invented retroactively; it must be iterated and tested at the preproduction stage, just like the basic mechanics.

Crash 3 has the greatest variation in the series: after each boss Crash gets a new ability. Most of the uncertainty is compensated by the fact that new abilities are variations of existing ones. The only truly new ability is a bazooka. She also became the most clumsy mechanics of the game; it is noticeable that it is not as sharp as all the other mechanics. A bazooka is an example of what can happen if you are not conservative at the production stage.

I fondly love games like Portal 2, Rayman Legends, Psychonauts and Antichamber, in which it seems that each new area offers more innovations than the previous one. Most likely, such games cannot be created by the Cerny method, because it is impossible to separate their production and preproduction in this way.

Such games require constant (CONSTANT) iterations and testing at levels close to production. Otherwise, each new level will seem like a non-tested prototype. Ubisoft and Valve have the resources for this, I don’t. The development of Antichamber does not go to any comparison, because it took a lot of time, and the graphics of the game are minimal (brilliant, but minimal).

I make a game with a tiny team and very limited resources. I do not want to spend ten years and do not want to come to the completion of development only to realize that the game was doomed a month after the start of work. That is why I use the Zern method.