Starting in 2024, I worked on the first and second TMNT Dimensions games in Fortnite Creative/UEFN.
These games were created in collaboration with Paramount and Epic Games. I worked as a core developer in a small team of no more than 3 people.
I was tasked with creating a prototype for the game with the aim of finding UEFN’s limits. UEFN is very barebones, only really providing you with copy-paste mechanics used in Fortnite BR, which you have little to no control over. To achieve anything different to Fortnite’s base game requires a lot of effort and creativity, to say the least.
My prototype contained basic combat mechanics and some demo levels, which led to the project getting a full greenlight.
I went on to develop both projects as part of a very small team, designing and implementing multiple core systems such as combat, enemy AI, and player progression.
Combat
My solution for implementing melee combat used an animation-based timing system, where each animation had its hit apex and connecting distance saved as part of its data. When an enemy gets within the attack radius, it plays the hit animation relevant to that distance, then when enough time has elapsed, another distance check is performed to see if the hit connected.
A more typical UE5 project would potentially use Anim Notifies and trigger volumes to implement this, but with UEFN you must think outside the box and neither of these tools are available to you.
Enemy AI
Creating challenging AI in any engine can be a challenge, but in UEFN you encounter some unique issues. The only way to spawn in an enemy character is via the NPC Spawner Device, which is also where you assign your behaviour scripts for that enemy type.
To spawn in multiple enemy types (e.g. for spawning a wave of enemies), you need a NPC Spawner Device for each enemy type. This led to the creation of the wave_spawner_device{}, which is responsible for managing each spawner and getting the desired amount of enemies in the level. Devices in UEFN have a tendancy to break, with the Spawn method on the NPC Spawner Device having the comment of “Tries to spawn an NPC), with no callback or reason if it fails. This means implementing a plethora of checks and fallbacks to ensure the game does not softlock if the devices we’re relying on to spawn the enemies do not function as they should.
When it comes to actually moving the AI around the scene we also have limited control. Fort Characters use the built in navigation interface, which only lets you pass in a target position which the character will then navigate to using the Fortnite/UE navmesh system. I recall there being issues with the navmesh not generating consistently, forcing me to implement a teleporting toilet prop that jumps around the scene while the loading screen is up to try and dirty the dynamic navmesh and get it to behave.
Taking this into account, I designed the enemy_choreographer_device{}, which works by assigning enemies attack “tokens” as they move around the play area. A defined maximum number of tokens can be assigned at one time, and as players move around, enemies will have their tokens revoked and granted dynamically. When an enemy has a token, it can attack the player, otherwise they spread out and idle. This creates challenging gameplay without just bombarding the player with an impossible amount of enemies.
Event-Driven Programming
Being the only programmer on both projects from start-finish gave me near-full control of how things were implemented. One of the best designs I came up with was the event_manager_device{}. Scripts throughout the game invoke the FireEvent() method with the corresponding event enum. Other scripts can subscribe to either specific events or any events that are fired, allowing gameplay systems to be cleanly linked together. There is support for a custom data field, allowing near-endless possibility of data being passed around.
Player Progression and Upgrades
The game revolves heavily around persistent upgrades which can be purchased by the player. These upgrades affect the damage the player does and deals, as well as stats like their movement speed, coin scalar, etc. Implementing some of these upgrades required us to override the in-built Fortnite mechanics (For example, whenever an enemy/player takes damage, we immediately heal them and instead maintain our own health value, letting us choose when they die and apply our own death animation/VFX).
These purchased upgrades are stored in a persistent data map. When writing persistent data, UEFN requires you to mark any enums used as keys with the <Peristable> attribute. This has the effect of locking the enum to its current state after publishing the island, making post-launch updates incredibly difficult. To get around this, I switched to using raw ints as keys, which are then converted to non-persistable enums when the data is read in. Confusingly, enums in UEFN/Verse cannot be casted to/from ints, so this required a lot more work than you might think. By the end of it there was over 1000 lines of manual enum->int conversions.
Success
Our focus was creating an experience with high player engagement and retention. The first game had over 26k CCU at launch, which was a new record for any non-Epic UGC experience on Fortnite. I think players appreciated the lengths we went to in creating a unique experience with limiting tools.
I co-wrote a technical write-up after launch, which Epic published here
Leave a Reply