Engine: Corona SDK
Platform: iOS
Development Time: 16 weeks/640 Individual Hours
Team Size: 2 people (+2 part-time, contracted artists)
Description: Fallen Kingdom: Tactics is a turn-based tactics game prototype set in a dark fantasy world. It takes inspiration from games such as Space Hulk, Final Fantasy: Tactics, and Diablo II. The player controls a small squad of specialized, powerful units against an unrelenting horde of undead enemies in the thrall of the fallen god, Ithun. It targets iOS devices, and as such has a strong focus on touch controls, short play sessions, and replay value through character levels and procedurally generated levels. This game serves as a thesis artifact for myself – my thesis was on how player performance could affect the procedural generation – as well as fellow developer Jon Sova, whose thesis was on the Timed Action Sequences within the game.
Core Responsibilities:
• Designed, developed, and implemented the procedural level generation system – which included the generation of floorplans, the placement of gameplay and decorative objects, enemy count and placement, and the drawing of walls.
• Designed and implemented five different per-floor objectives to incentivize player exploration and vary gameplay.
• Created detailed Excel sheet to track gameplay variables and allow easy balancing for five classes against five enemy types, across twenty-five player levels and nine tiers of dungeon progression.
• Designed and developed the enemy AI and lighting systems.
Level Generation Process:
• Divide playspace into quadrants and generate rooms within each quadrant
• Grow hallways from doorway seeds in each room
• Generate a secondary objective for the player
• Place level features in the level
Generate Rooms
The room placement algorithm began by determining the level size based on the depth of the floor. It then divided the playspace into quadrants. It then placed between one and four rectangular rooms of varying sizes in each quadrant. The system allowed some rooms to overlap, which created more interesting room shapes. Difficult levels featured larger rooms, as these provided the player with fewer pieces of cover to use. Desired difficulty was determined by the current floor depth, the dungeon maximum depth, and the number of living player units.
Grow Hallways
After the system established the size and location of rooms, it called a separate L-System algorithm to connect rooms via hallways. L-Systems can grow large series of hallways using a fractal-like model of string rewriting. This algorithm began by determining the number and position of exits for each room. It then determined the specific parameters of the L-System used to grow the hallways from these exits. The game state influenced these parameters, feeding values that created more corners and difficult pathways when it determined the player needed a bigger challenge. If the player was consistently completing objectives and escaping floors with little trouble, the system compensated by generating floors that were more difficult. Using each entrance as a seed, the system grew a series of hallways using an L-System. Each seed ceased growth once it intersected with another hallway or room, or the edge of the level.
Select Objective
After creating the rough floor plan through the room and hallway algorithms, the system chose an appropriate Objective for the player. It did so by taking the overall difficulty factor for the floor and using this information to determine an appropriate Objective difficulty. It then randomly chose an objective that fell within acceptable range of the difficulty from a list of possible objectives. Each possible objective had a designer-determined difficulty level.
Place Features
The final step of level generation placed features around the level. These included any objective-required objects, such as destructible statues, tokens that represented enemies that get generated when they enter player line-of sight, and the entrance and exit for the floor. It placed the entrance and exit randomly along walls in opposing quadrants, and used an A* pathfinding algorithm to ensure that the entrance and exit had a path between them.
My thesis was based on informing the procedural generation system of player status, such as number of living units, health and remaining Faith (the currency used to cast special abilities). It uses these values to modify the specifics of generation, such as hall length, turn chance, room size, and the number and relative strength of enemies. By doing so, the system is able to create levels that tailor themselves to player performance, creating difficulty curves more in line with individual player skill.
One of the largest challenges facing our team was balancing gameplay for all the classes across all of the difficulties and acts within the game. To aid in this process, I created an Excel file that updated based on the same files that the game uses to create characters. This way, all of the values can be seen directly by editing small, simple files – which allowed rapid iteration and tweaking in order to achieve appropriate balance. Additionally, since these are the same files used by the game, changes made to game balance are easy to immediately implement.
Creating Interesting Levels My primary goal for this project was to create a procedural generation system that produced high quality levels. To do so, I used a variety of systems. First, the system creates a number of rooms around the map, and places several seed tiles in each room. From each of these seeds, an L-System algorithm grows hallways from each of these seeds. Each seed has a preferred length, a range of variance for that length, and a chance to turn. Each continues until it connects to another room or hallway, ensuring that the seeds all connect into a large level. After creating the layout, the system places the entrance and exit in opposing quadrants, and uses an A* algorithm to get the length of the critical path, ensuring that it falls within an acceptable range. The system places Shrines – interactive objects that prevent the dangerous Hound enemy from spawning – along the critical path. After placing the entrance, exit, and shrines, the system determines the floor-specific objective and places the required objects in the level.
Strategy Gameplay on a Mobile Device Another big goal for the project was delivering deep strategy gameplay on the mobile platform. To do so, we kept units relatively simple – having only the ability to attack, move, and perform one special ability. The special ability varied by class – for example, the Huntress is able to enter Sentry Mode and provide cover for her squad, shooting any enemies that enter a watched tile. We also did not include an inventory or equipment system, as these could quickly increase the complexity beyond what was manageable on an iPhone. By keeping to these core tenants, we were able to create a game with great strategic depth while not overwhelming players on the chosen platform.
Replayability One core goal for the project was a high amount of replayability. We took cues from the roguelike genre, creating a new discrete experience for each play session via procedural generation. We also provide a difficulty system similar to that seen in the Diablo franchise – that is, each difficulty is tailored to a specific level range and player progress through them in order. Additionally, we created a leveling system that included talents, providing a way for players to customize individual units and personalize their squad. This provides incentive for players to play through the game repeatedly to experience new dungeons and increase the power of their squad.