This is a video game I developed and published as a member of int13 back in october 2004, for PocketPC platforms.
It was designed as a fast-paced "bullet hell" shoot'em up, inspired by Cave shooters such as Dodonpachi and Zun's Touhou Project games—many hours were spent on Perfect Cherry Blossom during the making of Darklaga.
Like all bullet hell games, the player's ship had a tiny one-pixel hitbox right in the middle, which allowed them to weave between hundreds of slow-moving enemy projectiles. Since this was played on PocketPC, the ship was controlled with a stylus, which allowed a very enjoyable level of precision. A grazing mechanic counted each bullet that passed close to the hitbox ; once the graze counter exceeded 20, all the player's power-ups entered an overdrive mode, which could be kept active by grazing more bullets.
The power-up system was the first thing developed, because implementing weapons is fun. From the starting gun that fired slow-moving bullets vertically, the player was quickly upgraded to one of three red weapons: the Laser, which immediately hit what was directly above the player for better, the circular Blades, which caused area-of-effect damage over a short duration wherever they hit, and the Rockets, which were fired in pairs that were launched to the sides and then flew upwards.
Weapons also supported two yellow modifiers: Speed, which increased the fire rate (and for the laser, the damage-per-second), and Multishot, which fired several projectiles, resulting in twelve weapon-modifier combinations (counting the default weapon and modifier).
For each of the twelve variants, there was an overloaded variant triggered by grazing enemy bullets or by picking up an overload-box. Speed and Multishot modifiers went up to 11, and the behavior of the weapons changed : lasers now bent into the direction of movement instead of only shooting straight up, blades bounced off of enemies, triggering area-of-effect damage on every bounce, and rockets became homing.
Because of this, the typical gameplay was to graze bullets whenever possible, to enter and stay in the overloaded state.
Acting as screen-clearing "smart bombs" was the Fury system in the lower left : as damage was inflicted to opponents, the Fury bar slowly filled up, gaining one charge for each third. Consuming one charge turned the player invulnerable and unleashed a barrage of weapon fire on the screen, usually clearing out everything but the bosses themselves.
The third power-up was the blue upgrade, which could be Fury enhancement (filling the Fury bar faster) or the Shield, which made the player invulnerable to being rammed by enemy ships (although bullets were still dangerous).
There were nine levels, cut into three chapters of three, plus an end-of-chapter boss. By the end of the first chapter, all enemy types were introduced ; the second and third chapter added color-shifted variants that had similar but more challenging behavior. There were around 30 different enemy types. Some were damage sponges, others died in a single hit ; some came from the top of the screen, others teleported in, others came in from the sides ; some would leave the screen after a fixed duration, others would stay until killed.
In technical terms, the game was implemented in a subset of C++ that happened to compile in all the toolchains for the various platforms we were targeting. Among the difficulties encountered:
Support for the STL was very bad. The game implements its own arena allocation, and used linked lists for tracking enemies and projectiles. No inheritance either, the game used tagged unions instead to avoid even thinking about different object sizes.
Floating-point support was often software-only, so the game uses fixed-point math all over the place (using 24 bits for the integral part and 8 bits for the fractional part).
Division and modulo was sometimes
software-only, and several compilers failed to optimize
division and modulo by a power of two known at compile-time. So,
instead of x / 64
, the code would be manually
written as x >> 6
.
A few more technical anecdotes:
The game was shareware, so the first level could be played for free. After downloading a small-ish blob of data that acted as a key, the other levels would be unlocked. Of course, the system was cracked very quickly by disabling the "has the blob key been loaded?" check entirely. We had planned for that. When the blob was loaded into memory prior to the check, it would overwrite part of the game's data structures with the correct initialization (essentially, by nulling some pointers that would instead point to garbage). By skipping the blob entirely, those pointers would cause the game to crash somewhere in the middle of the second level.
At the time, several PocketPC variants had GPU chips, but those were very bad, and relying on them would be non-portable anyway. Because of this, Darklaga and other int13 games from the time had their own low-level implementation of graphics primitives: blitting, alpha-blending (with fixed-point math!), additive blending, etc.
During development, the game ran in a PocketPC emulator, but it also ran on Windows by forwarding all instructions to SDL instead. Since deploying to the emulator took minutes, the SDL approach was necessary to have a fast feedback and iteration loop.
The hardest part to implement was the menu system. Since it was not provided by the game engine, I had to implement an entire system with its own rendering logic, controls, internal state, etc.
The level editor was an ugly windows application built with Borland C++ Builder 4. The level format was basically a stream of "spawn enemy" instructions that specified the enemy type, initial location, a few parameters for the enemy's behavior, and several conditions such as "max number of enemies on the screen" or "delay after previous enemy".
The team was fully remote. I was the programmer in Paris, and Ronan Mellec was the artist in Nantes, and we were supported by the core int13 team in Bordeaux, in particular Stéphane Cocquereaumont who took on the many arduous tasks of implementing the graphics and audio library and the build tools for the various platforms, and France Quiqueré on font design, web development, app store relations (or what was then called app stores), and marketing.
I have one big regret about the game: more than a decade has passed since then, and I have long lost my copy of the game source. With modern tooling, modern processing power, and my up-to-date skills, porting the game to the browser would be a great holiday project.