I worked on the engine and game code while at Synesis. Graphics, music, animations, and all other non-programming aspects were handled by other talented specialists.
I can’t go into full detail about the development process or the internal structure of the engine and game. Both the game and the engine – as well as the toolchain needed to build the game – were written in C++.
The development process itself was similar to most casual games: we chose the game concept, the artist/designer created sketches, and we approved them together. Animators and integrators then got involved, while I focused on writing the game code and, when necessary, refining the engine. Everything was then combined into a single project, resulting in a game for iOS and Android.
This is a space-themed endless runner. Unlike other runners, it stands out with its setting. The game features a variety of ships, each with unique characteristics.
The game was also developed at Synesis. I worked on the engine and the game code itself, while other specialists at the company handled the rest.
This is my version of the game King’s Valley for the ZX-Spectrum, which I wrote back in my school years. The game is not a clone of the original MSX title but rather inspired by it. The main character was copied pixel by pixel from King’s Valley 2 with the help of graph paper, a few keen eyes, and a pencil, thanks to my friend Yevgeny Yanushkevich. My brother Ilya and my friend Yevgeny also helped me design the levels. All the development of the game and its resources was done entirely on the ZX-Spectrum.
In the video, there’s quite a serious player – completing the game in just two hours.
In fact, the game turned into quite a long-term project, stretching out, if I remember correctly, for about a year. It was written right after I lost the disks with the source code of my previous game – a port of Knightmare from the MSX.
The game can be found in the World of Spectrum archive and on other sites.
Strangely enough, World of Spectrum claims that the game was released in 1994. That doesn’t quite match reality, since that was already my third year at the Academy, while I had actually written the game back in school.
To this day, I continue working on reviving the game for mobile devices (iOS, Android), TV set-top boxes (Apple TV, Android TV), desktop platforms (Linux, macOS), and the web. But I’m doing this VERY slowly – sometimes putting development aside altogether, and sometimes spending just a few hours a month on it.
The idea was simple: “I’ll take Krakout and Arkanoid: Space Ball, quickly rework them, and release something new.” Yeah, right – wishful thinking. “Quickly” didn’t happen for several reasons: the old game code was useless, and even looking at it hurt my eyes; plus, the plan was to use a new (for that time) version of the engine and replace my old simplified math with the Box2D physics engine.
So the old projects “voluntarily shared” only some assets and ideas – the game itself was written entirely from scratch. Levels in the game were grouped into worlds – there were 10 worlds in total, each containing between 10 and 40 levels. To save time, some worlds were copied from previous games. But several levels and even entire worlds were newly designed. Different people worked on different levels and worlds.
Because the game’s levels were meant to be dynamic, an external editor was created for building episode worlds. Level data was stored in XML, describing object types, appearance, behavior, and durability. The editor worked with object groups – for example, a circular trajectory with radii R1 and R2, rotation speed and direction, and the number and type of objects on it. When loading a level, each object became independent in the game while still visually belonging to its group.
Krakoid on the OUYA TV console
Target platforms were iOS, Android, Android TV, OUYA, Linux, macOS, and Windows. Both the game and the engine were written in C++. Development was done under Linux, in my favorite editor – VIM.
At one point, a publisher from China requested the game. I had to implement special, localized payment methods. The tricky part was that each mobile operator had its own SDK for different payment systems. It was impossible to test integrations locally, so I had to rely on sparse documentation and my own experience. I don’t remember how long it took to implement all the payment options, but the work was eventually completed. A special build of the game was sent to the publisher for testing – after which the publisher disappeared.
And that wasn’t the first publisher to vanish after receiving a build.
Almost my first game developed for iOS. I worked on this game at Melesta. The company’s engine, written in C++, was used with my modifications to the renderer. For the UI, I created my own simplified polling-driven widget system. At the time, I thought it was a good and justified approach.
The game was developed between 2011 and 2012. I only worked on the iOS version; later, other developers ported it to Android and Windows. One of these developers was the excellent programmer Sergey Greshnov, sadly passed away prematurely. There was also a Flash version, but it was most likely written from scratch.
Development proceeded in bursts — first a feature would be implemented, then cut, and replaced by a new one. This happened quite frequently. When developing a game with a “floating” or completely absent design document, this can be considered normal. Still, the development of this game stood out compared to others. Not necessarily good or bad — it’s just a fact that stuck in my memory.
It’s worth noting the particle system used in the game. I won’t name it, but the library was quite well-known, with a Windows-only editor. The particle system itself was decent but very slow. Sergey Greshnov once tried to improve its performance, fortunately, the system came with source code. In my opinion, it would have been better to write our own particle system with proper architecture and cache-friendly data layout.
For this game, I also wrote an external level editor. I developed it at home on Linux using one of my older engines. Of course, the release version was for Windows, as the game designers were using Windows computers.
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.
