Trailer (Unreal Engine Version) by Jeroen Visscher
My Role(s) // Systems & Tech Design Genre // Rogue-like Dungeon Crawler Engine // Unreal Engine 4 and Stellar (Custom Engine) Platform // PC (Itch.io) Team Size // ~ 15 Duration on Project // 8 Weeks |
OverviewI joined the team for Cabinet of Curiosities during the production phase. Development of Stellar (the custom engine for this project) had not progressed as planned, resulting in the original concept becoming out of scope. Working under a tight deadline of 8 weeks until the release of the game, I made the following contributions to ensure we deliver on the original concept as best possible:
Vertical Divider
|
Rescoping and Redesigning
While getting up to speed with the current status of the project, it was readily apparent that rescoping was necessary due to a number of reasons:
- All disciplines had a smaller workforce than they had prior to the start of the production phase.
- The art department had lost some specialists, with no suitable replacements available for their roles.
- There were only three designers now, of which I was a new member who still needed to be integrated into the project.
- There wasn't enough time to develop the custom engine beyond fundamental gameplay and rendering needs. The additional work required to deliver on the original plan was no longer feasible.
- Neither design nor art could develop content inside the custom engine entirely on their own, further adding to the workload of the programmers in the team.
To get a deeper understanding of the project itself, I studied the original concept, the research done by the team and how the project had been developed so far. Once I had a better grasp, I was able to determine a couple of issues that needed to be tackled:
In order to scope efficiently, the status of the custom engine needed to be demystified to art and design. I facilitated this by becoming a mediator between disciplines.
|
Example Notes - Excerpt from Enemy Design Constraints from Art
|
|
|
Example Lists from Feature Discussions - Excerpt from Artifact System Redesign
Content was also cut if found unfeasible after these discussions. Combined with the new limits imposed by constraints for each feature, redesigns became necessary. Systems were repurposed and iterated upon while keeping the core game loop intact. The biggest challenges were enemies, progression and artifacts.
- Enemies needed to offer enough variety to keep the procedural dungeon crawling interesting. With both AI constraints, character modelling and animation bottlenecks, there was little room for making any enemies.
- Artifact system as the way it had been designed prior required too much bespoke work per artifact. Some of the planned artifacts were just not in scope for the custom engine's new constraints, and our VFX workload was already extensive.
- The main progression would suffer as well if less artifacts were made to keep it in scope. The player obtained new artifacts while delving deeper into the dungeon. They could equip these artifacts, mixing and matching any combination of modifiers to apply them to their attacks.
Turret Enemy Sketch - Behaviours and Variants
|
Turret Enemy - Prototype of Sketch in Action
|
I started designing with reusability and variation in mind, and compiled a list of assets that we already had or were in production. I applied this approach in different ways for enemies and artifacts.
- I repurposed the assets we had to create new enemies. Enemies also had minor variants, which were made with the intent to make better use of the various level design layouts and to keep combat spaces fresh.
- Abilities and attacks were designed to be interchangeable between enemy types and the player, to give both a larger repertoire.
- Researched other rogue-likes and divided up the artifact system into primary and secondary modules based on how compatible their functionality was with the rest of the modules (more on this in the artifacts section later on this page).
Building the Unreal Version
During production we came to the conclusion that this project required Unreal development in tandem to mitigate development blocks for artists and designers. Since programmers were occupied with custom engine development, majority of the game's concept was recreated in Unreal by our team of three designers.
Unreal Project - At the start of the first week
|
By the end of the third week
|
While Unreal was already being used, only room layouts and some prototypes existed in it. The team now needed to test their design and assets holistically.
- Artists needed to see their work in-engine and see how it came together in level design's room layouts.
- To get proper player feedback, we needed the game to be in playable state. Subsequent iteration would further allow us to pave a clear path for custom engine development.
Module Menu UI Example - Equipping an artifact to a slot (Before)
|
Equipping an artifact to a slot after setting up data-driven UI widgets
|
To achieve the aforementioned, I worked on the implementation (in addition to designing the systems themselves) of all kinds of content for the Unreal version of the project, alongside some production work for both versions:
|
Charged Shot - Charge Bar + Fire Rate indicators
|
Boss Charger - Attacks + Feedback VFX
|
|
Playtests (Stellar and Unreal) - Feedback and Observations
|
Iteration Log - Conclusions from Playtests
|
Progress of the custom engine was closely tracked throughout, with more features being adjusted during development based on findings from the Unreal version.
|
Stellar (Custom Engine) Version - Gameplay
|
Artifact System
With how the artifacts were designed originally, each one had to be created from scratch. They then required further work to make sure they were compatible with each other, rendering it unfeasible for multiple reasons:
- A good amount of the artifacts designed did not match the new constraints that were made to ensure features would remain in scope for all disciplines. Artifacts would need to be designed in a way where they could be implemented in our custom engine without requiring major adjustments to it.
- The game would need a high number of artifacts to keep gameplay fresh over multiple runs.
- Programming did not have the resources to create enough bespoke artifacts and then make them compatible with all possibilities or make exceptions where necessary.
- Art only had one VFX artist to make all artifact combinations distinguishable.
- Each new artifact that designers would introduce; no matter how small, would result in exponentially more work for the other two disciplines.
- Programming did not have the resources to create enough bespoke artifacts and then make them compatible with all possibilities or make exceptions where necessary.
Artifacts Research Example - Hades
|
To combat this and provide enough variety, systems from rogue-likes were researched and broken down to design a viable alternative.
|
Artifacts Research - Module Breakdown
|
Artifact List - Planning out the effort required
|
While adding in the distinction between artifacts and limiting primary effects to just one made compatibility easier, it didn't remove the need for exceptions entirely. Primaries were designed with this in mind:
|
Artifact List - Compatibility Matrix
|
Artifact Combinations - Examples
|
Taking this approach increased our modularity, making room for more possibilities. Modules were finalized based on scope concerns and custom engine constraints. I created the framework in the Unreal version of the game to demonstrate the viability of the revamped artifact system from a tech design perspective.
|
Secondary Artifacts - Setting Up New Modules Through a Data-Table
This entire setup for the artifacts was created in just under two weeks, while working on other content simultaneously. The following video demonstrates what was possible with various Primary and Secondary module combinations, and showcases how far we could go with its implementation. The modules were created in a scalable way. New content could therefore be added and made compatible with existing modules with relative ease. Adding new secondary modules, as stated before, was as simple as adding a new row in a data table.
Having this fully implemented also positively impacted the development of artifacts within the custom engine, not just to prove individual designs in advance but also as a reference point for how to implement it. |
|
Stellar (Custom Engine) Version - Module Debug Menu
|
The marked improvement in the progress rate of the custom engine implementation allowed us to test more of the artifacts there, and we included it into our daily playtesting rounds as well.
As a result, we eventually had a taste of our combat and progression on both versions of the game before hitting the deadline, which was a big win for the team as a whole. |