Tower of Babel
Introduction
Tower of Babel is a single-player Action Adventure RPG featuring turn-based team vs. team combat.
As the player ascends the mystical Tower of Babel, they recruit allies and grow in power. Hoping to bring about an end to the world's plagues and suffering, the player must defeat the monstrous and powerful creatures that have infested the tower as they make their way to its peak.
Photo Gallery
Features
| Environments | The unique environments of each of the Tower's levels allow the game to explore varied and distinct stories. |
| Story | The stories and lore of the fantastical world are told through scripted Quests, NPC Dialogue, and visual storytelling. |
| Combat | The player and their companions face off against groups of enemies in turn-based combat. Each character has their own speed, and can use an ability once their speed meter caps out. |
| Creatures | The game features a variety of enemy creatures, each with their own stats, abilities, and combat behavior. They are fought in Encounters, which can present many combinations of individual creatures. Boss Encounters can be made up of a powerful single enemy, or a cluster of synergized lesser enemies. |
| Companions | Companion characters can be recruited to the player's party, outfitted with Weapons, and upgraded with Skill Points to improve their stats and access new abilities. |
| Abilities | Abilities can be used in combat to enhance allies or harm enemies in a myriad of ways. |
| Items | The game is populated with a multitude of items, including: equippable Weapons, Consumables, Quest items, and Trophies that are intended to be used in crafting and bartering. |
| Progression | Advancement through the game is achieved by increasing character's levels and power, unlocking access to new waypoint locations, defeating Bosses that bar passage, and ascending to higher levels of the Tower. Progress can be saved and returned to at a later time via game saves. |
Download Links
Development Summary
This game demo was created as a part of the two-semester Capstone project for the University of Baltimore's Simulation and Game Design program. As a game demo, all of its core features are complete; additional content and polish would be its next step.Timeframe: September 2020 - May 2021 (9 months)
Game Engine: Unity v. 2019.4.x (LTS)
Collaborators:
Roles & Responsibilities
I took on a variety of roles while working on Tower of Babel, acting as the primary programmer, a systems designer, and a content designer.My responsibilities included:
When I say self-managed combat effects, I mean that the effects subscribe to the core combat management structure and react automatically to various action events that are broadcasted through the system. The reactions handle things like determining when effects should be applied or removed and how.
Thanks to the use of action events and reactive behavior, the combat system is very set-and-forget. New combat abilities can be created and configured modularly to behave in a wide range of ways without needing to alter the core combat system to account for them or integrate them explicitly.
Thanks to the use of action events and reactive behavior, the combat system is very set-and-forget. New combat abilities can be created and configured modularly to behave in a wide range of ways without needing to alter the core combat system to account for them or integrate them explicitly.
Mechanically, tooltips are achieved with:
- A set of Tooltip components that dictate the format and content of any given UI element's Tooltip. They can be added to any UI element, either manually or programmatically at runtime. A number of the component's variables need to be configured in order for the Tooltip to populate properly.
- A UI layer for the Tooltips to be displayed upon, in front of all other UI.
- Graphics Raycasting to detect when a UI element that has a Tooltip component on it is detected, which will cause a Tooltip to be generated.
- A set of simple prefabs with primitive UI elements that are used to format and construct Tooltips and that are populated with relevant information or graphics.
- A method responsible for instantiating, formatting, and populating the Tooltip with relevant information. Each of the Tooltip components' methods are configured based on what is relevant given the content being shown and the context it's shown in.
- Companion scripts that can be invoked to dynamically generate Tooltip components on UI elements and populate them with relevant variables.
I was responsible for building the game for different platforms, configuring Unity's build settings, resolving build errors as they arose, packaging and organizing the built game's different versions for our distribution and backup sites, and ensuring that the game in general and each of its systems functioned properly on different platforms.
The following are examples of accomodations made to account for differences between and limitations of certain platforms and devices:
The following are examples of accomodations made to account for differences between and limitations of certain platforms and devices:
- Horizontal and vertical mouse input sensitivity sliders were added in the game's options to allow each player to calibrate the sensitivity as they need for their setup.
- For PC, Mac, and Linux builds, the game's save data (savegames) are stored in accessible, editable files that were located relative to the application's location on the hard drive. However, since reading and writing files between a browser and the local computer isn't nearly as straightforward, the savegame data for WebGL builds is instead saved as PlayerPref strings of JSON-formatted data.
Throughout development, I regularly tested the game to confirm that the functionality and scripted content being added behaved as expected.
An outline of my general QA testing and bug-fixing process:
Reflection
Since I was also responsible for a significant portion of the game's programming and content design, I ended up having a fairly streamlined and comfortable iterative process with my own work.
An outline of my general QA testing and bug-fixing process:
- Implement features and new content.
- Playtest the game, especially focusing on content, features, or fixes that were implemented since the last playtest.
- Record unexpected behavior, make guesses about root causes of the issue, and assign a preliminary priority level for the issue based on its prominence and severity.
- Review the list of issues to consolidate similar issues, adjust priority levels, and ultimately indentify the most pressing ones.
- Work on implementing fixes for the most pressing issues.
- Investigate the backend of the elements related to the issue to identify the root causes of the issue.
- If a root cause of the issue was found, add it as a sub-goal to the issue with it's own priority level.
- If I failed to identify any root causes behind an issue, I would leave its priority level as it was, make note of what I had considered or looked into as potential root causes, and then move on to the next issue, saving this one for a later pass.
- Make necessary changes to address any identified root causes.
- After implementing a change intended to resolve an issue, mark the issue as preliminarily-resolved, pending confirmation in an upcoming playtest.
- Repeat.
Reflection
Since I was also responsible for a significant portion of the game's programming and content design, I ended up having a fairly streamlined and comfortable iterative process with my own work.
- This dynamic gave me additional insight into what was likely wrong when coming across any given bug, which was typically helpful for identifying and resolving issues quickly.
- However, that the dynamic was also likely less than ideal due to my inherent bias and shortsightedness with regard to my own weaknesses of design and limited ability to mimic other people's playstyles. Had the roles been a bit more equitably divided, I likely would have identified more issues and recieved design feedback that was more critical of the various implementation choices I made for various content or systems. Unfortunately, our circumstances were not quite so ideal as to allow for that.
Major Achievements
incomplete
v3
Tooltips
Inventory
Character Management
Equipment & Abilities
Combat
Abilities
v2
The game's data is stored in persistent ScriptableObjects. The kinds of things that are stored include items, abilities, quest details, and character stats.
Using ScriptableObjects means that the data is stored in a database of sorts. Not only did this improve organization by centralizing the data and allowing changes to be made easily, but because it was a database, I was able to develop tools that would reference the databases' information and dynamically populate the various UI elements throughout the game at runtime. This meant that, after configuring and programming those tools, I was able to apply them in numerous places through the game and have them do the work for me, work that I otherwise would have had to manually input.
In the case of the inventory, quest journal, and the equipment and ability lists, I was able to doubly automate that. First, the player's save data is read to populate the buttons that are present, and then those buttons
Using ScriptableObjects means that the data is stored in a database of sorts. Not only did this improve organization by centralizing the data and allowing changes to be made easily, but because it was a database, I was able to develop tools that would reference the databases' information and dynamically populate the various UI elements throughout the game at runtime. This meant that, after configuring and programming those tools, I was able to apply them in numerous places through the game and have them do the work for me, work that I otherwise would have had to manually input.
In the case of the inventory, quest journal, and the equipment and ability lists, I was able to doubly automate that. First, the player's save data is read to populate the buttons that are present, and then those buttons
//Enemies, Abilities, Equipment
Skills Developed
incomplete- Finite State Machines
- Saving and Loading Custom Data Structures
- Event Listeners - Intelligent/efficient. Rather than checking for the conditions of things like FSM's in an Update or Coroutine, they only check their state when a relevant form of progress is made (i.e. when a quest whose progress affects one or more of that FSM's states updates, or when the item count of a relevant item changes). Also used for combat Effects. Handled through a set of centralized manager scripts. //I also set up a lot of event listeners at runtime in order to provide self-referential functionality to things like procedurally generated UI elements; diverting a lot of the implementation of functionality that is common but still varied depending on specifics to be handled by automatic processes helped to open my mind to more efficient practices overall that can reduce the amount of input needed by a designer.
- //
Postmortem Reflection
//It would have been really helpful to expand the practice of using dynamic population of content into more aspects of content production. Things like interactions with objects or NPCs required a lot of detailed configuration to set up, including the manageable of conflicting logical circumstances. incomplete