A New Roguelike Project

Roguelikes really suit my programming style: they can be ASCII based, which makes creating the graphics very easy, and they are usually grid based, so positioning entities and checking for collisions is simple.  This means that I can spend more time actually creating a game rather than writing all that boilerplate collision and graphics code.

I wrote my first roguelike (Astro Commander) several years ago; it was based on what I thought FTL was like, having never actually played that game.  I've now decided to write another roguelike, after deciding that 3D graphics are too much hard work.  Also, I wanted to have another go at creating an even-better ECS system.  And of course, the theme of the game will be a classic Spectrum game: Alien (Mind Games).

In this game, you will control the crew of Nostromo.

Do you know, I always feel I should write about the games I create in order to "get them out there".  However, when I'm excited about a new project, I prefer to spend my time creating it (rather than writing about it and taking screenshots).  Once this excitement has passed and I've completed all the interesting challenges, I'm then too disinterested in the project to bother writing about it, since I'll probably start another project and won't look at this again.
 
If you want to look at the source code, it's here.  It contains a good ECS system, and units can walk around.  But now I've decide the writing a co-op game is my next project, maybe in Unity.

What is an Entity Component System?

Let's assume you've written a game.  Imagine you've split your game logic into several well-defined classes, e.g. a movement class, a collision class, a drawing class.  Let's call them "systems".  Each has a specific and obvious role.  Also imagine that your game has a bunch of "things" that make up the game, such as the player's avatar, power-ups, bullets etc...  Let's call them "entities".

Each entity is basically a collection of data, and depending on what data it has, it can be handled by one or more systems.  For example, if it has "bounding box" data, it can be handled by the Collision System.  If it has image data, it can be handled by the drawing system.

Your game then works by cycling through specific systems that are required to run each game loop, e.g. Player Input System, then the Movement System, then the Drawing System.  Each system then "processes" all the entities that apply to it, e.g. draw all the entities which have image data.  Systems may well call upon other systems as-and-when required.  For example, your Collision System may call upon the Score System if a player's bullet hits a perp.

And that's it!

The advantage of this is that it's very easy to pinpoint which bit of code is doing something.  If there's a problem with the animation, it will probably be in the Animation System.  If there's a bug with collisions, it will probably be in Collision System.  If you need to implement explosions, create an Explosion System.

Designing a game now becomes a task of defining your systems based on what your game is.  Once you have clearly defined and scoped systems, the rest is easy.

I've created a simple ECS system which I use in my games, over at GitHub:  https://github.com/SteveSmith16384/BasicECS

C# Gotcha - "static readonly" v "const"

On the face of it, there seems very little difference between these, apart from one takes longer to type out.  However, there is one difference that could easily catch you out: you can reference a "static readonly" from pretty much anywhere in your code, but until your code gets to the line where it is declared, it will have the default value (typically zero for numbers).

Time for an example:-

public static readonly int size = width * height;
public static readonly int width = 100;
public static readonly int height = 50;

public void Test() {
    Console.WriteLine($"The size is {size}");
}

Yes, this program will output "The size is 0".  Probably not what you wanted.