Online game: howto, or how I lost a girl programmer

Not a few stories about how small groups of developers have achieved success. And even more about how these developments have failed. But here I want to tell exactly about the evolution of the online game development process, based on my experience. I will make a reservation in advance: this is my first experience in developing a massive online game.
It all started quite intriguing. I had the inaccuracy to argue with a familiar web-programmer about who will make the web-project faster and more qualitatively among us. In order not to be very dispersed and not to spend a lot of time, we decided that we will be given only one week, and we will develop a multiplayer game!

At the end of this period, the projects were handed over to the “appraisal commission,” which were our mutual friends. And ... My project did not win. And the most offensive at that moment seemed to be that, under the terms of the dispute, I had to set aside one more week of working time to help my opponent develop her game. But a dispute is an argument!

The beginning of time

What did we have at the time of the joint development? Yes, almost nothing! Concept in the head and some source code. Plus, the "team", which consisted of two people. Programming engaged Marina. I started developing the user interface.
')
My week of "slavery" was very fast and interesting. Bugs were fixed, and several new features were implemented. This ended the week, and I could wash my hands, but ... the project turned out to be really interesting, and we decided to continue its development.

The basic installation was - as soon as possible to make the first workable version. Dates were again chosen hard: 1 month. And this is taking into account that we were engaged in the game only in our free time, being in different parts of the city and communicating only on ICQ and Skype.

1 week - concept

To begin with, it was decided to start by putting the whole concept on paper. This is what saved us in the future from big mistakes.

What was the concept? Just a set of phrases and sentences (“thoughts out loud”) in which only we, probably, could see the meaning. But, despite this, all the main points in it were outlined, and the potential for the development of the project was laid. At this first week came to an end.

2 week - start of work, first mistakes

I wanted to work on the project and it worked. Files with updates often exchanged on soap and ICQ. Old versions of the code and psd-shki with graphics were deleted and copied, as if there were no evenings spent on them.

Each house had its own server configured, where the work was done. Why was this working principle chosen? Everything is very simple - the deadlines were set very tight for themselves, and I wanted to do a lot, so we decided not to waste time on the useless configuration of a common server and other synchronization of work. Only one thing was sitting in my head: “there are only 3 weeks left ... and also time to spend when it is not there”.
But by the end of the week we howled and decided to do everything the way we would have done right away.

3 week - subversion and refactoring

The installation of subversion and the storage of the project in it greatly facilitated our lives. Now it was not necessary to spend a lot of time to merge the accumulated. It was always possible to check the latest version of the project. And, most importantly, it was possible to roll back to the early version. This, too, then “saved life” to us more than once. Looking back, I wondered how we could do anything at all without a version control system.

Also, one of the volitional decisions was to refactor despite the fact that there was less and less time left.
For example, at the beginning, the game map was controlled using the navigation arrows (discretely), and the display of parts of the game world took place in long strides.

Later, such an approach was abandoned in favor of dragging a card by grabbing it with a mouse (drag-n-drop). At the same time, we were too lazy to refactor the code responsible for this function. This led to the fact that the functionality designed for one task and well performing its role, on another task, began to overgrow with various “dopils”, and at the same time errors. In the resulting mess to make the most elementary changes had to fix quite a lot of code.
And after this code was almost completely rewritten, it became 70% smaller, while performing significantly more tasks.

4 week - the first taken line

For the rest of the week, before the expiration of the deadlines, they completed almost everything they wanted. Something did not have time, somewhere done too much. But, despite the fact that decisions about the implementation of a particular functionality were taken on an intuitive level, the choice was almost always the right one. Our first testers appreciated the changes made.

Closed testing has shown that not everything is perfectly done and that the online game is more raw than ready to be shown to people. The interface was practically absent, it was extremely difficult and not intuitive to control the gameplay. But at the same time there was a great potential in development, and our testers liked the game process. Therefore, it was decided not to stop at what has been accomplished.

5-7 weeks - tudulists and a lot of work

Having collected wishes and error reports, we started sorting and prioritizing them. All this happened in the format of a brainstorm, and all conclusions were recorded on stickers. This whole process took us all weekends. The result was a mountain of stickers. The ideologists of agile development say that you need to take a board, divide it into areas and hang everything there. But this option did not suit us - we worked in different parts of the city, and I wanted to see the completion of the tasks in real time.

