32Blit roguelike: Scope and moving player

Inspired by 7DRL (7 day roguelike), I have decided to try to get a simple roguelike gaming up and running for my 32blit beta unit from Pimoroni.

Since I have never actually made a roguelike and only played a few, I know I’m not going to make a new revolutionary roguelike as my first try.

Instead, I am using this project to get a feeling for the basics of the genre, and then hopefully use this new found knowledge for other projects in the future.

In this post I will define the intended scope for the game and get player moving on the screen.

Scope

My main goal is not actually to make a finished game, but it would of course be nice, it I have something playable at the end of this project.

Instead my goal is to get an understanding of how to implement the basic mechanics for a roguelike game. Because I am fairly new to the genre, I will use some of the steps from the “RoguelikeDev Does The Complete Roguelike Tutorial” as inspiration.

I will focus on making a simple game, with only a few possible actions, items, upgrades etc.

Moving the player

The first thing I implemented, was moving the player around the screen. This actually turned out to be a bit more complicated than I first assumed.

Moving the player is not difficult in it self. But since this is a turn-based game, the game loop works a bit different than I am used to.

I am reusing a simple game object-component system I already made for the Bubble Bobble clone I am also working on the the 32blit. However, this system works by calling update functions on each component every time the 32blit update function is called.

This does not work for a turn-based game, where we have to wait for player input. We could of course wait to call all the update functions until the player has chosen an action. But if we only update after each player turn, then everything will freeze while the player is making her/his choice. In some cases this is okay, but if we want things like animations to keep running, we have to keep updating even while waiting for player input.

To solve this I added a tick function to my gameobject and component classes. The tick function is then use for the turn based actions and the regular update functions are used for things that might have to keep running.

I also added the two states PlayerTurn and Running. If the current state is Running, all game objects will tick, and if the current state is PlayerTurn the 32blit update function will look for player actions. For both states we will also call the regular update functions for all game objects.

The 32blit update function then acts like the following

UPDATE
    process input
    if it is players turn:
        state = PlayerTurn
    
    if state == PlayerTurn:
        if there are new actions
            handle player actions
            state = Running

    if state == Running:
        tick game objects

    update all game objects using regular update function

Drawing the player

Since I want to keep this game simple, I am so far drawing all game objects (including the player) as coloured squares. But I also have an idea I might reuse the code for later, where I will be using 16×16 sprites. Which is why all the squares are also currently 16×16 pixels.

That is it for day one 🙂

Turn-based player movement