I created the first version of this game at my summer house over just two weekends in 2015. The full version differed only by minor interface tweaks, improvements to the wave generator, and Facebook integration.
The game featured saving and progress synchronization across devices, allowing players to exit on one device and continue on another. At the time, I thought this was a useful feature, but now I see it as an unnecessary use of time.
Most of the bugs in the game were originally made for another game that never saw the light of day. Yet in this game, they fit perfectly and added a unique charm. I designed the game interface myself using GIMP.
A logic game for mobile devices, blending elements of 2048, Color Lines, and Match-3.
This game, like Krakoid and Bugzz Smasher, was built on my own engine. The engine supported only a few platforms — Linux, macOS, Windows, iOS, and Android. Development was mainly done on Linux.
The screenshots show a later version of the game, where the graphics were polished to the level of “finally not hurting your eyes” at Melesta. The game was also published by Melesta. Unfortunately, it was completely unsuccessful. This may have been due to extremely long sessions, which could last days or even weeks, and poorly designed monetization. There was not even a basic rewarded video feature — only interstitial ads at the end of a session. And, as you may remember, sessions lasted a very long time.
A tower defense game developed by Belka for social networks – a really cool game with a great story, artwork, and animations. The original game was built in Adobe Flash.
I was one of three programmers responsible for porting the game to iOS and Android, using C++ and a custom engine. I worked on the tower defense core of the game, the popup system, the tutorial system, a localization-merging utility, and various smaller features. Everything else – which was a huge amount of work – was done by other talented members of the team.
Some of the graphics and animations were taken from the original Flash version, while others were recreated from scratch. For example, most of the user interface was redrawn.
Cutscenes were implemented as video clips loaded from the server when needed, featuring animations of localized character dialogues. The old-film visual effect was implemented entirely in code.
This is a highly engaging hidden-object game featuring numerous mini-games and tasks.
The game was developed by a team of three to four people, but the team composition changed several times, so the total number of developers was roughly twice as many. In addition, marketers, documentation creators, and a project manager also contributed… I can’t provide all the details, especially since I’ve forgotten much of it.
The game was developed under Linux using Code::Blocks. The target platforms were Windows and macOS. The engine was a heavily modified HGE, primarily to support Linux and macOS. Here, the SDL library and its companions — SDL_sound, SDL_image — proved very useful.
The game was released around 2010. As far as I know, it is still available on various publishers’ websites.
Worms Zone – a game about worms, or slither.io on steroids
At first, I didn’t even think of making a game. I just wanted to try implementing smooth worm movement – where the segments don’t follow the exact path given by the player, but behave more naturally. Yes, it’s a bit more complex and requires more calculations, but the movement looks much nicer and more interesting. My first tests were done in a Java-like language using Processing. After about an hour, I had a working prototype – a project on GitHub.
Watching the worms eat “apples” in my prototype, I decided to move forward with developing a full-fledged game.
I first rewrote the worm movement algorithm in C++ and then began refining it. The most important part was to pass the “coiling test” – when a player curls the worm into the smallest possible loop. Most games of this kind fail here: the worm’s tail stops moving, and only the head and a few segments follow, which looks awful.
Once I had an algorithm that passed the coiling test, I ran into a new issue: long worms had many “invisible” segments hidden behind others on the screen. Time to refine the algorithm – the tail still follows the head, but the number of visible and calculated segments decreases. When the worm moves straight again, the segment count returns to normal.
Then came the small details: when boosting, the worm should lose mass, becoming shorter and thinner. When moving normally and eating goodies, the worm should grow in both length and width. These details turned out trickier than they seemed at first – always a nuance, and here there were many 🙂
Game development and gameplay evolution
Worm bots were added to the arena, and their AI gradually improved. The first versions of the AI were, frankly, terrible. Now the bots are much smarter – and sometimes even cheeky.
I experimented with the interface. Unfortunately, I’m no designer or artist, so the result is what it is.
Gradually, support for different platforms was added – iOS, Apple TV, Android, Android TV, Web, Linux, Facebook Instant Games, OK, VK, and more. Since development was done on macOS, that was the first platform the game worked on.
I implemented multiple control schemes – mouse, remote control, gamepad, keyboard.
Gameplay evolved with new power-ups: a temporary worm extender; a radar showing other worms on the map; and a 5x multiplier for rapid growth and score boosts.
Balancing gameplay is still ongoing. I haven’t yet found the ideal parameters for arena size and maximum worm count; worm growth and weight loss rates; and the cost of skins and customization.
Over time, the game accumulated various features. Skins with textures were added, and I wrote a simple Photoshop plugin to make textured skins easier to create. It was very basic – it automated only a small part of the process, so some steps still had to be done manually.
A few technical details
All sprites (UI, skin elements, effects, power-ups) are stored as separate files. During the resource build stage, atlases and descriptions are generated – all done via the console. Yes, I love the console. The atlas packer, of course, is my own.
I also wrote a simple shader implementing a “circular indicator” to show remaining power-up time. I based it on one of my older shaders available on ShaderToy. Nothing fancy – it could have been done without it.
The game supports multiple languages: English, Russian, French, Spanish, Vietnamese. Adding a new language is no problem — you just need to order a translation. The game uses the free Google Noto TTF font, which contains glyphs for many languages, and the required character atlas is generated at runtime.
Not all zombies are equally useful. Crush them all, but be careful – some zombies aren’t quite ordinary.
The rules are simple: tap a zombie to kill it and use power-ups wisely.
All the artwork was purchased from specialized stock sources. There was nothing unusual during development – I was just making another game.
The only exception was the button. I had to make a change in the engine – adding a new event to the button widget, which was needed for the power-ups. I could have created a specialized widget instead, but I decided that extending the functionality of the standard button would be useful for future projects.
One of the early games developed in a small team at Synesis. It’s a hyper-casual game where the character is controlled with just a single tap on the screen. The player’s task is to tap at the right moment – tap too early, and you lose; too late, and… yep, you lose again.
I can’t recall many details about the game – I’ve forgotten most of them. I do remember there were some issues with the game mechanics. It lacked clarity and transparency for the player, which left mixed impressions overall.
Both the game and the engine were written in C++. It was still the first version of the engine, though already significantly improved.
What I do remember well is that I really liked the character – both the design and the animations. In that regard, the team did an excellent job. The same can’t quite be said about the rest of the game.
Simply another clone of Fist of Fury. I really liked the game’s dynamics, style, and animations. Development went smoothly and quickly, and I can’t recall any major issues during the process.
Like most of my other games, this one was created by a small team at Synesis. In-game purchases were not implemented, but the game did include ads – judging by their appearance, they were provided by Chartboost. Coins needed to unlock characters dropped randomly from defeated enemies.
Another classic arcade-style game inspired by bar machines often found in pubs to entertain tipsy visitors.
The original arcade game – Ice Cold Beer, developed by the well-known Japanese company Taito in 1983, served as the main source of inspiration.
The player’s goal is to roll a ball into a specific hole on the playfield. To do this, the player controls a horizontal bar holding the ball using two levers connected to the edges of the bar. Tilting the bar left or right allows the player to guide the ball to the desired location.
This was one of the last games I developed together with a great team at Synesis.
The game was built on a new, reworked engine, which fixed issues from the previous version and introduced an updated API. Box2D was used for physics simulation, although it wasn’t strictly necessary given the simplicity of the gameplay.
I also created a test build for Android TV and Apple TV, designed for gamepads with dual analog sticks. Unfortunately, such controllers are quite rare on these platforms, so the TV versions were never released.
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