At first they turned to specialized online services that were supposed to help in joint work. After trying many, they were convinced that all of them do not suit us. Some were oversaturated with functionality, in others we lacked something else, some were paid.

In the end, we abandoned the services in favor of googledocs. Having adjusted the highlighting of the required columns, we got a very convenient todo-list.

It was here that the main work began to boil. Tasks are actively closed. Now we have seen progress, excitement has appeared. And from this, the speed of development has increased markedly.

At this stage, we are faced with one ideological error: we formulated several large, not specified tasks.
One of them had the following wording: “Reverse all dialog boxes”. Now such a formulation of the problem seems wild to us, and it’s not a similar task, but then it was all different. Because of this vague formulation, the task was not closed for a month and a half.

It would be correct to break the task down into subtasks. For example, such as “Roll up a table in a rating”, “Stylize buttons in settings”, “Roll up inventory in a player's infe”, etc. And the specifics of the game interface would never allow the initial task to be sent to the list of completed ones (new dialog boxes appeared with enviable regularity).

Also, thanks to testers, we received many new requests for the implementation of one or another functional. I remembered the very beginning of the work and the fact that it was not for nothing that we had a single concept outlined on paper. It was decided to deny themselves strong deviations from the concept. Following this not difficult rule, we gave ourselves the opportunity to remain within the established time frame and did not lose the integrity of the gameplay.

The month was not in vain - a lot was finalized. Testing has passed with much greater success.

8 week - Pareto principle, many results

I think you should not talk about the 80/20 rule , which you probably already heard about. I'll tell you only about how we encountered this problem, and how we struggled with undesirable 20% of the result.

At this point, testers demanded from us a chat, a variety of game landscape, and a notification about the beginning and end of all game actions.

Chat. Everything is simple here. It was decided to divide the work into two phases - 80/20. Initially, a regular chat was made where you could send messages. Simple and fast: 40 lines of server code and a dozen client. Things like private and private messages, ban, etc. were put off until later.

Game landscape. For a long time we pulled this task. Oh, how we did not want to take on her! Thought it was a useless feature. But we were persuaded and, reluctantly, we sat down and did it ... in a few hours. Here we realized that we were very wrong - the effect was above all our expectations. You can compare for yourself how it looked defective "before", and how much it became more pleasant to the eye "after."

Alerts. How much we did not think, we could not figure out how to do it in a hurry. Try, go over the whole code and double-check whether any action of the player tells him what he has done. Here, of course, we ourselves were to blame for not doing it as the code was being written. But there was nothing left but to postpone this task indefinitely.

The result of the week was that we had a useful 80%, and the remaining 20% ​​were postponed until later.

Week 9 - Pareto principle, few results

The beginning of the week was difficult. We "hung" tasks that were included in 20% of the results. But what to do ... And here we made an unexpected, but very pleasant discovery. It turns out that our tasks were divided equally between the two developers, while not intersecting. This made it possible to complete the implementation of tasks without distracting each other from work.

We also took into account this experience. Later we acted as follows: implemented tasks related to 80% of the result, while trying to capture the maximum of the intersecting functional. And later they arranged “boring” weeks, when everyone, without distracting their partner, completed the tasks they started.

10-13 weeks - a lot of nasty bugs

It is time to prepare a project for release. The mountain is difficult to find and rarely manifest errors, minor flaws in the original concept. In general, instead of the four days planned for preparation, we were completely stuck for three weeks. A lot of code was rewritten, which remained from the first weeks of work and was constantly tightened with “crutches”. It was at this stage that we cursed the fact that almost no refactoring was performed.

In turn, regression errors made us understand that writing automated tests makes life a lot easier. But this is the next step.

Findings:

1) If the project will contain more than one hundred lines of code - have the formulated concept. If there are more than 1000 lines of code, have a recorded concept.
2) Do not be afraid to change the concept, but do not abuse it. Leaving everything as it is, you risk "not falling into the stream." Otherwise, you never finish your project.
3) Do not be lazy to use version control systems, even if you think that the project will fit into 100 lines of code.
4) Do not be afraid to refactor, even if it seems to you that the product will be finished tomorrow and will not require support.
5) Break large tasks into smaller, tangible ones. They are more interesting and more productively executed.
6) Do not forget to write regression tests.
7) Do not argue with girls even about programming. Especially, if you think that programmers are bad :)

The server temporarily went down, were not ready for this.
Returned to life.

And finally, our programmer at work :)