Hey.
Today I will tell you about another fanatical home development, about how far interest and perseverance can lead, and about how they break. In general, everything is pretty standard for such stories.
Under the cat, you will see: a detailed history of creating RTS with your own hands (concept, code, interface, balance, map, models) and an experiment on attaching an eytreker to it as an input tool.
Well, let's start.
In the yard in 2014.
I am a student of the Department of Information Design at the Polytech (now "Engineering Graphics and Design").
With my bachelor's diploma, I developed a game for the kinekt about a duel of two puja, where you had to dodge the enemy's attacks and throw your hook at him (GET OVER HERE !!!).
In the master's work, I decided to take a step further. At that time, a technical innovation appeared in the laboratory at the department - Aytreker. The choice immediately fell on him. There was no doubt that the work would be a game, all that remained was to choose only the subject. After some thought, I realized that I wanted to pay homage to the strategy on which I grew up and which opened up to me the wonderful world of programming - Warcraft3.
Master's thesis, however, is not just the development of a product. To a greater extent, it should represent some kind of research. The question is, how can one fit Aytreking into the strategy, revealed Pandora's box.
This is where many years of gaming experience came into play. Most games try to clear the screen of controls, giving the main space to the content. In strategies, the interface occupies a huge space. To understand what a particular unit is, you need to find it on the screen, select it, translate a glance to the “status panel” and find the necessary parameter there. When such a need arises during the battle of large armies, such a sequence of actions often creates difficulties.
The question arose: since we already find a unit on the field, then why should we allocate it in order to read the information? Why not get it just by looking at it? After the demonstration, the question was transformed into the wise name “Functionality of the operating area of a person’s view in human-computer interaction,” which, in essence, meant a comparison of the effectiveness of the mouse and the eye when solving the problem of searching an object from a multitude and reading information from it.
Summa technologiae
Theme is. The concept is. It was the choice of technology. After a market review, the choice was between Unity, UnrealSDK, libGDX, among which Unity + C # was chosen. Having mastered the interface, the life cycle of objects on the stage and the possibilities of interaction with them, I began to develop.
Thanks to the greatest miracle of modernity - the Internet - I found a stunning series of tutorials that allowed us to build the basis of the engine for the future game. After going through the entire series of tutors for a couple of sleepless nights, I had a strategy blank on my hands. There were workers able to build buildings; harvesters capable of extracting resources and buildings capable of producing units.
This basis was enough for the experiment. True, one important component was missing - connecting the functionality of the eytreker to the game itself.
The Aytreking system is a bundle of two computers, one of which outputs the stimuli intended for the user (let's call it Demonstrator), and the second collects and analyzes the information coming from the Aytreker (let's call it Registrar). From the box with the eytreker, there was a software that allows you to synchronize two machines, calibrate the registration of the subject's gaze (everyone has their own eyes and the gaze parameters themselves), and then start to view a number of static stimuli. In my own task, the registration of a glance should have been integrated into an extraneous program.
For this, I had to study the protocol of interaction between the Demonstrator and the Registrar. Data transmission was carried out via a local network using UDP packets with commands, which means I needed to write my calibration client that emulates the operation of the default application.
It took me a couple of days to write a client. First as a third-party application. It made it possible to calibrate and then control the rectangular screen on the screen with a glance. More precisely, the rectangle was drawn at the point of fixation of the gaze. It would seem, not rocket science, but the ability to use the eye not as a means of obtaining information, but as a tool for outputting, influencing the external world, delights and shocks.
When everything was ready, it was time to set up an experiment.
There is a scene bounded by a single screen. On it, after launch, units (tanks, lol) spawn and begin to move erratically.
Each unit has a certain amount of health. All units have maximum health, except for one, which has a half level of HP. When you select a unit, we see around it a frame with a health indicator. Whose health is full - the indicator is green and full. In the wounded unit, he is red and half full. The goal is to find among the rest a wounded tank and keep it highlighted for a second. The main parameter measured is the time required to complete this task. The experiment consisted of 5 levels, differing in the number of units on the stage - 5, 10, 15, 20, 25. The hypothesis was that the solution of this task using the eytreker would take less time.
The experiment was conducted, the data collected. It is time to process statistics. I used the familiar means - PHP and JavaScript, calculated the Fisher criterion and found that the difference between using the cursor and using the Aytreker is statistically significant. As a dependent variable, of course, the speed of the task was used. Further, with the help of D3.js, I visualized the result.
In general, either the R language or the SPSS program is usually used to solve such problems. But by my nature I like to save energy and mental resources. I considered spending time studying these additional tools as an inefficient investment.
The resulting picture exceeded my expectations. It turned out that the subjects using the eytreker solved the problem together, and up to 15 objects and three times faster than the subjects with the mouse.
The study with the supervisor we have drawn up in
an article and it was published in the journal Perception.
Wow! Success, fame and so on.
Here I would like to separately mention my supervisor. Thanks to him, I wrote both my diplomas, and in general I moved towards programming and human-computer interaction. Pavel Orlov (
1 and
2 ), he now teaches at Imperial College London, but in general he studies people with the help of an eytreker and creates all sorts of cool jokes.
In principle, it would be possible to stop at this stage, but the artist's soul screamed that as a master's thesis one could show something more than a simple project made on a tutor.
Learning to walk
For a game to be a game, it must have a concept, an idea, a plot, a logic. Events should take place not on an endless grassy plane, but on a certain map, on which besides buildings and resources there should be relief elements, some kind of vegetation ... Units should clearly not only be able to move, but the player’s interaction with the world should occur through a thoughtful interface.
Blinded by opportunities and perspectives, I began to write code. First of all, I gave the units the opportunity to attack. Well, since they are attacking, naturally, they will need protection, so my units are overgrown with armor. Buildings were under threat of destruction, so units had to learn how to repair them. And why not at the same time add the opportunity to sell these same buildings? And if you look a little more promising, is it possible to arm the buildings themselves so that they can shoot themselves from enemies?
This thought became a cornerstone, which determined the further development and complete refactor of my project. At this point, I had a WorldObject class from which Unit and Building were inherited, each of which had corresponding functionality. Units could move, attack, extract resources, build buildings. Buildings could stand and produce units, but could not move and attack. There was a desire to make a guard building - a tower or a turret. The turret should be a building in its essence, but have the ability to attack, characteristic of units. It broke all my plans. It was necessary to somehow remove the attack functionality from the class Unit ...
But the problem may look wider. Are there any other intermediate links between the rear and units? Are there any other situations of using the capabilities of one class to another?
For debriefing, I decided to study: what other inconsistencies of this kind are present in the game taken as a reference - Warcraft3. And you know what? It turned out there is a whole galaxy. There are buildings that can attack, such as the Guard Tower or Orc Burrow. There are those who can still move, such as the Ancient of War. There are also units that cannot attack, for example Wisp or all sorts of neutral sheep and pigs scurrying around the map (critters). In my head, thinking about the nature of the differences between buildings and units went on, and I realized that there were no such differences. These are just the meanings imposed by the program by the players for their own convenience. There are only units and their abilities - to move, attack, produce units, build buildings, extract resources and so on.
An obvious solution to the situation was the creation of interfaces that units can implement. Were created: MoveAbility, RotateAbility, AttackAbility, DefenceAbility, HpRegenAbility, DefenceAbility, ProduceAbility, BuildAbility, RepairAbility, SellSelfAbility. The unit essentially remained only a container with the name, image and model. All other abilities are tied to it on top.
Brave new world
Now it's up to the concept.
Let me remind you that the case took place in 2014. Then there was a certain stagnation in the strategy genre, and this influenced the choice of the genre of the game itself. Also in those years, the steampunk campaign experienced a clear rise in popularity. I was a big fan of worlds dressed in copper and brass, wrapped in steam, rushing into their mechanical future. But it seemed boring to make the game only with a blow to steampunk and I was looking for the development of an idea. I wanted to add confrontation to the game. And what could be the most opposed to man-made industrial civilization? Of course, magic and unity with nature! Yes, of course, you will say Arcanum, but damn it, over time the beauty of such a setting is not lost. Further you will see that the project has developed not into a clone, stuck with a student on his knee, but into something completely different. Perhaps the complete ideological opposite of Arcanum.
Who will inhabit this world? In my opinion, modern fantasy games (and this is, after all, fantasy) now have come up against the crisis of archetypes. Obviously this is due to the universal rendering, everything becomes more accessible, and for this purpose it is more understandable. But this is no less painful to see everywhere the usual boring “people”, the sadly striking muscles “Orcs”, sour from the grace of “elves” and others so incomprehensible and detached that the eye became blurred, “protoss”.
I wanted to get as far away from this as possible, to abstract. And what could be more abstract than a ball? I went from this ideal geometric shape. I added a portion of “zerg” biomorphism to it (yes, I sinned against myself). I thought: why should not the abstract beings have the ability to form their body and all the covering tissues?
So orbs were born.
They are alive. They have no limbs. They have telekenetic abilities to interact with the world and the ability to sing (like dolphins) to communicate with each other. They settled the planet rather densely, but two centers of power were formed.
One is traditional, conservative, where they believe that they are children of nature and should as much as possible be integrated into it and contribute to its development.
The second is those who consider themselves to be the pinnacle of nature’s evolutionary algorithm, which means they have the right to burn forests under factories and overshadow the skies with smoke and steam. And, alas, according to the standard (the cake, the orcs left, and the fox did not go away) the second pull to conquer the world made the search for an expansion of the material base and led their warships to a land filled with forests and sparkling light of crystals ...
Behind this plot was an allusion to quite historical events. Didn't one day make the Indians see mast of Conquistador ships on the horizon? In the world of orbs, history repeated itself; we gave real sorcery to local Indians, and the conquerors came not from Spain of the 15th century, but, say, from Bismarck’s Germany.
So the war began, which destroyed both civilizations. Our game was supposed to start on the fragments of the former world, where a young tribe begins to look for itself in these twists and turns of magic and technology.
Between the tambourine and the gear
And what is the development?
There is only one race in the game, but during the plot it can modify itself. The experience gained from killing and exploring the world, allows you to start developing on the branches of magic and technology.
For a start, we stopped at two branches - Creation and Destruction. In each of them there are several pumping passes. Getting each one affects all units and all race structures. Creation is responsible for all the design characteristics - the development of the world, production, resource extraction and so on. Destruction, in turn, is responsible for the tools for the destruction of their own kind and everything that moves.
Having pumped in one branch in one direction, you immediately block the opportunity to go on it in another. Ultimately, to answer the question of how many races in a game can be differently - it is one, but with a development potential of 4 completely different.
And here we have a concept. So, it's time to decide who will be in our game! What units and buildings, how they will change. After long discussions, we decided to dwell on the basic set of strategies: a worker (builds buildings, extracts resources), a light unit (fast, weak), a heavy unit (slow, strong), a catapult (very slow, very thin, long-range combat). Of the buildings - the base (produces workers), the nest (gives growth to food), barracks (produces light and heavy units), workshop (produces catapults), sanctuary / factory (allows pumping).
Yes, I completely forgot to tell you about game resources. We decided to dwell on the classic pair - crystals + food limit, as well as an additional resource for moving along the development tree. Crystals are mined from deposits scattered around the map (hi starcraft), the food limit is increased by building special buildings - nests. An additional resource is earned by building on poisonous geysers of buildings of one of two types — shrines or factories. In addition, the game has experience, which is given for the destruction of enemy armies and neutral creatures. If a player earns a new level and has a sanctuary or factory, he can pump one perk on the development tree.
But back to the units and pumping.
For a long time thinking, we thought about how the pumping branches will modify the units. We came to the following:
- Steampunk + Destruction will increase the damage and range of units.
- Steampunk + Creation looks for production power, puts everyone in armor, and also increases the profitability of each employee's sales.
- Magic + Destruction in turn makes units faster in attack and reduces their cost, turning catapults into wall-to-wall tools.
- Magic + Creation increases the stock of health, and also significantly increases the speed of movement.
Remember, I said above that the game was the ideological opposite of Arcanum? In the world created by us, technology and magic do not mutually exclude each other. Fantasy now and then gave us visions of sorcerers walking on mechanical legs and tanks set in motion by a magic crystal instead of a steam or diesel power unit.
Find a balance point
All this sounds quite simple, but when we tried to transfer this narrative into the space of numbers, exact values and their increments, everything turned out to be VERY MISMANTED. It is easy to distribute some kind of delta of values for abilities, for example, this unit gets +20 to damage, and this +15 to movement speed. But then it is very difficult to reduce this huge array of parameters to balance.
In the huge Google table, we recorded all the desired changes of each unit, focusing on the sense of beauty. The sense of beauty worked in tandem with the inner empiricist, so each change in values was immediately checked on the test battle scene.
At a certain point, somewhere in the middle of the next night, it was understood that the feeling of beauty is good, but only logic and mathematical apparatus can lead to success in the task.
It became clear that all values needed to be reduced for each unit to one or several coefficients, which we could already compare. It turned out that the whole school and the whole university are not preparing you to calculate the effectiveness of the builder. It is not so obvious who will bring more to the treasury - the one who loads more into the backpack or the one who moves faster.
Through a sleepless night of mathematical tricks, formulas for calculating the effectiveness of different types of units and buildings were lined up, and this stage was more or less completed.
Then probably the question crept into your head: how did all this madness go into the game? I will answer quickly - the first time by scrupulous interrupting. But by the time each branch received 2 stages of development in each direction and the total number of units reached 9, then my internal lazy programmer had rebelled. How is it - me, non-creature-trembling, have to do such a dull confused routine ?!
Then I created a web application for generating the tree of pumping.
RTSeditor (as I named it with an easy hand) allowed me to create the tree structure itself and for each node specify the increment of values required by IAbility units. The zero node defined the initial configuration of each game unit.
At the output, this system gave JSON, which now took Unity and configured game objects (this import system also had to beat a certain amount of time, because it was not so easy to build and bypass trees).
Finally, the work was done, and instead of hellish torture, a convenient tool was obtained that allows you to quickly configure all the “content” of the game.
Music Ainur
Here I would like to insert a remark. Throughout the story, I use different pronouns - I, then WE. The fact is that I started the project alone, did research, created the game “engine” and so on. But then, with my activity, I became interested in my comrades and at first two people joined the process - Vladimir Ermakov (
Avega ) as an experienced programmer and Pavel Shilin as an artistic and descriptive consultant. Then Anna Trofimova and Nikolai Morozov (
Avatar4eg ) were added to help with landscape and programming, respectively. My good friend Dmitriy Mashoshin had a hand in creating a balance of his nights.
Vladimir helped to reach the solution of transferring units to the IAbility system, and then decided to link his graduation project with the game. His topic and goal was writing AI. Such a large task, which was generally solved, and our computer opponents learned how to rebuild the base and send their armies to the found enemy base with a conveyor belt.
Let's return to the development.
When we already had such a variety of functionality, it became simply unbearable to watch how these developed life forms graze on an endless grassy plane. I wanted to create a world for them, and I started to create a map.The first stage I analyzed the WC3 cards. I learned that they consist of several symmetrically located starting points, camps of neutral units, points for the further development of the base and a cunning system of roads between all this.Well, I tried to create something similar, but my own (heh, with these words you can write the whole development as a whole).
At first the map was drawn and designed on paper.Then it is outlined in Photoshop in the form of a black and white height map. Initially strict, then it acquired smoothness smoothness and noise. The important point here was to preserve the distinction between impassable faces of surfaces and descents and ascents.After that, this structure was extruded from the plane already in Unity. The result was a good relief, very similar to the game map.But something was wrong with him. He was completely white and shouted loudly - ADD ME TEXTURES.What I did.
I didn’t have time to paint my textures (I confess, but the diploma time was appropriate, and it was necessary to turn around), so WorldOfWarcraft textures, downloaded from open sources, were used.
Unity has amazing texturing functionality that allows you to draw textures on top of a form, like brushes. This allowed us to quickly mark the zone, and then it was for detail and elaboration. It would seem that the playing field is a background secondary element, but it is the player’s eye that looks at him throughout the game, so I wanted to make the card really interesting and lively. Here I would like to thank Anya, who helped me a lot with the texturing process and made a real highlight from the map.Here we were waiting for a big surprise. Our units moved well along that hated grassy plane, deftly walking to the point of pressing along the perfect line. When obstacles and irregularities began to appear on their way, problems began with the movement. Yes, the orbs have no legs, but this didn’t stop them from breaking small bumps. There is a need to give the units a search path algorithm.Here the experienced Vladimir entered into the matter, who explored the topic and realized that it was too hard to implement any of the existing methods of solving the problem. A plugin (module?) For Unity to solve the problem - A * was quickly found. Vladimir understood the interface and adapted it to our needs. After that, the units began to find their way perfectly even to the other end of the map, when there were rocks, lowlands, and other joys of the landscape in front of them.After the creation of the world, the most anxious question became actual - why all our units are goddamn CUBA?The time has come to give the orbs the appropriate form, to settle them into the buildings proper to their appearance, to give them the tools for mastering the new world and weapons.Here I want to mention that a couple of weeks remained before passing the diploma. Having calculated my temporary capabilities, I came to the conclusion that I have about 4 hours for one model and its modifications. I had to work fast, stream and at the limit of opportunities.To shape the shapeless
Meet the orbs!
These are basic workers. The first is pumped into full magic, the second in full tech. One with the help of a piece of crystal, which he has grown on himself, can pull crystals from deposits to other stones and deliver them to the anthill for further use. The second one puts on technological tools of labor and huge carrying capacities.
But the nests in which the orbs live. In the center of the base varinat. To the left there is a development in magic, to the right - to technology. Moreover, both there and there - development along the branch of both destruction and creation, therefore, they look so integral. But, as you understand, this is not always the case.
But the hybrids nest. Steel pillars and magic crystals on top? Why not.
On the contrary, do you like unity with nature more, but at the same time you want to have a heating system? You are welcome.
A total of 6 objects were simulated for the game (3 units and 3 buildings) + 4 modifications (2 magic, 2 technical). There was not enough time for a light unit and totems, alas.All modifications were designed in such a way that part of them was changed during the development of the branch of destruction, and part of them - of the branch of creation.Thus, the game became visually diverse. During the game you are waiting for the next shooting range as a holiday, because after that all your units will be transformed and will more reflect their characteristics and your style of play.In Unity, this was added as follows - units have basic elements, such as a body, plus each pumping range (including the basic one) has a link to the corresponding graphic elements. When a unit appears on the scene, its base part is created, and then all the required body kits are added to the WorldObject structure from the assets.Window to the world
And now the game already looks like a game. But still in it something else is not finalized. The world is there, creatures move along it, buildings are built, resources are extracted. Battles take place, experience is gained and races choose their own path of development.Why, then, does the player suffer? The fact is that an adequate interface has not been developed, HUD, as they call it in games.To solve the problem of building the interface, I initially collected analogs, old and new - Command & Conquer, Cossacks, Warcraft 3, Starcraft 2, Warhammer, Dota, LoL - and began to analyze the constituent elements.The game interface (as in any other) should reflect the current location and status of the protagonist, as well as suggest ways to change this state. In general terms, this includes the availability of resources, information about the selected unit (such as its location, health, possible actions and explanations for them), the location of all units on the minimap, the ability to pause and leave the game.
After seeing how these tasks are performed by the grandees, I tried to assemble my own structure, which corresponds to the usual user patterns, but occupies the minimum amount of screen space.In those ancient times, native Unity tools for creating HUDs were a small set of elements that need to be created and placed on the screen directly through code.After writing a wonderful smooth adaptive frontend on html + css, this seems to be an absolute wildest fanciness, but what to do. It was necessary to adapt, calculating various indents, constantly considering the width and height of the screen.
The beauty of screwing to such an interface is an extremely dreary exercise, so for a start it was decided to execute it in neutral colors in a flat form.As soon as the basis was nakidana, the question arose of creating a large number of icons for the actions and other interface elements.It became clear that drawing everything was a completely hopeless task with a hard time limit, and I began searching for alternatives. I found a wonderful project - GameIcons, which creates free simple icons for indie games. All necessary components were found in it and the interface was assembled.In the course of development, the need to create a minimap surfaced. After a bit of thinking about Unity’s capabilities, I added a rectangle of size corresponding to it to each unit, which is visible only through a special camera mounted above the entire field.As soon as the minimap was ready, there was a desire to click on it to send units on long journeys, which I quickly realized.
It is worth mentioning that part of the interface is the very display of information about the health of the unit from which it all started. When selecting, now around the unit there is a circle, the color of which reflects the attitude of this unit towards you: green - friendly, yellow - neutral, red - hostile. Above the unit itself, the health scale is also displayed, which also changes color depending on its quantity.In order to save space on the screen, it was decided to make the health bands of all units of a certain length (so that when pumping and buffs, the health band of 10,000 ha was not from edge of screen to edge).
The interaction with the world does not end there. An important element of understanding the state of the world and the possibilities of change is the cursor. In the web, it most often turns into a foot to display an element that can be clicked, and into a carriage for text that can be selected.In the game, just as we need to understand who raised their hands and what to do with it. So, when selecting, we need to understand whose unit it is, and when switching to a state of a certain action (attack, movement, loot), show the possibility of interaction.As soon as all the basic actions appeared, they wanted to perform them from the keyboard for speed. To do this, we added sets of inputs from the keyboard, which depend on the state of the player.And, of course, experience and tree pumping.
We get the level - a special button for pumping lights up, a tree opens. It shows in green what we have already learned, black shows what we can go to, and red shows what we cannot.
After opening a certain shooting gallery, we see all the changes he makes to the game, and then we decide whether we want to pump it.Yes, it looks pretty clumsy, but this was just the beginning!And now everything is ready for the first launch! Hooray, a big way behind, ahead of the infinite space of development options.
It remains to add only the start screen - and go ahead, scout the amazing spaces of Evennedium. Oh yeah, I did not say that after the enhanced brainstorming we did choose the name?EVENEDIUM.Go!
And some screenshots for those who do not want to watch the video above.
Finita?
The basic version of the game was ready.Yes, it is very simple, but it only gave us a reason to make an excellent pool of tasks for further development - here you will have new units, a fog of war, and abilities with an accompanying generator of them, and new branches of pumping, and more variability, and campaign, and multiplayer, and monetization ...Oh, by the way: I defended myself perfectly, but that did not surprise me. I was more excited about the future of the game, which I immediately embarked on implementing.The keyboards were boiling, for another month we were actively writing something, and suddenly, suddenly, I discovered that a year of development had passed! For a whole year, I pored over the creation of this brainchild, acquired over-allies, and here we are - the team, we have a product and a bright future. We decided to celebrate.The last commit began to meet everyone like this post.
And yes.
Last. Strange as it may seem, it was at this very moment that the guys, who by the end were seriously helping with the creation, decided to leave the project. He demanded time and effort for which they were not ready. They did not see any perspective or sense in it.For me it was a surprise. Hurtful, hit pretty hard.There will be no long withdrawal, what is it for? Everything is described above.In general, I am proud that I chased my dream of creating a world and brought it to such a state.