Engines

Everything that makes explicit use of a game engine. I've done my best to ensure this has a good mix of both Unreal Engine 5 and Unity.

Equally, you will find the best descriptions of the systems I can give in so few words, but should have any more questions, I would love for you to contact me. I apologise in advance for any expletives in the code comments.

Biome chart from Wikimedia (left), and as being processed by the project (right)

One of the most critical functions, the remapping of points that fell out the bounds of the chart.

Just mirroring over the line caused issues with being out of bounds at the extremities, so instead the data has a scaling factor applied to it towards the bottom right corner, based on how far it was from the dividing line. Remapped data can be seen in red.

01

Hex-based World Gen

Using the cubic theorem as coordinates, where you denote them as if they were a sloped stack of cubes.

The origin of this project was a graph on Wikimedia demonstrating how the relationship between the average temperature and precipitation affects the biome of the land.

In this case, they're both represented by Perlin noise maps courtesy of OpenSimplex2, modified for 3 octaves and 1 power function each. This ensures that only similar biomes are adjacent, unlike the early Minecraft generation where tundra could lead straight into the desert.

Notably, hexagons are not a Unity primitive. rather than import a mesh, I've experimented with the meshes being declared at runtime from an array of set vertices.

One advantage to this is technically, even though the terrain can have height from a third noise map, all the hexagons have scales of (1,1,1), meaning things can be added as children without worrying about them deforming unexpectedly.

To stop the coordinates from getting out of control, there are large, invisible tiles with 44 smaller, coloured tiles within it on a localised grid. This can be used recursively as they use the same script, allowing for theoretically infinite detail.

As an additional feature, you can visualise the temperatures and precipitation values.

The next steps for this project, aside from visual improvements, are underwater biomes and beaches, placing settlements and roads between them.

An additional possibility is to include height in the biome selection: the more modern biome classification by Holdridge, however this includes 33 classifications (against the current 9) and would need a complete redesign of how values are mapped.

Video Demonstration Of the System

02

Samsara Mudras

In the world of Samsara, the player's spells are split into Mantras an Mudras, after the Buddhist mediative tools.

Under training, and then a freelance job, I developed 3 of them, named Divine Confusion, Spreading Radiance and Divine Bloom. Once the game releases they may have changed name, but I will update this section when it does.

For now, I can publicly tell you about the first, Divine Confusion. To synergise with a character that already had buffing spells for themselves and allies, I created a spell to temporarily turn an enemy into an ally, a common mechanic in RPGs.

This took more work than expected, as the underlying system was not prepared for an AI to have their teams changed dynamically, and I had to modify the AI behaviour tree to help them reassess their new situation upon being bewitched.

Presentation and Technical Breakdown of 'Divine Confusion'

Ai & Ai Architecture

The project as a whole was based on Cowsin's FPS controller, a fairly sizable package on the Unity store. While it updated to include many of the movement mechanics I wanted (annoyingly, while I was making them), at the time it did not include any AI modules.

The first step was to make a generic AI that can path to a given target, which could later work as a separate script to a behaviour state machine so the pathing functions were always available.

An important element when considering the pathing for 7m tall titans was them cutting a hole in the navmesh while they stood still, so others would have to walk around them, but human-size ai operating on a separate navmesh could still path between their legs.

One major problem that arose while developing the Titan's following AI was how close it would get to its target, the player.

When it was set to get as close as possible, it would loom over the player at an uncomfortable proximity, and restrict freedom of movement. This was resolved with a buffer zone, meaning the actual navigation target was slightly before the player. This also meant the player could move further before the Titan would attempt to catch up, freeing CPU time that would be spent on navigation.

Main navigation function, operating on a 1 second clock

Function swapping from the Titan controller to the human

UI

I did begin to craft a user interface for this project, loosely based on the design created by illustrator Nathan Beasly in a TitanFall fan project of his own.

I had never crafted a menu with dynamically collapsable elements, and was concerned with how the mouse would interact with moving buttons, however with the group not collapsing until another is hovered over, it's very clear to use.

Another interesting element borrowed from the original games is a lock indicator instead of greying out, in a UI where hovering and grey text are already heavily used.

03

Operation Rapier

Briefly, a vague attempt at making a level for a hypothetical Titanfall sequel.

For the unfamiliar, TitanFall is a series by Respawn Entertainment, a fast-paced FPS known for fluid movement mechanics such as wall running and double jumping, as well as the ability to enter player-controlled mechs called Titans.

This did also include character designs and scripts, which have been since lost to time.

How the AI functions, in theory

How the AI functions, practically

Illustration of navigation buffers

Titans

An extremely important game mechanic is the ability to mount and disembark from the player's titan. As the movement controller was provided by Cowsin's FPS controller, but it is explicitly designed for only a single one two exist. It would be impractical to modify it in real-time to wap between human and titan mode, so the controller itself had to be extensively modified to allow the player's input and camera to be switched between the two.

It made use of the newer Unity input system, meaning it was closely knit with the keyboard actions and event manager. After discovering and mapping all the elements that bind the controller with the event manager, it was simple to make them public and provide an external script to swap between two existing controllers.

Another element that needed to be managed was the location of the two controllers. The human controller could always be dumped at the feet of the old Titan controller, but the Titan controller would then need to be disabled and swapped for the AI Titan.

Main Menu screen (devoid of background art)

LINK TO THE DESIGN DOCUMENT

LINK TO THE EVALUATION

04

Minor Mechnics

This section is dedicated to minor mechanics that don't really need their own section. This space will always be under construction, so check back!

A camera trick that forces the player to look at a button on a laptop during a meta disempowerment moment, giving them no option but to press it. The further away the player looks, the lower the camera sensitivity gets.

One issue while making this was having the force against the player being partially separate, so it wouldn't get stuck looking sideways or being able to flip around then being forced to look backwards

Spline Pathfinding

I was inspired to make this by the auto-run function and map in Black Desert Online, a Korean MMO I used to play a lot.

This version is in Unity using Sebastian Lague's spline system, however I have previously made an Unreal version with it's native spline system.

Following a path is simple logic with linear interpolation down its length, but the complexities are with junctions and maintaining a certain side of the road.

The logic pipeline works as such:

enter a junction
check the far position of every path outside of the junction (not the connecting paths inside it) against the destination of the vehicle
check if the vehicle is at the start or finish of the inside connecting road
set the vehicle position to the nearest point of the inside path, *-1 the "side of the road" offset and speed if it needs to be
do that again for leaving the junction

I also created an editor tool to help with placing roads in the world by vertically snapping with a terrain collider, as well as automating as much of the setup for the junction triggers as I could.

This mechanic is still in its infancy, with the next step for it being a more efficient essentially traveling salesman solution, as well as significant visual polishing.

Manifest-type Inventory

This was the inventory system that worked alongside the above pathfinder to make an RTS/trading game, and is equally under construction.

The original intention for this was for an interface to resemble Victorian-era paperwork, such as ship manifests and passenger lists. While this is being delayed whilst I research an effective yet immersive UI design, the temporary solution is a traditional slot-based solution.

Each wagon has a max load by weight as well as volume, and an amount of passengers it can carry. At less efficiency, cargo can be placed in passanger slots, and visa versa. A lighter load allows for faster movement, but an overloaded vehicle quickly grinds to a halt as the horses cant pull it, if not breaks the wagon entirely.

It also makes use of Unity's IEnumerators to support spoilage after a certain amount of time, overwriting the image, name, description and price into the spoilt version, as well as different categories of cargo not only for sorting in the UI, but so they can be tariffed differently as well.