Have you ever thought about your own game? And about your own multiplayer game? I think yes! Many of you would like to cling to the development of your own masterpiece, where your multi-faceted fantasy and exceptional perfectionism merge. I understand you and want to tell my story of this fascinating way.
It all started back in 2007, then there appeared a game not similar to anything online j2me based on the work of Sergey Lukyanenko. I did not have a computer yet, and I was very impressed with this game on a mobile phone, most of all I was amazed by the open world. I got involved and, despite the absence of any tutorials, I quickly figured out what was happening.
As time went on, but the interest did not fade, there was already a little just a game. The desire to find out how it works, and randomness led to the use of bugs with subsequent bans. Then graduation from school and the choice of profession "programmer" gave impetus to the development of my first software for gaining benefits in the online world.
As soon as my knowledge in the field of OOP was strengthened, we then, with our game friend and artist, decided to develop our MMO, which would be a hundred times better!
Our game glorifies two factions between each other, Oseon and Weiland. Each of them has its own planet, in turn, the buildings necessary for the player’s development are located on it.
Home Planet of the Osone Faction
Planet factions are protected by a system of 12 gates. Having captured all the gates, players get 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. Caught in a difficult situation, players of the occupied side receive reserve troops with parameters 1.4 times higher than their own.
The battles take place in turn-based mode, some compare them with similar ones in “Heroes”, others are called original chess. In part, they are all right, there are units with magic, and your head will have to think a few steps forward.
Fight with the enemy
However, the cruel world of PvP games has other interesting mechanics, ranging from the usual mining of rich deposits to hunting treasure hunters.
Since we didn’t have the experience of creating MMO games, we decided to take everything that is bad. Our set includes: Anthill, Netty, MySQL. It was not exactly the technology. After a lot of work done, we ran into a bunch of problems: the lack of an interface editor, micro-lags 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 started to behave strangely.
The prototype of the game. Lagi
After a year of development, when it was impossible to retreat, we still completed the basic game mechanics, assembled the map editor and decided that the time had come to try it out 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 this time, the game had an incomprehensible control involving the keyboard, there were many bugs left, and also too simple maps that had only two layers (grass and trees). And after three days of work in the VC, only 15 people registered - people did not understand how to play.And we decided to redo everything from scratch.
Player Interaction Menu
Probably many, faced with failure, think that it is not them, because a lot of time has been spent, but there is no visible result. But to give up is stupid when it’s been such a long way. After a couple of months, with the experience we already had, we decided to take up the game again.
We decided to definitely do a new version of the client with drawing graphics through a video card. Of many frameworks, Starling seemed to be the most attractive, it had a similar API with standard flash, supported by Adobe, and it was possible to use existing graphics with little effort. Finally, the new version worked smoothly.
To rasterize a vector on the fly, I took Dynamic TextureAtlas Generator . But later the 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 dealt with the technologies on the client, we decided to go in with the
server maps. Each planet can consist of one or more locations, between which you can move to the 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 stopped at four:
The idea was such that the first three layers were drawn in one bitmap and sent to video memory. This is a good approach when one is drawn instead of three layers in the background. But there were no problems: when switching MovieClipa to the next frame for rasterization, all previous frames should be rendered. At the entrance to the location the game was frozen, so it was decided to transfer all the tiles in advance into BitmapData and make a quick copyPixels. But it turned out an unpleasant frieze at the start of the game at the time of rasterization of a large number of frames. You may have seen some browsers grinning at the start when loading resources. We didn’t want our game to be the same handicapped, so I limited the time of drawing tiles for each frame. Here is here you can read more about how to do this.
All cards had one size of 20x16 square tiles of 64px. Map data was written to a file in binary format, where the boundaries of the layer were determined in advance and it was necessary to record only the frame number of MovieClip. 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 has taken a significant part of the client’s development. In order to be able to create beautiful maps, an editor was written in Flex.
For each of the 14 planets, its own flora and fauna was made so that you can visually understand which planet you are on.
Also, we programmatically added halves of tiles for the card, which are simply duplicating the neighboring ones, for the card.This was done for protruding interactive elements like menu buttons. The 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.
Map with a fog of war on the sides
While pursuing a client, we simultaneously looked 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 threw, because it was not clear what to write, but it was boring to delve into the thorns of game logic. After some time, we determined that we need a specialist who can design a server in Java, and if he throws a project in the future, I could finish it. The local solver helped us with the server architecture. He, one might say, set us on the right path: showed how to do the server, and borrowed the architecture from the Meil.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. Looking back now, I’m wondering why we didn’t write a server on Akka?
You can read about the architecture here - The architecture of the online game server using the example of Skyforge can also be found lectures on Intuit. Of course, we have not 2 million lines on the server, but also quite a lot. No fibers (as in skyforge) are used, and our server is likely to be less readable. By the way, the code that was used for non-preemptive multitasking in Skyforge, the very same filers, was published much later, when everything was working for us.
While I was working on the server and gluing logic on the client, the artist completed the missing parts that immediately got into the client. As soon as the server was ready, we started the alpha test. This time everything was almost as it should, but the bugs and server errors had to be corrected for a long time.
I want to tell you about another unusual thing in the game. What would you call a player who deliberately makes an incomplete army and loses to other players/bots? We call them "plums." They merge experience and lower their level deliberately, 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 becomes 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 simpler than the classic game, but draining the experience requires more time from you and skillful pumping up initially. If you lower the level of a weak character, it will not give a big advantage, and will only tighten the player to the average. Level up and down can be infinitely long. Even reaching the maximum development for his current maximum level, the player can rise to an even higher level to access new technologies and again merge his progress through experience, remaining equally strong in technology.
There is a problem for newbies when they can’t do anything to such pumped dwarfs. We solved this problem by introducing restrictions, dividing the players into two groups: plums can only be attacked by bots, with restrictions on the maximum level on other players and on players as merged as they are. Thus, they practically ceased to put pressure on the balance of the game, and most importantly - they could continue to do their favorite thing.
In the VC games catalog we hit February 4, 2018, and not the first time.Our first application was rejected without explanation, and when we re-applied we were still added to the catalog.
Despite the long development of the game, it didn’t cover all the details, we made a lot of mistakes. First of all, I made a mistake with the platform: not every player is ready to spend a lot of time in the 2D browser game, which is required by the mechanic. Many people are accustomed to more simple and 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, the players safely forget what was there, and maybe not even read it.
According to VC statistics, we have a huge dump of players, for a long time mostly only those who once played that old game and are already familiar with the mechanics remain.
About a year after the launch of the alpha version, it became clear that Flash would soon stop working in browsers. From this point on, I decided that the client should be ported to something more enduring. Of course, it is more pleasant to write in a familiar language, so I chose LibGDX. This Java framework allowed us not to rewrite some of the logic, but simply to 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 weaknesses: font rendering, lack of live visual interface editors, etc.
At the moment, the alpha client is written under the android, which implements 50% of all features in the game.
Game Client for Mobile
Development is still ongoing. If you have a desire to draw something or write for a mobile client - write.
I also want to express my gratitude to the sound engineer Peresvet Mukhanov and the composer Artem Davydov, they wrote everything that can be heard in the game in a short time and very well.
Source text: Five years of slavery