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.
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.
«Brainfuck придуман Урбаном Мюллером (нем. Urban Müller) в 1993 году, известен своим минимализмом. Название языка можно перевести на русский как вынос мозга, оно напрямую образовано от английского выражения brainfuck (brain — мозг, fuck — иметь половое сношение), т. е. заниматься ерундой. Язык имеет восемь команд, каждая из которых записывается одним символом. Исходный код программы на Brainfuck представляет собой последовательность этих символов без какого-либо дополнительного синтаксиса».
Yesterday marked the deadline for submissions to the international Ludum Dare game jam. Developers are challenged to create a game from scratch in 72 hours (for the jam) or 48 hours (for the compo) based on a given theme.
Our team of four created Ultimate Question 42 in just 72 hours. I took on the role of programmer and technical specialist (well, what else could I do? :)), Shevadzutskiy Alexander was our game designer, and Artem Khodas and Dojo handled the art.
On the morning of the first day, we learned the theme, brainstormed ideas, and dove straight into development. By midday, we had a rough concept of the game, and by the second day, we had a playable version.
We decided to build the game on my engine directly for the Web, as it allows immediate testing without installing anything on desktop or mobile devices. A native Linux version is available on the project site, and I can run the iOS version on my smartphone. In the future, we plan to release public versions for iOS, Android, Apple TV (tvOS), Android TV, and Facebook Instant Games.
Although I was completely exhausted by the evening of the third day – like a squeezed lemon – I was incredibly satisfied with our work. Our team functioned seamlessly; everyone clearly understood their responsibilities, and in the end, we delivered a great result.
You can find the official Ludum Dare page for the game here: Ultimate Question 42
Smart Tiles is a logic-based strategy game where you merge identical tiles on a square grid to create higher-value tiles. Plan carefully, analyze your moves, and reach the top by achieving the tile with the highest value. Fast-paced yet engaging, it’s a brain-teasing challenge with strategic depth.
I developed the game from scratch in just a week. My goal was to finish it in five workdays, but it ultimately took seven. Most of the extra time went into the “small stuff,” like game balance and minor polish. The background music and sound effects were sourced from Sonniss.com, which recently released 30 GB of WAV 44kHz audio for public use.
Originally, I planned to release the game on Facebook Messenger, but versions for Android and iOS came out “automatically.” The development was done on macOS, using my own C++ engine – yes, for macOS, from macOS.
Way of Tanks is a tank runner game with endless gameplay and diverse tracks. Players control a tank using swipes, keyboard buttons, or Apple TV gestures, aiming to cover as much distance as possible without hitting obstacles or dying in boss battles.
The tank can switch lanes, shoot, and even jump over trenches – yes, it’s that kind of modern tank! The game features various power-ups that temporarily enhance the tank’s abilities: agility, super shots, doubling collected coins, or the ability to break through obstacles.
Players can also use coins collected during runs to purchase new tanks or upgrade existing ones. There are four tanks in total, each with unique stats and capabilities.
With the permission of Ogurec Apps, I took on porting Way of Tanks from Java to iOS, tvOS, macOS, Linux, and Web, using my old but familiar and convenient game engine. The game is now ready to be handed over to its owner, though I retain the source code of both the game and the engine.
The game is already available in the browser – Way of Tanks. Hopefully, it will soon appear on the Apple AppStore for iOS, tvOS, and macOS. As for Linux, the decision rests with Ogurec Apps, but I really hope they won’t mind.
Road Fighter is an arcade racing video game developed by Konami and released as an arcade machine on December 7, 1984. Later, versions were released for MSX1 computers (1985) and the Nintendo Entertainment System (1985 in Japan, 1991 in Europe).
In 2003, Retro Remakes organized a “remake competition,” where participants were challenged to recreate a game from scratch in a short time. The team Brain Games decided to participate with a remake of Road Fighter for MSX.
What I did
The source code of the game was available on the Brain Games website, which I used. I informed the original clone author about my work – amusingly, he was happy and said he was looking forward to the web version.
First, I did a small code refactoring to make the game compile with a modern compiler using the “modern” version of SDL 1.2. Then I performed a larger code refactoring – dividing the code into logical parts and making it readable (here, my favorite VIM and clang-format were very helpful). Next, I had to make fixes to the sge library code required by the game.
After that, I ported the game to Linux and macOS, and six months later, I finally completed the port to Web.
Main challenges
The Web version was the most troublesome. At first, the game wouldn’t run at all – this was because the main loop needs to be slightly different for Emscripten (and generally for any properly designed architecture).
The next issue was clearing the screen (or filling it with black). You can’t just use zero; the zero must have an alpha of 0xff.
Later, the game seemed to freeze when loading a level – it turned out it wasn’t frozen, just very slow to load. I had to make many optimizations, mainly related to direct access to SDL surfaces. I solved this by removing Lock/Unlock calls from the main loops.
Another problem appeared when the car spins after a collision and skid marks must be drawn. Drawing lines was extremely slow, and they were never cleared even when off-screen. Moving the lock outside the loop and clearing the line list solved the issue.
I also improved file system handling, video and audio initialization, and music and sound loading. There were many changes – too many to remember. Anyone interested can compare the original game (the first commit) with the current master branch.
I might eventually add save-state support for the Web version. It’s not hard – synchronizing the “local” file system before reading is sufficient. IDBFS is perfect for this, but I haven’t gotten around to it yet.
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.
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.
