Why sometimes you have to beat yourself?

Good day. My name is Ilya and I am a perfectionist.

One of the main problems of most startups is that they never become startups: they simply are not able to complete their first project. Similar difficulties are experienced by some freelancers - they do not always come out to finish the project on time.

These problems have a common fairly trivial solution. But no one dares to abandon the ideality of their code, and instead of getting a completed project, they usually make a dream project.

A month ago, our team, consisting of one and a half designers and one and a half coders, took first place in the regional championship on high-speed game development. The development was given only 48 hours. Two days, consisting entirely of coffee and nerves, resulted in the most completed of the projects of the competition. I will tell you what I had to do with myself and my desire to write the perfect code that would not be scary to show people.



Speaking remotely, the competitive game was supposed to be a small project, without long-term support with one or two patches and a preparatory stage. The two main criteria for evaluating such projects are logical completeness and relevance to the topic. A lot depended on the conditions of the competition. I’ll make a reservation right away: according to its conditions, it was possible to choose any language, any framework, any engines and any art, provided that all licensing problems fall on the performer. There were also complicated versions of the rules, according to which one person had to participate in the competition and at the end provide all the sources, but our organizers refused them. In any case, I chose pure ActionScript without any engines.

Work without TK. Preparatory stage

The competition began at eight in the evening on Friday. From that moment, one could already start to do something - to draw the basic design blanks, write basic code modules, and come up with a game concept. However, the theme of the game all the teams received only in the morning, common to all and unknown in advance. Initially, only an array of 25 possible topics was known, of which, by global vote, by eight in the morning of Saturday, the “Evolution” that was very unexpected for everyone was chosen. Here our first problem appeared, having solved which we caught the very wave of gouging, which allowed us to finish the game in time.

Friday evening we spent on a game engine suitable for 20 out of 25 topics. We missed very different moments, hoping that by the next day we would simply customize a ready-made engine for any topic. When we learned that the topic is included in those five unaccounted for, the result of the preparatory work had to be simply thrown away. In fact, this preparatory stage, when it is already known exactly what we will do, but it is not yet known thatwe will do is very important, and it is always with everyone. Freelancers - when they took the order, but the customer was in no hurry with the Terms of Reference; enterprises that have software production put on stream have a kernel that they grow and sell all their free time from orders; in indie - the moment when the design document has not yet been verified, and his hands are already itching to write at least something. At this point, it’s best to do things that are really common to all projects. For example, in all games you need a timer - make the timer universal, calibrated to the millimeter, with convenient start and call the methods you need. Or the main menu. Or preloader / installer. Even for designers, you can come up with some templates of the same main menu and outline the interface. I would save myself a lot of nerves if I wrote an engine for messages from the keyboard and mouse in those eight hours of the first day,

A wave of gouging, or when it's time to stop planning and start doing.

On Saturday morning, the designer and I came to the office to urgently come up with a game that would suit an unexpected topic. Here we need to make a digression and notice that our team was called “ Who cares?”, Which in a free censorship translation may mean:“ Who cares at all? ”. We stood at the project board and looked at it without a single thought in our head, until one of us said: “Who cares about evolution? Who needs complex games with a branched plot, especially built in two days? ” It was decided to make a very simple game with primitive gameplay, built on a pure fan. The essence of the game was proclaimed a bored deity, who decided to refute the theory of evolution in practice, using his divine slipper destroying the most adapted types of monsters on some abstract planet. The designer sat down to look for examples of art and color guidelines (I have no idea what this means), and I wrote a design document.

At first, there was only one sentence in the disco: "This is a game about violating the laws of evolution with a divine slipper." Over the course of two days, the dzdock was replenished with more and more new features, but none of them contradicted the initial statement. The beauty of such a formulation is that it allows you to start work immediately without thinking through the details for several hours. It gives an unambiguous answer to the question "what to do?" Without bothering with conventions, like: "how to do it?". The best option would be if at least the first time there are no questions like “how?”. There is a task, it is formulated and, although not specified, it can already be realized little by little. When discussing the completion of the design document with the team, I did not focus on the details. All that needed to be added to this document answered the question: “what?”. If designers asked me “what should be the color of the interface element” - I simply answered “Do your best”. If I asked myself the question: how should monsters fight each other, how should they communicate with the rest of the code - I answered “somehow, if only it worked”. Needless to say, the issue of architecture planning has not even been raised?

The reason for this detachment is very simple. No matter how perfect your code is, no matter how much it complies with standards, and whatever complex programming patterns it implements, the end user will not see them . It is important for the user that the program does not crash and does not slow down. And if in the process of the main workflow the user does not catch a single exception, if he passes your game in one breath - he will not remember that he failed in the texture at the third level or the enemy somehow attacked him in the fifth way. In fact, you need to take the user’s hand and show him all the interesting places of your product, carefully avoiding those that may cause problems. The converse is also true: it is best to focus on those parts of the code that the user will most likely turn to.

Do not overdo it

However, fanaticism is harmful even in such a useful development method as ignoring specifics. There are several bottlenecks that you should spend a little precious time on. For example, when a monotonous work is ahead, especially if you don’t have to do it. To describe the problem that cost our team the loss of a designer halfway, we need to make a small digression and explain the essence of programming graphics in Flash.

Initially, flash was designed to play and easily control a variety of animations. ActionScript of the third version is quite an object-oriented event-driven language, but earlier in flash applications few people used classes and generally separate files. All the code was usually called not by some user actions, an internal timer or communication with the server, but simply by the entrance to a certain frame of animation. Flash developers even have their own historical shortcut: “code in frames”, which usually means the way a beginner encoder works. The code in the frames as such and the so-called principle of “programming with the mouse” usually lead to the fact that it becomes quite difficult to fix the noticed error. If this error is typical and is present in several animations at once, the error correction time grows in direct proportion. You won’t be able to do a search-and-replacement - you must manually go into each animation and manually fix it.

In our game, it was originally planned to implement animations for thirty-nine types of monsters, each with four actions. Start and stop animations are made by the code upon the occurrence of some in-game events. Due to the fact that the animator was not immediately provided with a template to which all these animations should correspond - a minor but very noticeable error to the player crept into more than half of the animations. I had to fix everything together, a lot of time was spent, the designers quarreled and one of them refused to continue working.

Another point that deserves to be worked out is the interface of the beginning and end of each of the separate blocks of code. For a team with more than one programmer, this rule becomes even more important. Unambiguous and strong bridges of challenge and completion should be thrown across the border of the zones of responsibility of each of them. Strictly speaking, under certain conditions, the second programmer can become the only one when he returns to the old code after a long time. Therefore, if you do not plan to finish work on the code block from the first call, it would be better to take care of the presence of such an interface.

Completion, release path

When the development time comes to an end, and the project comes to its first release, the ability to come to terms with the idea that not all planned features can enter the first release will be very useful. The sooner you come to terms, the faster you can start cutting the fichelist. If you yourself wrote a design document for yourself, to make it simple is simple: take all the unrealized functionality and put it in line with the first sentence "This will be a project about ...". If a feature is not logically connected with it, you can throw it away without regrets. If the implementation list still remains quite long - sort it by priority of execution speed, not paying attention to the importance of functionality for the project itself. Even if the functionality was very important - it's too late to think about it before the release. Moreover, the more important you miss - the more motivation you will have for the early release of the patch. For example, an arsenal of weapons was thrown out of our game without special regret, the animation of which would have had to be drawn to the designer for a long time and the priority of the problem of the lack of music in the game was sharply reduced in favor of adding two additional slide show endings.

If there is really little time left, you can not even pay attention to most non-critical bugs: only those that break the main workflow of the program should be fixed. So, for example, in the first release of our game there was a bug with the infinity of the battle of monsters, who sorted out the relationship at the moment they hit it with a slipper. But I still have time to remove the error with double sending messages about the monster’s death, imperceptible, but significantly increasing the load on the processor. Again, you don’t need to completely ignore such bugs, it’s better to transfer them to the first patch. As my computer science teacher said: sometimes it’s better to have ten errors in the program than one. Especially when those ten are syntactic and one is “the program does not work.” Projects of the first type have long been making money and can afford to spend it on support and release of patches,

Post-release. Patches and refactoring

And now, this moment has finally come. You have released the project. This and only this is the main thing. You received congratulations, or catch up - it does not matter. You have a finished project. A little buggy, a little simpler than planned, but ready. Now you can relax after the race with time and finally start refactoring. Right now, and not a minute earlier, you can sit down and think about how best to connect the code to yourself so that it is easier to maintain it. If you realize that the project has moved from the development stage to the support stage, it will become much easier to work on the project. When you look at the list of missed releases, bugs will run before your greatness, and unrealized features themselves will fall into place, with just a little of your help. All this time you endured and delved into your own shit, beat your hands and stopped,

And you already know how to do the next project.

PS: I wanted to publish this text a month ago. But it so happened that right after the announcement of the winners of the OLD48 and the award, the wonderful AnnieOmsk approached me and offered to tell me about the difficulties that I had to face during the development at the HappyDev'12 conference . All I wanted then was to fall off somewhere and fall asleep soon, therefore I couldn’t refuse her. The next three weeks I was terribly worried, I did not know whether it was worth going and speaking in front of a huge audience for me (this would be my first such experience). But in the end, everything worked out and I'm even glad that I received additional motivation to write this report.

PPS:If someone is eager to play our game: follow the link . If someone is really interested: on the next link you can find slides to my presentation