Project & Portfolio 3: Tournamental

Written By Bryce Lenhart

For this PNP (Project & Portfolio), the goals were:

  • Use Trello as a sprint planning board

  • Keep practicing documentation of daily activity and design/development steps taken each day (using Trello in this case)

  • Create a new mechanic for a data-driven tile-based game in Unreal Engine 4 named Tournamental

  • (Optionally) Keep using Perforce as source control for project files

 

For the first week of work, the Navigator sprint, we were instructed to create a brand-new game mechanic for Tournamental. I chose to create a Switch/Lever (here-on just Switch) that could control an arbitrary number of other individual Tiles. When activated the Switch would toggle the predefined array of Tiles between two types. For example, I could toggle a line of blocking Wall tiles to be non-blocking Floor tiles instead.

With a nice chunky sound and clear visible indication something had changed, very quick playtests in a simple map often had testers making a surprised sound or remark when the Switch was interacted with.

 

Tournamental, Bryce Lenhart’s Switch Mechanic test map

 

For the Driver sprint the following week, we paired with another student from our section and worked to include the mechanic that they had created into Tournamental alongside the mechanic we had already created.

I paired with Bryan Barragan, who had designed the “Fake Walls” mechanic. The concept is that the Fake Walls are blocking tiles that prevent forward movement, often hiding access to a key or otherwise important object that allows for further progression. When interacted with they crumble away, or otherwise hide itself to allow the player to pass through the once-blocking Wall tile.

With a simple rockslide sound, the Fake Walls felt as though they were crumbling away when interacted with. More quick playtests had similar reactions as the first, with testers often showing excitement in their discovery of the mechanics to allow for forward progression in the map.

 

Tournamental, Bryce Lenhart’s Switch mechanic alongside Bryan Barragan’s Fake Walls mechanic

 

Postmortem

What went right:

  • The mechanics felt satisfying to use

    • Between the Switch’s chunky sound and simple animation, and the Fake Walls crumbling sounds, the mechanics had a simple charm that had playtestersmaking surprised sounds or remarks in both playtests.

  • The Switch mechanic is modular and easily expandable

    • The Switch mechanic was created from the ground up to control an arbitrary number of Tiles that could arbitrarily be any two other types of Tiles. For example, if a future designer wanted to they could use the Switch system to turn a simple Floor or Wall Tile into a “Win” tile.
      The mechanic supports any object of parent type “Tile”, meaning the Switch can toggle any Tile between any new types of Tiles created in the future of the project.

What went wrong:

  • Switch Tile Change Indicators

    • The temporary hot pink tile material works very well at drawing the player’s attention to the changed tiles! However, it’s not what I originally envisioned. Originally I planned to individually support switching into and out of each tile type, playing an animation for that tile. For example, if the Switch turned a Tile into a Wall Tile, then the component(s) that make up the visible wall of the Tile would animate up from out of the floor for show the Wall popping up, and vice-versa when toggling away from a Wall Tile.

  • UpdateTileType Function

    • While working on my project, I had to highjack a function named “UpdateTileType” in the parent “Tile” blueprint to spit out a return node for the new tile that was created. Unfortunately, this function was also available to be called in the editor. I didn’t know this at the time, but if a function is available in the UE4 Editor and it has an input or output value, it can no longer be called in-editor. My very quick and dirty solution to this was just making a direct copy of the “UpdateTileType” function, making it return the new tile, disabling it from being useable in-editor, and naming the original “UpdateTileTypeEditor.” This leads into the next point…

  • Tile Reference Issues

    • I discovered fairly late into the project that directly referencing a Tile instead of referencing a coordinate set from the TileMap was leading to issues. If two Switches on the same TileMap both referenced the same tile and one of the Switches toggled the state of that tile, the second Switch would no longer have a valid reference to the Tile. That second Switch would instead be referencing a Tile that has been destroyed and no longer exists, throwing an error and failing to function for that tile when activated.
      This could be easily fixed by instead storing an array of TileMap coordinates instead of directly referencing individual Tile objects. This would also fix the previous issue, removing the need to have a return node in the UpdateTileType function for the newly created Tile.

 

Conclusion

The Switch mechanic was a success, being fun to testers, modular, and very easily expandable with very little effort required. It allows for making a level significantly more complex without flooding the player with information, giving a Level Designer freedom to create something with more depth.

If I had more time, I would absolutely go back and change a few things, but for the time we were allowed it stands as something that I’m more than happy with.

Bryce Lenhart