Why sometimes you have to beat your hands?

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 cannot complete their first project. Some freelancers have similar difficulties - they don’t always have to complete a project on time.

These problems have a common rather trivial solution. But no one dares to abandon the ideality of their code, and instead of getting a complete project, they usually make a dream project.
')
A month ago, our team of one and a half designers and one and a half coders took the first place in the regional championship in high-speed game development. The development was given only 48 hours. Two days, consisting entirely of coffee and nerves, gave the result of the most complete of the competition's projects. I will tell you what I had to do with myself and with my desire to write the perfect code, which is not scary to show people.



If you talk distantly - 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 their logical completeness and relevance to the topics. Very much depended on the conditions of the competition. Immediately make a reservation: 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 contractor. There were also complicated versions of the rules according to which one person had to participate in the competition and at the end to provide all the source codes, but our organizers refused them. In any case, I chose pure ActionScript without any engines.

Work without TZ. Preparatory stage

The competition began at eight in the evening on Friday. From this point on, it was possible to start doing something already - to draw the basic design blanks, write basic code modules, invent a game concept. However, the theme of the game all the teams received only in the morning, common to all and previously unknown. Initially, only an array of 25 possible topics was known, of which, by eight o'clock in the morning on Saturday, a very unexpected “Evolution” was chosen for everyone. Here our first problem manifested itself, having solved which we caught the very wave of breakup that allowed us to finish the game in time.

Friday night we spent on the game engine, suitable for 20 of 25 topics. We missed very different moments, hoping that by the next day we would just push the ready-made engine for any topic. When we learned that the topic was included in those five unreported ones, 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 what we will do, is very important, and it is always and for everyone. In freelancers - when they took the order, but the customer is not in a hurry with the technical order; Enterprise enterprises that have software production put on stream have a core that they grow and debug all the time off orders; indie has a moment when the design document is not yet verified, and it’s already itching to write at least something. At this moment it is best to do things that are truly common to all projects. For example, in all games you need a timer - make the timer universal, calibrated to the millimeter, with a convenient launch and calling 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 interface sketches. I would save myself a lot of nerves if I had written the message engine from the keyboard and mouse for those eight hours of the first day, which would have turned the character's engine of movement that would turn out to be useless.

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

On Saturday morning, we went to the office with the designer to urgently come up with a game that would fit an unexpected topic. Here we must digress and note that our team was called “ Who cares? "That in free censorship translation may mean:" And who cares at all? ". We stood at the project board and looked at it without a single thought in my head, until one of us said: “Who cares about evolution at all? Who needs complex games with a ramified plot, especially those built in two days? ” It was decided to make a very simple game with a primitive gameplay, built on a pure fan. The essence of the game was proclaimed a bored deity, who decided to disprove the theory of evolution in practice, using his divine sneaker 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), but I wrote a design document.

At first there was only one sentence in dizdok: "This is a game about breaking the laws of evolution by a divine sneaker." Over the course of two days, the dizdok was replenished with new and new features, but none of them contradicted the original statement. The beauty of this wording is that it allows you to start work immediately, without thinking over the details for several hours. It gives an unequivocal answer to the question “what to do?” Without bothering about conventions, like: “how exactly to do?”. The best option would be if at least the first time there are no questions like "how?". The task is, it is formulated and, although not specified, it can already be gradually implemented. Discussing the replenishment 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 the designers asked me “what should the color of the interface element be,” I answered simply “Do your best”. If I asked myself the question: how should the monsters fight with each other, how should they communicate with the rest of the code - answered “somehow, as long as it worked”. Needless to say that the issue of planning architecture has not even been raised?

The reason for this detachment is quite simple. No matter how perfect your code is, how much it conforms to standards, and no matter how complex programming patterns it implements - the end user will not see them . For the user, it is important that the program does not fall and does not slow down. And if during 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 textures on the third level or on the fifth he was somehow not so attacked by the enemy. In fact, the user must take the handle and show him all the interesting places of your product, carefully avoiding those that can cause problems. The reverse is also true: it is best to focus attention on those parts of the code to which the user will most likely turn.

