My first few years of university, I spent a lot of time working on a 2D space shooter called Abendstern. It ultimately didn’t end up going much of anywhere, and not for lack of it functioning well as a game. In the hopes of being able to try this again, I look back on why Abendstern ultimately failed.

Genesis and Evolution

Abendstern grew from a desire to have something similar in play style to Twisted Metal, but with user-constructed vehicles. This ended up moving to space and two dimensions due to the simpler physics and not needing real assets such as environments. I finally started on the project near the start of my freshman year in 2009 with the goal of actually getting competent in C++ and OpenGL along the way.

The general design was that the player would place “cells” to define the physical structure of their spacecraft, and then place “systems” in those cells to provide functionality such as power generation, engines, and weapons. Originally, the game was to use a simple oval for each ship as their collision boundary and a simple HP counter for damage (justified as a Star Trek-style shield); switching to precise collision detection and per-cell damage and destruction added a huge amount of depth to ship design and is one of the best changes to the original design. In the final version, a typical ship looks like this:

Development continued until December 2012. The final build has quite a bit of stuff in it: full network support, a ship editor GUI, strong AI, and a fairly diverse set of play modes. The fact that it works at all, much less fully stably, is perhaps a miracle. The code base has no tests whatsoever and contains many… very strange things which I may talk about another time. You can still download the Windows installer or struggle through building it yourself if you care to; everything does still work other than Internet features since the server has been shut down.

Death and Decay

Development ultimately ceased due to a few interrelated factors:

• Increasing code maintenance burden, making further development progressively slower.

• Loss of existing players. I had had two loyal players for much of development time, but they eventually lost interest. There’s not too much else to say about this point, though it is presumably related to slowing development due to the above.

• Inability to get new players.

The Game Engine is Expanding, to Meet the Needs of the Expanding Game Engine

Perhaps unexpectedly, the maintenance difficulties were not a result of the lack of tests or other insanity. Rather, the largest problem was a matter of scaling performance to match the ever increasingly-complex player-designed ships.

The engine was written with the expectation that a ship with 30 cells would be “very large”. This assumption is still pervasive through a lot of the code, including some O(n²) algorithms in the ship physics calculations. But by the time development ceased, the majority of ships had two to three hundred cells, with a few in the thousands.

At the time, I simply thought the equilibrium point for ship size was simply higher than I had planned. But tweaking parameters didn’t accomplish much; expansion stalled for a short while we three players adapted to the change, and then resumed with the steady expansion. Thus I was forced to optimise for larger and larger ships, resulting in an increasingly complex and contorted code-base and increasingly more work to introduce new features.

It wasn’t until long after development ceased that I realised this expansion was due to a flaw in the game design. A ship with an overall radius r has an area proportional to r², and so the total power output, engine thrust, and weapon count could also go up with r². However, a ship’s vulnerability depends on its cross-sectional area, which only goes up linearly with r. So increasing a ship’s size by factor k would improve its combat ability by k² with an increased risk of k; in other words, the ship’s overall strength increased linearly with size. The only thing that slowed expansion was the task of progressively learning how to effectively construct larger ships.

Noobs Need not Apply

Abendstern has almost nothing to assist users new to the game. There is no explanation of how to construct ships, no introduction to the controls or mechanics, and no way to make single player easier other than a slider to set a damage multiplier. I always put it off because it seemed like something that could wait till the game was more complete. The result was a game that is almost completely unapproachable by new players.

The two other players had been introduced to the game when it was only a couple months old. There were not many mechanics yet and the AI was so simplistic that anyone could deal with it. The only way to add new ships to the game was by opening a text editor and typing the ship in by hand, like this:

e {
 n10s s0pc30 s1xd {
  n20s s0pu s1xs10 3.5 {
   n20s s0pu s1pu {
    n20s s0pu s1pu {
     n20e s0pu.
    }.
   }.
  }.

  n13s s0eb s1wp {
   n13s s0pc30 s1pc15 {n00e s0pc30. n20es0pc30. n10r s0eb.}.
  }.
  n31s s0eb s1wp {
   n31s s0pc30 s1pc15 {n00e s0pc30. n20e s0pc30. n32r s0eb.}.
  }.
 }.
}
.
1.3

As a result, the two players essentially “grew up” with the game, learning new features and mechanics as they trickled in. New players did not have this luxury, and would need to figure out on their own, e.g., that a viable ship needs power, capacitors, engines, and weapons at minimum.

The lack of an introduction exacerbated the confusion caused by the unconventional control scheme and some unusual terminology. Most notably, what most games in similar genres would have as numbered “tech levels”, in Abendstern were instead “classes” following the lettering scheme most prominent in Japanese racing games.

Finally, there was the AI. Since there were so few players, online play was generally not viable, so one would need to play against bots. I was always dissatisfied with the AI, and went through six or so major redesigns, four of which were leaps and bounds better than the prior. But it always felt just a little too weak. Little did I realise that this was because I was becoming more skilled as a player.

I discovered the hard way that the AI had actually gotten to the point of being on-par with a moderately skilled human player. I had convinced someone new to give the game a try. He had just started the game and was still trying to get his bearings, when an AI in a Tintenfisch wandered over. The AI know no mercy, and the player was killed in under a second.

A contributing factor here is that Abendstern was strongly focused on symmetric multiplayer. Bots had to be reasonably human-like in terms of skill and behaviour in order to be challenging to established players, and there is no difficulty progression. Contrast this with other single-player games in similar genres, which often pit the player against a larger number of allied low-skill enemies, and use a level system or similar to start the game easy and naturally progress to greater difficulty.

Rebirth

Abendstern’s demise has always made me a bit sad. It took me a long while to understand the various game design problems, but I’ve recently had the inspiration to start working on a complete redesign, tentatively named Hexeline, which will be the subject of an on-going series of posts. Hopefully I’ll be able to take what was learned from Abendstern and make something a lot better.

Some of the improvements are pretty shallow and don’t bear much discussion. “Use a control scheme which actually resembles that of similar games”; “Put a tutorial system in sooner rather than later”, etc. The deeper changes are more interesting.

Firstly, symmetric multiplayer will be de-emphasised in favour of a more arcade-like single-player experience where the player faces more, but weaker, enemies. This makes room for a simple difficulty progression to allow new players to get their bearings.

Instead of a separate ship construction mode, players are given a preset ship which they can modify in-game as they accrue resources. For new players, this means they do not need to learn the whole system immediately, but can make “obvious” improvements to the ship and then discover the additional requirements (e.g., needing more power) as they become a problem. For experienced players, it increases the dynamism of the game, since they do not simply start with their ideal ship at time zero.

The final big block is the problem of eternal ship expansion. The solution actually comes by adapting the heat mechanic from Abendstern. In Abendstern, a ship had a temperature meter; certain actions would increase the temperature and could not be performed if it was too high, but during inactivity temperature would decrease naturally. In Hexeline, temperature will be distributed on a per-cell basis through the ship, far more things will produce heat, and heat can only be radiated away via the exterior of the ship. Since most components will produce heat, a ship with radius r will generally have around r² heat-producing systems, but only surface area proportional to r, making a ship bigger will make heat problems worse or require making contorted, fragile designs to increase surface area.

There’s a lot more to say about Hexeline, but it will need to wait until later posts. Next time, we’ll take a look at coordinate systems.