Five years of slavery
Have you ever thought about your own game? And what about your own multiplayer game? I think yes! Many of you would like to cling to the development of your own masterpiece, where your multifaceted imagination and exceptional perfectionism merge. I understand you and want to tell my story of this fascinating way.
It all started back in 2007, when an online j2me game based on the work of Sergey Lukyanenko appeared. I did not have a computer yet, and I was very impressed with this game on a mobile phone, most of all it struck the open world. I got involved and, despite the absence of any tutorials, quickly figured out what was happening.
Time passed, but interest did not fade away, there was already not enough just a game. The desire to find out how this works, and randomness prompted the use of bugs with subsequent bans. Further graduation and the choice of profession “programmer” gave impetus to the development of my first software for profit in the online world.
As soon as my knowledge in the field of OOP was strengthened, then we already decided with my playmate and artist to develop our own MMO, which would be a hundred times cooler!
What is our game about?
Our game glorifies two warring factions, Oseon and Weiland. Each of them has its own planet; in turn, it houses the buildings necessary for the player’s development.
Oseon Home Planet
Faction planets are protected by a system of 12 gates. Having captured all the gates, players gain access to the enemy planet. It is not enough just to teleport through the opened path, after that it is necessary to capture the citadel - the main building of the planet. Finding themselves in a difficult situation, the players of the occupied side receive reserve troops with parameters 1.4 times higher than their own.
The battles take place in a step-by-step mode, some compare them with similar ones in “Heroes”, others call them a kind of chess. In part, they are all right, there are units with magic here, and you will have to think a few steps ahead with your head.
Battle with the enemy
However, the cruel world of PvP games has other interesting mechanics, ranging from the usual development of rich deposits to hunts for treasure hunters.
Since we did not have experience in creating MMO games, we decided to take everything that is bad. Our set includes: Anthill, Netty, MySQL. These were not exactly those technologies. After a lot of work, we ran into a bunch of problems: the lack of an interface editor, the micro-logs of the map when moving, text input, and much more. In fullscreen, the game looked disgusting.
The prototype of the game. Mine development
In some cases, when switching the game state, the virtual camera on the engine began to behave strangely.
The prototype of the game. Lags
After a year of development, when it was no longer possible to retreat, we nevertheless completed the basic mechanics of the game, assembled a map editor and decided that the time had come to test it in public.
We added the game to VK (without a catalog) and announced the launch in our group, where there were about 100 people.
At that time, the game had incomprehensible keyboard controls, there were a lot of bugs, and also too simple maps that had only two layers ( grass and trees). And after three days of playing the game in VK, only 15 people registered - people did not understand how to play. And we decided to redo everything from scratch.
Меню взаимодействия с игроками
Lech, it's not that, come on first!
Probably, many, faced with failure, think that this is not theirs, because a lot of time has been spent, but there is no visible result. But giving up is stupid when you have come such a long way. After a couple of months, we with the existing experience decided to take up the game again.
We decided to definitely make the new version of the client with rendering graphics via a video card. Of the many frameworks, Starling seemed to be the most attractive, it had a similar API with a standard flash, it was supported by Adobe, and it was possible to use existing graphics without much effort. Finally, the new version worked smoothly.
To rasterize the vector on the fly, I took the Dynamic TextureAtlas Generator . But in the subsequent library almost completely had to be rewritten and abandoned atlases, the animation took up a lot of space and could not fit into the atlas of the allowed sizes.
After we figured out the technologies on the client, we decided to deal with the
server cards. Each planet can consist of one or more locations, between which you can go right or left. For each location, a piece of map was created, initially consisting of two layers. Later, we decided to add another layer, and then another one, and as a result we settled on four:
- grass / ground;
- stones \ water;
- cage-sized decorations;
- large scenery.
The idea was that the first three layers were drawn in one bitmap and sent to video memory. This is a good approach when instead of three layers, one is drawn in the background. But it was not without problems: when switching MovieClipa to the next frame for rasterization, all previous frames should be drawn. At the entrance to the location, the game was freezed, so it was decided to transfer all the tiles to BitmapData in advance and make quick copyPixels. But at the same time, an unpleasant frieze was obtained at the start of the game at the time of rasterizing a large number of frames. You may have seen some browsers freeze at startup when loading resources. We didn’t want our game to be the same invalid, so I limited the time for drawing tiles for each frame. Here here you can read more about how to do this.
All cards had one size of 20x16 square tiles of 64px size. The map data was written to a file in binary format, where the layer boundaries were determined in advance and it remained only to record the MovieClip frame number. Thus, the weight of the map file was 1280 bytes. But later the format was converted to JSON to make it easier to work with data.
As a result, work on maps took up a significant part of the client’s development. In order to be able to create beautiful maps, an editor was written on Flex.
Each of the 14 planets has its own flora and fauna, so that you can visually understand what planet you are on.
Also, programmatically, we added halves of tiles for the card, from above and below, that simply duplicate neighboring tiles. This was done for prominent interactive elements such as menu buttons. Fields of neighboring locations with the fog of war were added to the left and right - this was a great idea that solved several problems at once. The game began to look much better in fullscreen.
Card with fog of war on the sides
While dealing with the client, we were simultaneously looking for a server programmer, but there were not many who wanted to write a dubious game without normal documentation. Some began to write and immediately dropped it, because it became unclear what to write, and it was boring to delve into the thorns of game logic. After some time, we determined that we need a specialist who can design the server in Java, and if he quits the project in the future, I could add it. The local craftsman solver helped us with the server architecture.. He, one might say, set us on the right path: he showed how to make a server, and borrowed architecture from the Mail.ru training course. Solver was no exception and after a while left us. After another year of effort, I managed to write all the basic game logic. Now, looking back, I am at a loss why we did not write the server on Akka?
You can read about architecture here - Architecture of an online game server using Skyforge as an example ; you can also find lectures on Intuit. On our server, of course, not 2 million lines, but also quite a lot. No fibers (as in skyforge) are used, and our server most likely turned out to be less readable. By the way, the code that was used for the same fiber for non-preemptive multitasking in Skyforge was published much later, when everything already worked for us.
While I was busy with the server and glued the logic on the client, the artist completed the missing details, which immediately fell into the client. As soon as the server was ready, we launched an alpha test. This time everything was almost as it should, but server bugs and errors had to be fixed for a long time.
Roundtrip. Self-born game mechanics
I would like to tell you about another unusual thing in the game. What would you call a player who specifically makes an incomplete army and loses to other players / bots? We call them "plums." They merge experience and lower their level intentionally, so they become stronger at their level. This is important when the level of players that can be attacked is limited and gives them more development opportunities. It is becoming easier to defeat high-level enemies and get more rewards. It's like pumping your Persian, but in the opposite direction. Although it may seem easier than the classic game, the drain of experience requires you more time and skillful pumping up initially. If you lower the level of a weak character, then this will not give a big advantage, and only pull the player to the average. Raise and lower the level can be infinitely long.
Beginners have a problem when they can not do anything to such pumped dwarfs. We solved this problem by introducing restrictions, dividing the players into two groups: you can only attack bots on bots, with restrictions on the maximum level on other players and on the same merged players as they are. Thus, they practically ceased to exert pressure on the balance of the game, and most importantly, they could continue to do what they liked.
Failed, not fartanulo
We entered the VK games catalog on February 4, 2018, and not the first time. Our first application was rejected without explanation, with a repeated application we were nevertheless added to the catalog.
Despite the long development period of the game, it was not possible to capture all the details; we made a lot of mistakes. First of all, they made a mistake with the platform: not every player is ready to spend a lot of time in a browser-based 2D game, which requires a mechanic. Many people are accustomed to simpler and more understandable games, where there is more fun from the very beginning. Our training in the game, to put it mildly, failed. After completing the tutorial, players safely forget what was there, and maybe they don’t even read.
According to VK statistics, we have a huge dump of players; for the most part, only those who once played that old game and already familiar with mechanics remain for a long time.
48 weeks later ...
About a year after the launch of the alpha version, it became clear that Flash would soon stop working in browsers. From that moment, I decided that we should port the client to something more tenacious. Of course, it is nicer to write in a familiar language, so I chose LibGDX. This Java framework allowed us not to rewrite some part of the logic, but simply copy it from the server. It has good abstractions for tile maps and an implementation for Tiled, which allowed us to quickly write code for our maps. But there are also weaknesses: font rendering, lack of live visual interface editors, etc.
At the moment, an alpha client for android is written, which implements 50% of all the features in the game.
Mobile Game Client
Development is still ongoing. If you have a desire to draw or write something for a mobile client - write.
I would also like to express my gratitude to the sound engineer Peresvet Mukhanov and composer Artem Davydov, they wrote everything in a short time and very high quality that can be heard in the game.