Tony Froman

Edge is a 3D action-adventure RPG where your skill tree centers around the community that you build and develop. Players are able to explore the land of Thymeria, a fractured world of floating islands with different mythical races. The game takes heavy inspiration from games such as Legend of Zelda: Breath of the Wild, Stardew Valley, and Ni No Kuni 2.

Technical Merits

Procedural Animations

Edge features a physics-based animation system, inspired by the system used in the game Overgrowth. The significant advantage is that in our open world, terrain can vary dramatically, so it can be quite jarring for the player to not smoothly interact with it.

Using two colliders- a lifter and a bumper as David Rosen called it. The lifter is a soft collider (trigger in Unity) that allows the player body to move into terrain instead of restricting at the bounds. Rather, it calculates the surfaces intersection and moves the player to be on top of it, simulating a normal force against gravity. This free movement allows the feet to be compressed as they normally would, acting as springs or pistons, instead of rigid sticks.

The bumper acts as the hard collider to keep objects from moving into the center of mass – the torso area, the minimum of where the arms and legs can be compressed to.

With this system and with the help of the Unity IK system, we are able to procedurally overlay prebaked animations with proper foot placement based on the lay of the environment. This will be extended to a full range of acrobatic motion, similar to Overgrowth.

Edge also takes advantage of pre-computing motion, based on the concept of a control sphere. Instead of directly moving the model, the player controls a sphere object which is then used for a target for the model to smoothly interpolate. This allows us to keep motion consistent and frame independent.

Inventory

The inventory system of Edge is incredibly robust and modular. The system implements the subclass sandbox pattern, whereby all inventory items derive from a common base class which is mutually accessible by the inventory. The inventory knows how to display items and their properties.

The child classes handle all of their type-specific functions. For example, you can create a multitude of ingredients which are used in recipes. The recipes specify these ingredients in their attributes and handle crafting. The inventory knows whether the recipe’s requirements are met, then proceeds to remove the required ingredients from the inventory and place the resulting recipe in the inventory.

This design allows for rapid iteration of many different item variations and also makes expansion to blueprints (similar concept as recipes) very easily. You can display any type of item you would like in the inventory, given the right amount of properties, and have it interact with the inventory as you wish!

Menu System

Since Edge is an RPG which requires a multitude of User Interfaces, I created another subclass sandbox structured system. The menu system implements a menu class which all player menus derive from. This allows the menu manager to know which menu to display at what time and also allows for a simple and efficient query to display menus and populate their data accordingly.

Again, this allows the addition of menus without modifying the menu manager script at all aside from extending the number of menus in the inspector.

Similar to the Inventory system, this makes the lives of designers much easier, since they do not have to have a deep coding background to modify the existing code. They simple have to implement a child class for the menu and add an identifying enum type for the menu to use.

RPG Stats & Modifiers System

As with most RPG games, the player and other NPCs can experience a variety of status effects and thus designers need a wide toolset to achieve the differing effects such as stun, slowed or increased movement, stealing health, etc.

To solve this issue, I created a base Character class that holds all key traits of the player such as the health, mana, stamina, and shielding. It also controls access to them so that the attacking script can simply get the character class and apply the desired effect.

Next, I simply added a list of active modifiers (instances of effects) that are applied to the player. They update every frame and apply the desired effect to the player stat and can also be configured to apply an instant effect as well. Using this, designers can rapidly prototype different effects that can be added to potions, weapons, and more.

I also built a damage sink (receiver) and source (attacker) script to interface with the character class and easily be added to weapons or projectiles and produce the desired effect on impact.

Interact-Detect System

Seeing that we would need to create several different systems that all interact with the player in similar ways (NPCs, Pickups, Enemy-Player Detection, Interactable Buildings with UI, etc.), I devised a base system that all these could derive from with universal communication methods.

The system uses two scripts in a constrained subscriber-notifier pattern. The interact script subscribes to the detector. The detector handles all the collision-detection to discover the player and react when the player enters, exits, and stays (all methods of which can be overridden by derived classes). The detector then notifies the interact script which interfaces with the player systems such as the HUD (i.e., showing a “Press F to Interact” when in bounds) or telling an enemy to look at a player or attack in bounds.

The simple, yet powerful code is the primary advantage here. It can easily be expanded to work with any of the example systems by simply customizing methods and calling them within the interaction base class calls.

Voxel Engine

To emphasize the dimensionality of the floating islands, Edge uses the voxel engine Ultimate Terrains. This gives the game a full range of views for the islands and allows us to create breathtaking landscapes as seen in the demo above.

The main issue with Ultimate Terrains is that it is primarily made for sandbox games where terrain is procedurally generated and is configured for only one scene. In order to alleviate this, I had to work with the standard uTerrains saving system and modify it to save as multiple scenes. This turned out to be quite difficult, as maps are saved as template “biomes” with a series of changes applied. After digging through the code, I was able to simply save these changes to an individual scene and pull them as needed.

Page updated

Google Sites

Report abuse