The story of the Russian A (AA) -indi gamedev on one example
Under the cat you will find a large and full of graphics history, as a group of interested people for 2 years created an indie project of AAA level (in their opinion)
Here I am completely old-fashioned and can’t stand rotten, attracting lovers of game with a stuffy, moldy cheese, spoiled people and ugly actions. For me, any work of art, be it a book, a film or a painting, does not exist if there is no deeply felt nature, beautiful women and valiant men in it ...
I. Efremov, razor blade
')
Instead of intro
What do you like to do when you spend time with friends? Board games? Sport? Creating a revolutionary start-up where you need to upload your photos with filters to a common tape? 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 gamedev is exactly the new and fresh thing that everyone wanted.
Only one of us regularly played games, and he told the others about the popular map for Warcraft 3, which is called Legion TD. Of course, a powerful analogy with DotA worked - the game also began as a Warcraft card, but then was converted into a standalone product, very successful. With the Legion, a similar situation is a very popular card, there are fan sites and tournaments, but people still play the map of the game made in 2003. It seems, an independent game is simply doomed to success.
Youtube-video with the gameplay of the original game.
By that time, I had experience in a fast-growing company, where modern Agile practices were actively used and I suggested projecting them onto our project. We agreed to work on the game weekly iterations, composing tasks for the current iteration at the beginning of the week and conducting a demo at the end. As a demo, we chose the format of the game - we have to play our game, take advantage of 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 little about the game mechanics
The game has a rather unusual genre - multiplayer tower defense.
The playing field consists of two parts - western and eastern. The west side team (minimum 1 player) plays against the east side. Between them is the arena (more on that later):
Playing field
One side consists of four slots (i.e. a maximum of 4x4 is possible). Each player builds defender units in his own slot, and wave units attack from the goal side (marked in red):
Gaming side card
The game consists of phases and begins with the construction phase:
Construction phase
After the end of the construction phase, a wave appears and the units automatically fight (here the player does not participate):
Wave phase
Breaking wave units go the shortest route to the king (King slot). If player 1 failed to fight back (“lost”), and player 2 fought off, his units teleport to the king and protect him:
King's slot where wave units enter
The peculiarity is that players can not only build defender units, but also send attacking units to the enemy. And then you have to catch the balance of resources to defend yourself and attack the enemy. This gives rise to a large number of strategies (to go into a dull defense and wait for the late waves, save resources and demolish the enemy at once, etc.) - for this, players choose which guild they play for (the guild determines the set of creatures available to the player for purchase)
First period
We were divided: two took up the server and two for the client. Since there was a requirement to play the game every week, it was necessary to assemble the minimum working version as soon as possible. We started writing a server on python, and we made a primitive console client on it:
The first game client.From above, the state of the game world is displayed in the form of a dictionary, below - built units (letters Q)
We tested the first features of our server on this console client, but rather quickly came to the conclusion that we had to immediately focus on a normal graphical client. We collected 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 smaller grid, to observe their various states (attack, walking), to see if they moved correctly.
The designer famously took up the matter and rather quickly rendered us a new interface (“torpedo”, as we later called it):
The second version of the game interface
We decided that there was enough of such an interface to test the game without gagging urges and set about developing the look of the game creatures. None of us had any experience designing game graphics, so we started with sketches. Here participated not only our designer, but also friends, acquaintances and, in general, everyone who wanted to join the domestic indie gamedev.
The first sketches of characters: a goblin in armor, an orc, and a goblin mechanic.
We scored sketches for the first guild, which we called Warfactory, and began to think 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 got interested in participating in the project, contacted us. He also began to create the first models, and in our team became 6 people:
One of the first own 3D units is the “plate”.So far, 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 its own graphics, units and maps. Since the free models were not of very high quality at the Unity Asset Store, we decided that in a couple of months we could make our own graphics.
Screenshot game of the time.The game has already added our own interface, and on the left you can see the very “plate”.
The screenshot shows that the most indifferent (among other things) is a flat green map 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 concluded that the problem is a lack of human resources. We threw a cry by thematic groups and rather quickly found guys who were interested in participating in the team - texture makers, modelers and animators. Thus, the team has grown from 6 people to 12, but we started working on several areas at once. At the same time, several units were skipped, a map and a new guild (Order of Dragon) were designed.
Third period
This is the period of the most active work on the project. We called the whole team once a week, singled out a block of tasks for the server, client, sketches, models and textures, summed up the results of the past week and played our game at the end of the meeting. Gradually, our own graphics appeared in the client and this additionally motivated.
We also agreed that the first interface was useless 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 card was very much delayed, the initially named period of 2 months resulted in almost a 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.
The appearance of the map, which we have for some time considered 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 we invited the first players (a total of very little). Here is the video we have prepared for the closed beta:
Clip, prepared by us for the first closed beta test.
The fourth period
Long and monotonous work without tangible results is tiring. Around the summer of 2016, it became clear that productivity had fallen, the team was tired and needed a clear goal. We chose to launch Greenlight as such a goal in order to show the game to the community and get people to launch a beta test. Initially, we planned to launch Greenlight in November, but the preparation of graphics, promotional video and minor fixes was very long, as a result we are entering the greenlight just now.
For Greenlight, we further improved the visual component of the map, completed 2 guilds (Warfactory and Order of Dragon), and also prepared a special video clip (you can also watch it on our page in Greenlight):
The video, which we have prepared specifically for the launch of Greenlight
I invite you to see some fresh screenshots from the game to create an impression of how it looks now (especially in comparison with how it looked initially):
Fresh screenshots of the game
Little about tools
From the very beginning, we tried to stick to Scrum, we followed all the basic procedures: we formed a backlog, planned iteration, at the end of the iteration, demo and retrospective.
We took Trello as a board and for a while there was no limit to happiness. But with the growth of the team, it turned out that not every team member is ready to keep his tickets up to date, outweigh the tasks in “In Work” and “Ready”. For a while I tried to do it for them, but it seemed to be terribly inefficient.
First of all, as a replacement for Trello, we tried a team forum. Every week a plan for the iteration was published, at the end of the week we checked what tasks were done and for which delay. This scheme is simpler than Trello, it is much easier to maintain, but it is difficult to track who is delaying the execution of their tasks or skipping meetings.
The third tool to which we come - a table in Google Docs
Screenshot of our table for the period from June to November
This table allows you to keep track of completed tasks and failed (marked in black). In yellow, we marked tasks that were made late. The color marking of the table columns is different directions of development (server, client, UI, graphics). A quick glance at the table is enough to see which directions are being stalled, who from the team often fails deadlines, and who on the contrary fits responsibly. This format was the most successful. As a cherry on a cake, the file has a history of changes in order to track errors and find out who is “spinning points” to itself (several team members have access to editing the table).
Conclusion
In my story, many interesting moments are omitted: how we fought with the network interaction and how it ended up being implemented. How we fought for server performance and rewrote it entirely with Python on Go, as 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 Greenlight page!