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.
Walls are edges of cells
Walls are cells themselves
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.
Part of a maze generated by the randomized version of Prim’s algorithm
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.
The player walks between the walls
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.
Demonstration of the scrolling tiles making up the viewport
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.
Animations in four directions
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.
Welcome to my new website. I decided to use WordPress so I can also write a blog post every once in a while. While setting up the list of my games on this new website, I also tested those games and it turned out many did not work properly anymore on my Windows 10 pc. For example, my Blitz Basic games from before 2007 had issues with audio playback or did not properly support alt-tabbing. So I have removed those games from the list.
Then I decided to try App Game Kit Classic (AGK) for a new game. This is a game programming engine by The Game Creators, who also made Dark Basic. Dark Basic of course was the big competitor of Blitz Basic! AGK is still used, maintained and receiving updates. It allows for games to be published for many platforms, including Windows and Android.
The game, codenamed ‘Action Rogue’ for now, is to be a 2d action ‘Roguelite’ game. Specifically, the player controls a character wielding weapons and shields, fighting opponents in a randomly generated dungeon. The plan is to keep the action relatively slow paced. I have not written a design document, instead I just started writing specific code for displaying and moving a character. This way I hope to be able to see results in the form of enjoyable gameplay sooner, and not lose interest before that point is reached.
The AGK interface, showing its functional (not object oriented) programming language and the simple beginnings of my game
This WordPress website replaces the old Foppygames website. Here I can maintain a blog as well as provide a page with my finished games. The website is currently under construction. In the meanwhile my games can be found on itch.io.
