Defining alien attack formations in a retro shoot em up

In our last game, Thundergun, we adopted a purely randomised approach to generating the levels. That is, the alien formations were predefined prior to the game loading but their formations for completely random.

For our next game, Akari: Battlestar (working title), we’re looking to plan the action with far more precision.

Our inspiration for this game is from the early 1990’s and games like Raiden.

Raiden was a tough game. Very tough. Our game will hopefully be a little more forgiving in the style of what were once referred to as manic shootersDo Don Pachi epitomised this style in which you pitched your fighter against hordes of formation-based adversaries who sprayed bombs (with some elegance) around the screen. Under normal circumstances avoiding the bombs would be nigh on impossible. But this genre used much tighter collision detection; often using just a single pixel in the centre of the player’s ship for collision reference.

We’ve already adopted a similar approach.

But it’s the fighter formations we’re keen to establish up front by way of an in-house level design system. The placement of aliens, cannons, collectables, mini bosses, tanks; you name it, will be handled by this system. Each entity will have all attributes defined and the resulting output stored in a JSON format to be read by the game.

The attack formations for Thundergun were based largely on Capcom’s 1943.

Fighters swooped in, curled around and then flew off. If you took the entire formation down you were presented with a bonus item.

For Akari we want to have a lot more variation.

Fighters will adopt one of several attack formations.
e.g.

  • Drift down from the top of the screen, pause, fire, drift off to the side
  • Drift in from the side, fire bursts, drift off to the side
  • (Tanks) trundle in from the side and follow a set path
  • Squadron formations from the bottom of the screen that fly off screen and return in slow formation

For Thundergun we introduced the concept of a game progress ticker. In code this was defined as part of the global namespace g{} and referred to as g.progress

g.progress bumps with every tick of the game’s main loop. This is consistent and in tune with everything else that the game loop handles (movement, animation, collision etc) so it’s a good base for defining the introduction of alien formations.

As g.progress counts its way through to several thousands for each level it passes what we refer to as waypoints. As each waypoint is triggered a new randomly but predefined alien formation is spawned.

The difference with Akari is that there will be no randomisation. Everything will be delivered from a level data file.

At set intervals in Thundergun the action was interspersed with a mini boss; a larger fighter that drifted into view and bullied the player. Formations continued to spawn around it.

For Akari we’ll suppress the formations and halt the bumping of g.progress while the mini boss action plays out.

With the mechanics for the mini boss developed we have pretty much 90% of the code written to handle a proper end-of-level boss. The main difference will be in defining the scale of the boss and any sub-elements such as wing-mounted cannons.

Level structuring isn’t a new thing for us. We’ve employed it for our platform games and the C64 style shooter Crossfire.

Hopefully we can get a demo up and running in the near future. Exciting times in arcade game development!