The story from the Russian A (AA) -indi gamedev on one example
Under the cut, you will find a large and full of graphics story, how a group of interested people for 2 years created an AAA-level indie project (in their opinion)
Here I am completely old-fashioned and can’t stand the rottenness that attracts game lovers with rotten meat, moldy cheese, spoiled people and ugly deeds. For me, any work of art, whether it be a book, film or painting, does not exist if it does not have a deeply felt nature, beautiful women and valiant men ...
I. Efremov, Razor Blade
Instead of joining
What do you like to do when you spend time with friends? Table games? Sport? Creating a revolutionary startup where you need to upload your photos with filters to a common feed? My friends and I went through all this, I wanted something new, fresh, which none of us had done before (away from hussar jokes). It turned out that game dev is exactly the new and fresh thing everyone wanted.
Only one of us played games regularly, and he told the rest about the popular map for Warcraft 3, which is called Legion TD. Of course, a powerful analogy with DotA worked - the game also started as a map for Warcraft, but then it was redone as an independent product, very successful. With the Legion, a similar situation is a very popular map, it has fan sites and tournaments, but people still play the map of a game made in 2003. It seems that independent play is simply doomed to success.
Youtube video with gameplay of the original game.
By that time, I had experience in a rapidly growing company, where modern Agile practices were actively applied and I proposed to project them on our project. We agreed to work on the game with weekly iterations, setting up tasks for the current iteration at the beginning of the week and conducting demos at the end. As a demo, we chose the format of the game - we have to play our game, use the new features added during the iteration. Thus, we always maintain the game in working condition, plus we see progress with our own eyes.
So in January 2015, we started developing our game.
A bit about game mechanics
The game has a rather unusual genre - multiplayer tower defense.
The playing field consists of two parts - western and eastern. The team of the west side (at least 1 player) plays against the east. Between them is the arena (more on that later):
The playing field
One side consists of four slots (that is, a maximum of 4x4 games is possible). Each player builds defender units in his slot, and wave units attack from the side of the gate (marked in red):
Map of the game side
The game consists of phases and starts from the construction phase:
After the construction phase is completed, a wave appears and the units automatically fight (here player not involved):
Bursting units of the wave go the shortest route to the king (King slot). If player 1 was unable to fight back (“leaked”), and player 2 was beaten off, then his units teleport to the king and protect him:
King’s slot into which the wave units entered The
peculiarity is that players can not only build defensive units, but also send attacking units to the enemy. And here you have to catch the balance of resources in order to defend yourself and attack the enemy. This gives rise to a large number of strategies (to go off the beaten path and wait for the late waves, accumulate resources and demolish the enemy at once, etc.) - for this, the players choose which guild they play for (the guild determines the set of creatures available to the player for purchase)
We split up: two took up the server and two took over the client. Since there was a requirement to play the game every week, it was necessary to assemble a minimally working version as soon as possible. We started to write a server in python, on it we made a primitive console client:
The first game client. The state of the game world is displayed in the form of a dictionary above, the units built (Q letters).
The first features of our server we tested on this console client, but pretty quickly came to the conclusion that we should immediately focus on a normal graphical client. We built it on Unity, and for models we used free assets from the Unity Asset Store:
The first version of the graphical game client on Unity
Such a client already allowed to build units with a much finer grid, observe their various states (attack, walking), and see if they move correctly.
In the end, in the comments on Habré we met with the interface designer, who was interested in our project and he decided to practice the design of game interfaces.
So the first months of development passed.
The designer famously got down to business and quickly drew us a new interface (“dashboard”, as we later called it):
The second version of the game interface
We decided that this interface was enough to test the game without gagging and started working on the appearance of game creatures . None of us had experience in designing game graphics, so we started with sketches. Not only our designer participated here, but also friends, acquaintances, and in general everyone who wants to join the domestic indie gamedev. First character sketches: goblin in armor, orc and goblin mechanic.
We sketched the first guild we called Warfactory and started thinking about how to get creature models. By that time, we were already widely known in narrow circles and Oleg, a 3D-modeler from Ukraine, who was interested in participating in the project, contacted us. He also started to create the first models, and 6 people became in our team: One of the first 3D units of his own was the “plate”. It is still one of my favorite units in the game. The process of working on the orc (Orc Bruiser) We began to actively engage in the development of our own graphics, units and maps. Since the free models in the Unity Asset Store were not of very high quality, we decided that in a couple of months we could make our own graphics.
Screenshot of the game of that time. The game has already added our own interface, and on the left you can see the same "plate".
The screenshot shows that the most unpretentious (in addition to everything else) is a flat green card with rectangular gray walls. We decided to devote some time to level design and make a beautiful map. Some elements of work on map objects
Work on the map dragged on and we came to the conclusion that the problem is a lack of human resources. We threw a cry for thematic groups and pretty quickly found guys who were interested in participating in the team - texture designers, modelers and animators. Thus, the team has grown from 6 people to 12, but we began to work on several areas at once. At the same time, several units were sketched, a map and a new guild (Order of Dragon) were designed.
This is the period of the most active work on the project. We called up the whole team once a week, highlighted the task block for the server, client, sketches, models and textures, knocked down the results of the past week and at the end of the meeting played our game. Gradually, our own graphics appeared in the client and this additionally motivated.
We also agreed that the first interface was unsuitable for anything and made the second version of the interface:
Appearance of the game, when we were actively working on the development of the map and game models
Work on the map dragged on for a long time, the originally named period of 2 months resulted in almost year of work. As a result, we made a strong-willed decision to drop work on everything else and finish the map to the final state.
Appearance of the card, which we considered for some time the final state.
Appearance of the game side (view from the editor)
In the spring of 2016, we launched the promised closed beta test, to which the first players were invited (very little in total). Here we have prepared such a video for closed beta:
The video prepared by us for the first closed beta test.
The fourth period
Long and monotonous work without tangible results is tiring. By about the summer of 2016, it became clear that productivity had fallen, the team was tired and needed a clear goal. As such a goal, we chose the launch of Greenlight to show the game to the community and get people to run the beta test. Initially, we planned to launch Greenlight in November, but the preparation of graphics, a promotional video and small fixes was very delayed, as a result, we are going to the green light only now.
For Greenlight, we further improved the visual component of the map, completely completed 2 guilds (Warfactory and Order of Dragon), and also prepared a special video (you can also watch it on our page in Greenlight):
The video that we specially prepared for the launch of Greenlight
I suggest you look at some fresh screenshots from the game in order to give an impression of what it looks like now (especially in comparison with how it looked initially): Fresh screenshots of the game
A bit about tools
From the very beginning we tried to adhere to Scrum, followed all the basic procedures: formed a backlog, carried out iteration planning, at the end of the iteration a demo and a retrospective.
We took Trello as a board and for some time, happiness knew no bounds. But with the growth of the team, it turned out that not every member of the team is ready to keep their tickets up to date, outweigh the tasks in “At Work” and “Ready”. For a while I tried to do it for them, but it seemed like it was terribly inefficient.
First of all, as a substitute for Trello, we tried the team forum. Every week a plan for iteration was published, at the end of the week we checked what tasks were done and for what delay. This scheme is simpler than Trello, it is much easier to maintain, but it is difficult to keep track of who delays the execution of their tasks or misses meetings.
The third tool we went to is a table in Google Docs A
screenshot of our table for the period from June to November
Such a table allows you to track finished tasks and failed ones (marked in black). We marked yellow tasks done late. Color marking of table columns - different directions of development (server, client, UI, graphics). A quick look at the table is enough to see which directions are skidding, which team often misses deadlines, and who, on the contrary, approaches responsibly. This format was the most successful. As a cherry on the cake - a history of file changes to track errors and find who “wins the points” for themselves (several team members have access to editing the table).
Many interesting points are omitted in my story: how we fought with network interaction and how we eventually implemented it. How we fought for server performance and completely rewrote it from Python to Go, how we optimized the client and added graphic effects there. We can tell all this in our future articles. In the meantime, sign up for beta, leave feedback and vote for us on our page in Greenlight!