Do not overdo it

However, fanaticism is harmful even in such a useful development method as ignoring the specifics. There are several bottlenecks, which are still worth spending some precious time to work through. For example, when there is a monotonous monotonous work, 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 intended for playing and simple control of various animations. ActionScript third version is quite an object-oriented event-driven language, but earlier in flash applications few people used classes and generally separate files. All code was usually caused not by some user actions, an internal timer or by communicating with the server, but simply upon entering a specific frame of animation. Flash developers even have their own historical label: “code in frames”, which usually means the way the novice coder works. The code in the frames as such and the so-called principle of “programming with a mouse” usually lead to the fact that it becomes rather difficult to correct the noticed error. If this error is typical and is present in several animations at once, the time to correct the error grows in direct proportion. Search and substitute will not work out - you have to manually go into each animation and manually fix it.

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

Another point that deserves elaboration 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. Across the boundary of each area of ​​responsibility, unambiguous and strong call and end bridges should be prokinut. Strictly speaking, under some conditions, the second programmer can become the only one when it returns to the old code after a long time. Therefore, if you do not plan to finish the work on the code block from the first approach, it would be better to attend to the presence of such an interface.

Completion of development, release path

When development time comes to an end, and the project - to its first release, the ability to come to terms with the idea that not all the planned features can enter the first release will be very useful. The sooner you reconcile, the sooner you can begin to cut a featuremaker. If you yourself wrote a design document for yourself, make it simple: take all the unrealized functionality and put it in accordance with the first sentence “This will be a project about ...”. If the feature is logically unrelated to it - you can throw it away without regrets. If the list for implementation still remains long enough - sort it in 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 an early release of the patch. For example, an arsenal of weapons was thrown out of our game without much regret, the animation of which would have had to be long drawn by the designer and the priority of the lack of music in the game was lowered in favor of adding two additional end slideshows.

If there is really little time left, you can even ignore the majority of non-critical bugs: only those that break the main workflow of the program are worth fixing. So, for example, in the first release of our game, there was a bug with the infinity of the battle of the monsters who were sorting out the relationship when they were hit by a sneak. But I still have time to remove the error with the double mailing of the monster's death message, imperceptible, but significantly increasing the CPU load. Again, it is not necessary to completely ignore such bugs, it is better to transfer their fixes to the first patch. As my teacher of computer science used to say: sometimes it is better to have ten errors in a program than one. Especially when those ten are syntactic, and one is “the program does not work.” Projects of the first type have been earning money for a long time and can afford to spend it on support and release of patches, while no one uses the latter.

Postrelease. Patches and refactoring

And now, this moment has finally come. You have released a project. This is the only thing that matters. You have received congratulations, or scolding - it does not matter. You have a finished project. Slightly zagagovany, slightly more simple than planned, but ready. Now you can relax after the race with time and finally start refactoring. Right now, and not a minute before you can sit down and think about how best to link the code with yourself, to make it easier to maintain. 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 those not in the release, the bugs will scatter in front of your greatness, and the unrealized features will fall into place themselves, with only a small amount of your help. All this time you endured and dug in your own govnokode, beat your hands and stopped when you wanted to urgently put the code in its place: now you can afford it and finally start the patches.

And how to do the next project - you already know.

PS: I wanted to publish this text a month ago. But it so happened that immediately after the announcement of the winners of the OLD48 and the award ceremony, a great AnnieOmsk approached me and offered to talk about the difficulties that had to be encountered during the development at the HappyDev'12 conference. All I wanted then was to quickly fall somewhere and fall asleep, so I could not refuse her. For the next three weeks, I was terribly worried, I didn’t know if I should go and speak in front of a huge audience for me (this would be my first such experience). But in the end, everything worked out and I am even glad that I received additional motivation to write this report.

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