Project Info - Leave No One Behind

Leave No One Behind is a puzzle game built by me and a team of my peers. I served as the team's programmer, gameplay designer, and level designer. This project will show how I am able to prepare for and work through the challenge and complexity of puzzle game design while making production smooth for both me and my teammates.

Scripting

Main Takeaways

Enchantment Scripting

enchantmentMenu

Whenever I make a system that is liable to be expanded upon, such as Leave No One Behind's enchantment system, I try to create a streamlined process for making additions to the system. Enchantments in No One Left Behind need to show up in their respective UI menu, update the UI when the ingredient needed for the enchantment is collected, and give the player's character the proper effect when they are enchanted. Here, you'll see how I use Unreal blueprints to make it so that adding a new enchantment that does all of this is a quick and simple process.

dataTable

The core of the enchantment system is a data table that holds all of the information on how each enchantment functions. The first step to adding a new enchantment is adding new enum values to represent its effect and required ingredient. Once these are created, a new entry to the enchantment data table can be added with these values. This data table can be read by other blueprints, which means I can have the game as whole react to just a single edit made to the table.

The enchantment UI takes great advantage of the ability to access data tables; I have specially scripted this UI so that it practically builds itself based on both the enchantments added by developers and the state of the game during runtime. To help make the UI this reactive, the enchantments shown in the menu above are actually each an instance of an Enchantment Recipe widget. When the menu widget as a whole is created, an enchantment recipe widget is spawned in the menu for each enchantment found in the data table. I use the menu's "Pre-Construct" event to spawn the recipes so that the layout can be previewed without running the game.

menuConstructor1 menuConstructor2

I wanted to make it clear to players what enchantments are and are not a part of the current level they are in, so any enchantments not used in the level are hidden in the enchantment menu. Since each enchantment requires a certain ingredient to be collected before it can be used, the game detects which enchantments are in play based on whether its corresponding ingredient has been placed in the level. Note in the blueprint snippet below that the recipe widget is set to be "Collapsed". Because the recipes are stored in a Vertical Box, if one of the recipes are collapsed, as opposed to just being hidden, the rest of the recipes will rearrange themselves to fill the space. This keeps the menu looking neat no matter which or how many enchantments are in play.

ingredients

For the ingredients themselves, I have a singular blueprint class made to represent any of the ingredients. The ingredient represented by each instance of this blueprint is controlled via an ingredient enum parameter. The blueprint's constructor reads this value and changes the mesh to that of the respective ingredient. Since this is done in the constructor instead of the Begin Play event, the mesh change is shown in the editor pre-runtime, allowing a level designer to tell at a glance what ingredient they have placed.

ingredientSelection

Finally, the actual effect of enchantments is hard coded. Because an enchantment's effects can be anything imaginable and are not, for instance, merely stat changes, I don't believe there is a practical way to make enchantment effects any easier to implement.