The purpose of this work is to present the implementation of a rule-based procedural generation algorithm used for the creation of a game that mixes two genres: First Person Shooter and Tower Defense. The algorithm creates 3D levels, where there will be added enemy towers to destroy, base tower to defend, generation of enemies that will have different mechanics, being one of them, the destruction or conversion of the base tower and more elements. Each time the player starts a new game, a new map is generated with the elements located in different positions adding roguelikes features.
In this work, we make a PCG system for the creation of FPS and TD game with roguelike features. The rest of the document is structured as follows: Section 2 discusses how the PCG system is built and the components it integrates. In Section 3, we describe how the gameplay is implemented and tools used. In Section 4, we make some conclusions and discuss future work.
In this section, we present our PCG architecture, and we describe our use case of the algorithm implementation in a roguelike FPS - TD prototype.
The architecture of the PCG system is composed for three modules that share data with each other: Map Generation, Tower Spawn Position Generation and The Enemy Generation. The game contains only one level generation, which occurs procedurally each game. With this system, and through the internal modules, it is possible to create new level shapes for the game. Although the enemies and objects are the same, the presentation of the set makes the player always feel that he is in a different game.
The map generator system is a procedurally generated algorithm based on the Random Walk
algorithm [
The algorithm has two parts: the first one to generate the path where the floor tiles are positioned, and the next one to create the walls tiles and give the level the appearance of a dungeon. In this case, the tiles are 3D models to represent the art of the game. The rules on which the algorithm is executed are as follows: the number of iterations, length of walk in each iteration, and whether each iteration starts at a random position as shown in Figure 2. The attributes are stored in a user-modifiable structure.
Once the floor path has been created, a method based on binary values is used to know the location of the wall tile to be inserted, since the walls have different representations depending on the position in which they are located. This method is used twice: once for cardinal walls, and once for diagonal walls. In both cases, we iterate over the list of floor coordinates obtained earlier and depending on the wall type, we add the position of the floor to a cardinal or diagonal coordinate. To create the binary number, we check if the resulting coordinate exists in the list of floor coordinates. If so, then a 1 is added to a string variable. Otherwise, 0 is added. Once we have the string representing the number, it is converted to integer and compared with the list of specified values of each address to obtain the corresponding model.
Once we have both the directions of the floor and the walls, we use a visualization system to place the corresponding model in each coordinate, and finally have the generate map. Figure 3 shows the complete result.
After the map has been generated, enemy towers and the tower we must defend are positioned. In this case, for the player’s tower, it is always positioned at the coordinate (0,0,0), although the visual representation is different, since the map always is different. Enemy towers are placed randomly at the extremes of the map. These extreme positions are positions where both x and z coordinates have minimum and maximum values. In our prototype there are only three enemy towers, so once instantiated on the map as shown in Figure 3, the remaining extreme position is used to place the player.
The enemy generation gets a random position on the map in which there is no key element such as walls or towers to generate an enemy in that position. There is a generator integrated in each enemy tower, and each generator have a different group of enemies and the interval in seconds of generation. When a tower is destroyed, the generator is destroyed with it. In our prototype, we have five types of enemies as shown in Figure 4. Of these enemies, two attack the tower directly (EnemyConverter and EnemyFollowTower), while the rest goes after the player (EnemyGun and EnemyFollowPlayer) or remains blocking the map (EnemyRadar).
The proposed PCG system was developed for the game with the code name: Project Survivor. In the game, the player’s mission is destroy the enemy towers before the enemies convert or destroy the player’s tower or kill the player. If the tower is converted, all enemies target the player and increase their speed to reach and destroy it, greatly increasing the difficulty of the game. In case of destroying it, the game is simply over and a new one would have to be started from scratch. In this pre-alpha version of the prototype, the enemies have a basic artificial intelligence performing the behaviors described in section 2.1.3 and the player has only one weapon available.
The game was developed with the Unity game engine [
After testing the game when this pre-alpha version has been completed, it has been found that it is necessary to adjust the generation times of enemies and add obstacles to slow down the player’s progress, and on several occasions, it has been possible to reach the enemy towers with easily. Apart from adding new weapons for the player and objects of healing and destruction.
In this paper, we propose an algorithm capable of generating the game and level structure for a game that mixes the FPS and TD genres. During the development of the game, enemies have been designed to challenge the player, such as enemies that directly target to the base tower. In future works, new skills, items, enemies, obstacles, and different challenges for the player will be implemented. Also, add extra complexity to the map by making it smaller every so often, generating the redesign procedurally but respecting the current state of the elements on the map. In addition, playtesting sessions with external users will be carried out to collect as much data and feedback as possible and make the appropriate changes.