Online game: howto, or how I argued with a girl programmer

    There were many stories about how small development teams succeeded. And even more about how these developments failed. But here I want to talk specifically 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 very intriguingly. I was inaccurate to argue with a familiar web programmer about who would make a web project faster and better. In order not to spray too much and not spend much time, we decided that we would be given only one week, and we will develop a multiplayer game!

    After this period, the projects were handed over to the “evaluation committee”, which was our mutual friends. And ... My project did not win. And the most offensive at that time seemed that, according to the conditions of the dispute, I had to allocate another week of working time to help my opponent in the development of her game. But an argument is an argument!


    The beginning of time


    What did we have at the beginning of the joint development? Yes, almost nothing! Concept in the head and a bit of source code. Plus, a “team” of two people. Programming was done by 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 main installation was to make the first workable version as quickly as possible. The deadlines were again chosen hard: 1 month. And this is due to the fact 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 presenting the whole concept on paper. This saved us in the future from big mistakes.

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

    2 week - start of work, first mistakes


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

    Each house had its own server configured, where work was done. Why was this principle of work chosen? Everything is very simple - the deadlines set for ourselves are very short, but I wanted to do a lot, so we decided not to waste time on the useless, as it seemed to us then, setting up a shared server and other synchronization of work. There was only one thing in my head: "there are only 3 weeks left ... more time to spend when it is not there."
    But by the end of the week we howled and decided to do everything as it should be done right away.

    3 week - subversion and refactoring


    Installing subversion and storing the project in it greatly facilitated our lives. Now I did not have to spend a lot of time on the merger of the accumulated. There was always the opportunity to check the latest version of the project. And, most importantly, there was an opportunity to roll back to an earlier version. This, too, later on saved us more than once. Looking back, I wonder how we could do anything without a version control system.

    Also, one of the strong-willed 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 portions of the game world were displayed in pieces with a large step.

    Later, such an approach was abandoned in favor of dragging the map by grabbing with the 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 intended for one task and well fulfilling its role, on the other task began to acquire various “dopils”, and at the same time errors. In the resulting mess, to make the most elementary changes, I 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 weeks - the first line taken


    For the rest of the week, before the deadlines expired, we completed almost everything we wanted. Something did not have time, somewhere did too much. But, despite the fact that decisions on the implementation of a particular functionality were made at an intuitive level, the choice almost always turned out to be the right one. Our first testers appreciated the changes introduced.

    Closed testing showed that not everything was perfectly done and that the online game is more raw than ready to be shown to people. There was practically no interface; managing the gameplay was extremely difficult and not intuitive. But at the same time, great development potential was visible, and our testers liked the gameplay. Therefore, it was decided not to stop there.

    5-7 weeks - tudulists and a lot of work


    Having collected wishes and bug reports, we started sorting and prioritizing them. All this happened in a brainstorm format, and all conclusions were recorded on stickers. The whole process took us all weekend. 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 - they worked in different parts of the city, and I wanted to see the completion of tasks in real time.

    First, they turned to specialized online services that were supposed to help in collaboration. Having tried many, we were convinced that they all do not suit us. Some were oversaturated with functionality, while others, on the contrary, were missing something, others were paid.

    In the end, we abandoned the services in favor of googledocs. By adjusting the highlighting of the desired columns, we got a very convenient todo-list.

    This is where the main work began to boil. Tasks were actively closed. Now we have seen progress, excitement has appeared. And from this, the development speed has increased markedly.

    At this stage, we encountered one ideological mistake: we formulated several large, unspecified tasks.
    One of them had the following wording: “Revert all dialog boxes”. Now this formulation of the task seems to us wild, and it doesn’t look like a task, but then everything was different. Due to this vague wording, the task was not closed for a month and a half.

    It would be correct to break the task into subtasks. For example, such as: “Make up the table in the ranking”, “Stylize the buttons in the settings”, “Make up the inventory in the player’s infa”, etc. And the specifics of the game interface would never allow sending the original task to the list of completed ones (new dialog boxes appeared with enviable regularity).

    Also, with the easy hands of testers, we received many new requests for the implementation of a particular functional. I recalled the very beginning of the work and the fact that it was not in vain that we had a single concept, outlined on paper. It was decided to deny myself strong deviations from the concept. Following this not difficult rule, we gave ourselves the opportunity to stay within the established time frames and did not lose the integrity of the gameplay.

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

    8th week - Paretto principle, many results


    I think you should not talk about the 80/20 rule , which you probably already heard about. I’ll only tell you how we ran into this problem, and how we fought against objectionable 20% of the result.

    At this point, testers demanded that we chat, a variety of game terrain, 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 code. Things like private and private messages, ban, etc. were postponed for later.

    Game landscape. For a long time we pulled with this task. Oh, how we did not want to take it! Thought it was a useless feature. But we were convinced and, reluctantly, we sat down and did it ... in a few hours. Here we realized that we were greatly mistaken - the effect was above all our expectations. You yourself can compare how flawed it looked “before”, and how much it became more pleasant to the eye “after”.

    Alerts. No matter how much we thought, we could not figure out how to do it in haste. Try it, go through the entire code and double-check if any player action tells him what he has done. Here, of course, we ourselves were to blame for not doing this as we wrote the code. But there was nothing left but to put off this task in the long box.

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

    Week 9 - Paretto principle, few results


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

    We also took this experience into account. In the future, we acted as follows: we implemented tasks related to 80% of the result, while trying to capture the maximum intersecting functionality. And in the future, they organized “boring” weeks, when everyone, without distracting a partner, completed the tasks begun.

    10-13 weeks - a lot of nasty bugs



    It is time to prepare the project for release. A mountain of hard to find and rarely manifested errors, minor flaws in the original concept. In general, instead of the four days planned for preparation, we got bogged down for three weeks. A lot of code was rewritten, which remained from the first weeks of work and was constantly twisted with “crutches”. It was at this stage that we cursed that virtually no refactoring was done.

    In turn, regression errors made it clear to us that writing automated tests makes life easier. But this is the next step.

    Conclusions:


    1) If the project will contain more than one hundred lines of code - have a formulated concept. If more than 1000 lines of code - have a written concept.
    2) Do not be afraid to change the concept, but do not abuse it. Leaving everything as it is, you risk "not getting into the stream." Otherwise, you will 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 productive.
    6) Do not forget to write regression tests.
    7) Do not argue with girls even about programming. Moreover, if it seems to you that the programmers are bad :)

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

    And finally, our programmer, at work :)

    Also popular now: