Author: Robbert

In my sword and sorcery game Altar’s Gold, three menus for the player to handle items have now been defined: inventory, equipment, and floor. Only one menu can be open at a time.

The floor menu shows items near the player and allows for items to be picked up. If a suitable equipment slot is still free, the item is equipped, otherwise it is stored in the inventory if space is available.

The inventory menu offers options for either dropping a selected item to the floor, or to wield it. (I changed the verb ‘equip’ to ‘wield’ so W is the key for wielding an item and E is the key for switching to the equipment menu.)

The equipment menu lets the player store a selected item in the inventory, or drop it to the floor.

I am now working on the behaviour of computer controlled entities. In the video above the new ‘grave robber’ entity (using the player animations) is wandering about randomly, paying no attention to the player. The plan is to have basic combat between the player and other entities, so that a bit of gameplay is possible and an ‘in development’ version can be published on itch.io.

The past month I have been working on an inventory and equipment system. In the video below the result so far can be seen. When the player walks into a sword, they pick it up and it is added to their equipment, if the correct equipment slot is still free. Otherwise, it is added to the inventory. All of this is implemented using a set of new components and systems. One component can mark an entity as an ‘item’, so it can be picked up by entities who have an ‘inventory’ or an ‘equipment’ component.

Graphically, this involves sets of coordinates to define the relative location of a carried item during an animation, defining both the equipment slots in the equipper’s animation frames, as well as the location of the ‘handle’ in the item frames. By pressing keys i or e the player can view inventory and equipment menus. In the future these will allow the player to manage their items.

The plan is for there to be a floor menu as well. Picking up random things by running into them can be undesired in the midst of battle, so this is perhaps better handled in a menu showing what items are on the floor nearby. It is yet to be discovered to what extend browsing through menus and pressing the right keys is acceptable during battle. 😉

My sword and sorcery game, using the working name action-rogue up to this point, is now called Altar’s Gold. An ancient altar, which according to stories is filled with treasure, is hidden deep within a dungeon below the ruins of a fortress.

In the previous post I described how I switched to a more elaborate ECS (entity component system). Already a bit before that, I decided to abandon the idea of the player sprite containing a sword and a shield. To have the option of using different weapons, such as those found in the dungeon, the graphics of the player and the weapons needed to be separated. This fits with the new ECS approach: the player is an entity, but swords and shields are also entities. The player entity is made up of components that make it possible for them to move around the dungeon using keyboard input, while a sword entity cannot walk but instead has components that allow it to be picked up and wielded by other entities such as the player.

Therefore I remade the player walking animation, this time without sword and shield. Of course this will require displaying weapons in the correct location and orientation during walking, attacking, etc. On the one hand this make everything much more complex that I had perhaps planned originally. On the other hand, once it works it will allow for a richer game.

While working on my action roguelike, which up to this moment was using an ‘Entity’ type, I ran into the point that in App Game Kit, it is not possible to store a reference to one type instance in another type instance. For example, while it is possible to have a property ‘sword’ of type Entity, this will then be the actual instance of the sword, and not a pointer to a sword stored elsewhere.

This was a bit of a setback. (Though I can appreciate that in the AGK language, pointers have not been added, to keep things simple. On the plus side, passing an instance by reference into a function is supported.) One alternative way of pointing to another entity would be the use of indexes. For example, a property ‘sword’ would hold the integer index into the array of all entities. This did not seem like an appealing solution. However, this did make me think of how in an entity component system (ECS), entities are represented by integer ids.

While I was already creating a kind of ECS, up to this point I was using an Entity type, containing components as properties. In more elaborate entity component systems, an entity is represented only by an integer id. Components are stored in arrays (or other suitable containers), and the integer id is used to find the set of components that make up the entity. In such a system, it is also much more natural to refer to another entity by simply mentioning its id.

So I started rewriting my code so far, to use this new approach. There now is an array for each component type. Since AGK does not support the null value for missing instances, each array holds a component instance for every entity, but the component itself has an ‘active’ property so it can be disabled by default. The integer id of the entity is also the index into the component arrays.

The game now has a simple line of sight algorithm. Its simplicity is based on the restriction that the game world is made up of corridors a single tile wide, and does not contain larger open spaces. Line of sight is therefore always along corridors, in four directions. In addition, tiles that are directly adjacent to a visible corridor are also visible, so you can see around the corner a little bit.

Visible tiles are drawn in full brightness, explored but not currently visible tiles are darker, and unexplored tiles are empty. Only entities that are on a visible tile are drawn.

Previously the scrolling engine was configured to stop scrolling when the view reached the edge of the world. Knowing that the game will likely display status information near the edges of the screen, this means the player could be walking underneath this information. It also restricted rooms to be at least as large as the screen.

Therefore I have changed it so the scrolling continues past the edge, showing black space outside the world. Now the player will always be displayed around the center of the screen. (There is an area in the center of the screen where the player can walk without scrolling.)

A message system has been added that can be used to display what just happened to the player. New messages are stacked on top of the previous ones, while older messages fade away. The font used in these messages is ‘Alagard’ by Hewett Tsoi and was downloaded from dafont.com. The game now also supports other entities in addition to the player, featuring rats, to begin with.

A typical part of roguelike games (and of roguelites, the category my game would probably find itself in, described on the same Wikipedia page) is their randomly generated dungeons. I did a quick search for maze generation algorithms and decided to use Randomized Prim’s algorithm as it did not appear too complicated.

This algorithm starts with a grid that has every cell filled. A random starting location is picked that is cleared. Then all neighbouring filled cells are added to a list. A random cell A is picked from the list and we check if it does not have at least two cleared neighbours yet. If this is indeed not the case, the cell is cleared and its filled neighbouring cells are added to the list. Cell A is removed from the list. A random cell is picked from the resulting list and we check if it does not have at least two cleared neighbours, and so on, until the list is empty.

This worked fine, except for the fact that my first implementation was better suited for grids in which walls are defined as closed edges of cells, taking up no space on the grid. Instead, in my game, a wall is itself a filled cell on the grid.

This problem and the solution were found on this Stack Overflow page. The solution is to move in steps of two cells when collecting a cell’s filled neighbours, leaving space for the walls. This gave a nice result.

In the future I can perhaps add even more variation by adding or removing random pieces of wall to the outcome of the algorithm. The outcome of the algorithm described above is a maze where every open cell can be reached; an important requirement, when adding or removing walls, is of course for the maze to remain solvable. A pathfinding algorithm, which will at some stage be needed to help computer controlled characters find their way around the maze, could play a role here as well.

App Game Kit offers a function that sets the depth of a sprite. The depth values are used in deciding the order sprites are drawn in. A sprite drawn after another sprite, will be drawn on top of or ‘in front’ of that sprite. This is now applied in such a way that the floor tiles are always drawn first, while the drawing order of the player and the wall tiles is made to depend on their vertical location on the screen. For example, a wall lower on the screen than the player is drawn after the player, so that the wall is in front of the player.

To give the player something to disappear behind the wall tiles were made a bit taller. I have not made them so tall as to completely hide the player and other game characters. The small dot indicating which way the player is looking, is always drawn on top of everything, as it is considered part of the interface.

As the game will feature levels that are larger than the screen, it now has a scrolling view on the current level. The player will be in the center of the view, except if the view is close to the edge of the level, at which stage the view stops scrolling. The level is made up of 16×16 tiles. Tiles can be walkable or closed. At a later stage the tiles, or what is depicted by them, such as walls, will be drawn in such a way that the player can disappear behind them or walk in front of them, corresponding with the side-on view of the player.

The view upon a portion of the world is implemented as a fixed set of sprites. The image that is assigned to each sprite depends on its corresponding location in the world at that moment. To achieve the effect of a viewport moving to the right, to keep up with the player, all sprites are moved to the left. When the sprites have moved more than the width of a tile to the left, all horizontal sprite positions are reset and their images are reassigned. In this fashion the image of a piece of wall will ‘move’ across the sprites.

This approach is not my own idea, I actually read about it on the App Game Kit forum, for example in this post: ‘Tile Based Map Scrolling – The most efficient way?’ In the demonstration seen above, the viewport was intentionally made smaller than the screen, so that the effect of the tiles being reset is visible. In the final game this effect would fall outside of the screen. (Although in some games such a smaller viewport is of course deliberately used to limit the distance the player can see ahead. I am not sure if my game will do that, but in that case the edge effect would have to be hidden by other means.)

Over the past holiday period I have given some attention to my game, codenamed ‘Action Rogue’. It now has a player sprite, animated in four directions. The player can move in eight directions, so animations are re-used for the diagonals. It is also possible for the player to move their shield forward, and to strike with their sword. I imagine the player will walk through a tile-based dungeon system, encountering opponents with similar abilities. The attack animation starts with the character moving their sword back; this movement and the delay before the strike is carried out, will allow for opponents to respond. The shield animation is slightly quicker than the sword animation to make a blocking action possible. A small dot has been added to make it easier to see which way the character is looking.

I am applying a keep-it-simple programming approach to this game. For example, instead of writing complicated systems for carried items, allowing for the player hands to also be empty, the code currently knows nothing about items, and just uses a sprite that happens to include a shield and a sword. This allowed me to skip directly to block and attack animations. The complicated systems may still be added later as needed. In this manner I think I can more quickly create actual gameplay.