A classic solitaire game. At the moment, only the latest version is available – it features improved graphics, animations, and two dealing modes: draw one or draw three cards.
This solitaire was the first game I created at Synesis, using the very first version of our engine. You could say it was a real-world test of the engine’s capabilities.
The graphics, animations, and sound effects were handled by the rest of the development team. The game supports both landscape and portrait orientations, and the layout switches automatically when the device is rotated, regardless of the current game mode.
Solitaire saves the player’s current progress, so you can pause the game and continue at any time.
The game also allows you to customize the appearance of the cards and the table. It keeps a full history of moves that can be undone at any point. Naturally, double-tapping cards works as expected. And if a player gets stuck, there are hints available to help them out.
The first attempt to create a classic stacker game in an isometric projection was made at Synesis. The custom engine and game code, written in C++, allowed the game to run on multiple platforms simultaneously – Android, Android TV, iOS, and Apple TV. Development was done on macOS, so the game also ran perfectly on macOS. The engine even allowed the game to run on Windows.
This game belongs to the category of my creations that I’ve enjoyed playing for many years.
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.
Весьма занимательное чтиво об истории становления компьютера ZX-Spectrum, Клайве Синклере и компании Sinclair Research.
Не все то золото, что блестит.
Цветной, с полноценной клавиатурой, дешевый
К декабрю 1981 года количество проданных ZX81 превысило 250 тысяч. На волне этого успеха, как пена, всплыли недостатки, свойственные полукалькулятору-полукомпьютеру, которым, по сути, и являлся ZX81. Прежде всего, это было отсутствие цветной графики и недостаточный даже по меркам 1981 года объем ОЗУ (RAM). И если недостаток памяти компенсировался низкой ценой и возможностью «прилепить» дополнительные килобайты в виде коробочки RAM Pack, то отсутствие цвета было для ZX81 неисправимо.
ZX-Spectrum 48
В начале 80-х годов в Великобритании больше половины выпускаемых и импортируемых телевизоров — цветные. В Америке аналогичные показатели достигали 80%. Черно-белый компьютер, подключенный к цветному телевизору, выглядел «инвалидом». И хотя на витринах компьютерных магазинов уже красовались цветные Apple, Commodore и Acorn, сделать очередной ZX цветным было очень непросто.
По аналогии с предыдущими моделями, в качестве монитора предполагалось использовать телевизор. Только теперь вместо черно-белой картинки (ZX80, ZX81) нужно было передавать цветную. Сложность состояла в формировании качественного видеосигнала в стандарте PAL. Далее сигнал преобразовывался в высокочастотный (UHF). Это позволяло подсоединить телевизор через антенный (UHF) вход. Добиться качественного изображения было непросто, но такое решение давало максимально простое подключение.
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.
A hidden-object game with a mystical yet detective-style story. The player must move between the real and mystical worlds to solve various tasks.
The game features a range of logic and arcade mini-games. The game was developed on a modified HGE engine using SDL libraries. Target platforms were Windows and macOS, while development was carried out on Linux. Versions for Windows and macOS were sent to publishers, but the Linux version remained on the development computer.
For a time, Between the Worlds was at the top of iWin’s publisher charts.
Two versions of this game were released — one for DOS and one for Windows.
1997 and 2002
It was a classic Tetris that included several variations: Tetris, Pentix, and Color Tetris.
What made this Tetris special was its support for network play with up to 5 players. When a player cleared two or more lines at once, random blocks would be added to the opponents’ wells.
The DOS version was written in Borland C 3.1. Apart from the network mode, its distinctive feature was a Windows 95–style interface. The network was implemented over the IPX/SPX protocol.
The game was written in C entirely from scratch, without any engines or third-party libraries, except for the IPX/SPX library. For graphics output, it used direct memory access. On startup, the game created interface elements in a memory area outside the visible screen, then copied them into the visible part for rendering. Because of this approach, the game wouldn’t run under Windows 95, even in compatibility mode. Unfortunately, the source code for this version has not survived.
I couldn’t find a screenshot of the DOS version.
If I recall correctly, the Windows version was written in C using Visual Studio 6. For the engine, it used the CDX library. The game had a client-server architecture: any player could act as the server, and the others would connect to them. It ran over TCP/IP. Thankfully, I was able to preserve the source code for this version.
Windows version in normal mode
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.
