It's efficient to process. While it's designed not to be overly lengthy, it can be, without causing noticeable hitches in the editor.

This tool is built in C++, allowing me to directly expose the InstancedStaticMeshComponent Collision properties to the Actor details panel.

The wall adjusts to the spline curve, generating new instances/sections only when the delta rotation surpasses the set maximum delta, which is a configurable parameter.

Here, you can distinctly see each section created in this instance.

The wall is also adaptable to handle pitch rotation.

A key feature of the wall is how the instances/segments align perfectly on the outside corner, ensuring no gaps or spaces where one could get snagged. All thanks to the math behind it.

A video demonstration of the mesh wall actor setup, showcasing its use in building a wall.

In the details panel, users can define a list of meshes to select from randomly. Additionally, weights can be assigned to modify their selection probability.

Here's an example of a stone wall that requires curvature.

In this debug mode, you can see represented by red lines that only sections with significant curvature utilize the Spline Mesh; the rest are made up of Instanced Static Meshes.

The fence wall design does't need any curved sections.

As a result, no Spline Meshes are used in this instance.

For each building requiring a proxy, a configuration was established within the setup maps. Here, a volume was placed and adjusted via a convenient Utility Widget.

The process output 3 meshes, one for things that had a last-lod impostor; like windows, vines, and finer details. And 2 other proxies; a default one and a winter variant. Ultimately, these proxies were combined within the ProxyContainerActor positioned in the LOD map.

This showcases the proxy containing only flat components, which significantly reduces the total polygon count.

This version of the proxy omits any mesh that had impostors. This exclusion drastically cuts down on triangle counts, aiding silhouette rendering. In the final rendition, both versions merge within the ProxyContainerActor, presenting a complete proxy with all its components.

The system was also adapted for World Composition Landscape LODs. Leveraging the same ProxyTool, but Unbound; it could generate a proxy for all actors and meshes on a given tile. Specific steps were executed for larger rock formations, hills, long spline tools, roads, etc. Collectively, this encompassed everything beyond the immediate vicinity of the player, including the very large and complex Hogsmeade Town and Hogwarts Castle.

The first step was to identify all the relevant overworld foliage and store that information in a pre-computed list. We established a TeamCity job to carry out this step daily. This ensured that any modifications made by artists would be reflected in the distant foliage shortly after.

The image below is a snapshot of the entire overworld. The boxes indicate the bounds of the captured foliage per tile.

At runtime, there's a defined radius around the player, represented here by a large sphere. Beyond this sphere, normal foliage isn't rendered since the foliage's max-draw distance is set to align with the distant foliage system's radius.

In this image, I've highlighted the regular foliage. Outside the radius, all foliage is represented by impostors. Importantly, these impostors are used per tree type or family, rather than for each individual or unique tree mesh.

As players move, the runtime system determines which distant foliage should be displayed. Meanwhile, the standard foliage utilizes Unreal's native optimization, fading out foliage beyond a set max-draw distance. Additionally, the system includes other enhancements, such as evaluating only after significant player movement, ensuring tiles are within the viewing frustum, and verifying they are not too far to be relevant at the time.

Since 2016, I've been developing and maintaining a plugin filled with handy C++ functions for Blueprints. These functions speed up my development process.

I experimented with creating islands using hexagonal tiles. They originate from a central, volcano-like elevation and expand outward. This expansion continues until the formation loses its "energy", resulting in natural-looking shapes.

One of the first fully custom tasks I completed as a Technical Artist was this bridge. You set its length, and it would automatically calculate the number of required supports and their respective heights.

The video demonstrates both a listen-server and a client interacting with the networked inventory/UI system, displaying consistent behavior on both sides.

All components are structured around the use of DataAssets. These assets provide detailed information about the items players interact with, facilitating seamless integration with the inventories and their respective UIs.

Within the game, the dialogue system can be seen in action. Towards the end, the player requests an NPC to unlock a door.

The system integrates six nodes. The first two are Latent Blueprint nodes which only complete once they receive their callback. The next two facilitate custom line displays, and the final pair are callbacks indicating the Latent Nodes can proceed.

By inheriting from a parent class managing the details (BP_DialogueSystem), child blueprints can focus solely on their specific dialogue scripting.

Each script functions as an actor attached to an NPC in the world, enabling easy interaction with other world elements.

Here's an example of how the blueprint dialogue script is built. Except for the custom Request line/question nodes, everything is vanilla Blueprints. the 'DoDialogue Event' is when dialogue is first initiated through the NPC host, and the 'DoFallback Event' is used instead when the primary dialogue has already been "used". Doing this is optional.

This other example showcases a script built around a question, with the initial line being alternated when the player replies with the D option. Since this is all Blueprints, any type of script customization can be easily achieved.

The Materials as a character runs in slow-motion.

Sand Material

Water Material

Shadow Material

This material divides the UV into 16 parts, giving each a color. It could be expanded to include more features if needed.

In Blender, I've aligned the UVs to match the color sections on the UV grid. For convenience one might want to have a mockup texture with the final colors to use in the UV-ing process.

All prototype assets use this single material, allowing for one draw call and up to 16 colors per asset.

Using a Material Instance, you can easily pick the color for each section.

The prototype showcases a 6-wheeled rover, each wheel having its own suspension. It's enjoyable to drive and uses interpolation instead of physics. The video displays the under-the-hood mechanics, emphasizing how it traces and adjusts to the terrain's shape.

Created material for the collectible crystals. Each actor chooses a random shape, rotation, and size when placed.

Control the train as it moves on tracks. It includes a junction system letting you choose paths and transition smoothly between splines.

A brief demo explaining the junction's construction within the editor.

Here is a video of the full game in action.

Watch the destruction system in action. The game incorporates a single configurable Destructible Actor, which is used to create modules for constructing larger buildings.

This showcases the configuration of the destructible actor within its details panel. You can determine the assets used for its varying destruction states, and it supports randomization.

A vertex animated flag.

A simplified collision tool. Used to define the outline of the playable area.

I modeled the tanks in Blender and employed a grid-UV technique for sectional painting. Masks were used to accentuate gameplay elements like weapon color, thruster intensity, and more.

The tanks consist of multiple components assembled within Unreal. All their specific secondary elements were added there as well. Only the legged tanks had their legs animated in Blender.

Maintaining a unique silhouette for the tanks was a key design consideration.

I also created various enemy skeletal meshes, modular turrets, mines, and missiles.

The game's landscape material was enhanced to facilitate easy painting of a distinct low-poly environment.

Tank 1/8: Hovering Tank. Fires a big bomb, and deploys a beam generator.

Tank 2/8: This is a legged melee mech. It punches with one arm, fires from the other, can generate three shields around itself, and launch them as projectiles.

Tank 3/8: Displayed is a hover tank with side blasters. It can deploy a smart turret with predictive aiming capability.

Tank 4/8: A wheeled tank that fires missiles, and can place a wave of dark energy.

Tank 5/8: Here's a heavily armored tank that generates an electric arc in melee range and can set up defensive walls

Tank 6/8: An agile, legged spider-tank that executes a tri-stage magic attack and can deploy a web grenade to hinder enemies.

Tank 7/8: A classic tank equipped with a front machine gun and capable of deploying proximity mines

Tank 8/8: An agile sharpshooter that can ensnare enemies in a gravity well and target them with its side gun.