Null Dominion is the prototype for a tactical RPG that would have been playable on standalone VR headsets. The primary target platform was to be the Oculus Quest, though the prototype was only playable on Oculus Go since that was the headset I had available for early testing. I worked steadily on its design and development to test the viability of a game in this genre that utilized a first-person POV. Designing around the limited input methods of Oculus Go posed additional challenges in comparison with what would have been available on Oculus Quest.
Though I did succeed in creating a playable prototype, I decided to shelve the project after receiving news that both the Oculus Go and Oculus Quest were being discontinued, replaced with the Meta Quest 2. Being that the prototype only included core features for testing the combat system, and given the fact that tactical RPGs are already system heavy game genres, I had realized that I was just not able to maintain a development cycle that could keep pace with the relatively short market lifetimes of current-generation VR headsets. I simply lacked the resources to pivot or gain momentum, especially given the scope of such a game.
There were highly valuable lessons learned from this initial prototype. I'm proud of what I accomplished with Null Dominion and I still believe in its potential under better market conditions.
1
Game Designer, Game Developer, Producer, UI Designer, QA Tester
9 Months
Unity, Visual Studio, C#, Android Studio, Microsoft Office Suite, Inkscape
Null Dominion was designed as a single-player tactical RPG similar to games like XCOM, Divity: Original Sin 2, and Final Fantasy Tactics. The gameplay showcased in the prototype is fairly shallow compared to the full feature list I had in mind for the final product. Players command the actions of a small team of characters while in turn-based combat against an opposing team, with the order of action determined by character derived initiative values. Combat continues turn by turn, round by round, until all units of a team are either defeated, or until the conditions for a predefined mission objective are satisfied or failed.
Combatants spend AP to perform the following actions as available: move to position, attack with a weapon, use an item, and/or use a known skill. An AP limit that partially recharges each turn provides for 1 to 3 actions per turn depending on the cost of the actions selected. Combatants can also rotate in place, view team and mission information, or end their turn as free actions. Unused AP will be reserved for use during the unit's next turn up to a limit. Otherwise turns end automatically when AP falls to zero or a condition prevents the unit from taking action. After all units have taken their turn in a round, each surviving combatant is queued for their next turn.
Movement is managed on a 3D grid of environment tiles with the distance available for horizontal movement being derived from combatant attributes and equipped gear. Vertical movement is also allowed up to a derived jump height, though fall damage is applied when moving down by a distance greater than that jump height. Movement can be split into segments up to each combatant's derived total, with each move action costing 1 AP. Only 1 character unit may occupy a space at a time, though certain actions may knockback or otherwise compel other units to move into an adjacent unoccupied space. A known limitation of this grid-based system is the inability to build tunnels into a level layout: areas with valid movement space below or above other valid spaces.
Weapon attacks and similar actions have a chance to either hit or miss depending on multiple factors, including the attributes and gear of both the attacker and defender in order to reflect nuanced strengths and weaknesses between characters. Weapons have maximum and effective ranges that are factored into the Hit Chance calculation relative to the distance between combatants. The chances of a hit are generally best when a target is neither too far or too near, though the facing direction of a target is also factored in to allow combatants an opportunity to evade attacks they can see. Elevation is also considered, with advantage generally going to whomever has the high ground. Critical hits are possible, dealing extra damage.
Each combat unit has a meter to track their current Health and Armor values, with their upper limits derived from character attributes and equipped gear. Health is damaged by attacks after armor has been depleted to zero, or when an attack pierces (ignores) a percentage of armor. Units are KO'd when their health drops to zero, removing them from the turn order and counting towards either victory or defeat. Up to 6 status conditions can be applied to any unit at any given time, which can be either beneficial or detrimental. These conditions last for a given number of turns, their effects apply at the start of each turn, and can be stacked up to a total of 10 turns. Some conditions can be 'permanently' applied by equipped gear, so these do not expire during combat.
The gameplay trailer below demonstrates two full sessions of combat between 5 characters: 2 players (blue), 2 enemies (red), 1 neutral.
NOTE: This video contains free placeholder art assets and does NOT contain in-game SFX.
Running Time: 12 Minutes, 8 Seconds (suggested playback speed = 1.25)
The in-game HUD is primarily composed of 3 distinct component systems. The first is projected from and engaged by the hand-tracking input controller with 3 DOF; it presents a nested radial action menu and allows raycast target selection. Second is an informative overlay that responds to the 'center-eye' camera reticule; it highlights the subject of the player's gaze and displays non-iteractive information from other characters. Lastly, an overlay of information for the active player character is attached to the viewport; it also provides hit feedback with a vignette. There is also a placeholder world space popup menu used on victory or defeat to either restart or quit the demo.
Each option of the radial action menu is intended to display an icon relevant to the option, though these are blank in this prototype. This menu has 2 layers, each with up to 8 options. The sub-layer menu is only used for skills and items, all other actions are at root level. The raycast changes color depending on target presence and distance to provide additional feedback. A radial meter appears at the end point of the raycast to confirm both the action and its target, canceling on early button release. Additional information such as the calculated hit chance and AP cost also appear relative to the raycast end point. The overlay indicating the current round, turn, and FPS tracker are placeholder solutions for testing purposes. A stripe-compass indicator was planned along with an actual round/turn order listing.
NOTE: If images fail to load in the slider, refreshing the page can correct the error.