Trailer by Roel Jansen and Okan Tekin
My Role(s) // Systems & Narrative Design Genre // Third-Person Sandbox Adventure Engine // Unreal Engine 4 Platform // PC (Steam) Team Size // ~ 20 Duration on Project // 32 Weeks |
Overview
I've been a part of Dune Strider since its inception. Throughout its development, I've worn multiple hats and worked on a variety of systems for a wide range of content for the project. The following are a few worth highlighting:
Vertical Divider
|
Concepts & Prototypes
Trading
For our 3rd year projects, we're provided with a project brief that provides us with specific constraints that can cover anything from gameplay mechanics to art-style. One of the requirements in our case was trading. To design something cohesive with the other requirements of our project, I began my work by breaking apart what each constraint could possibly mean for the trading experience and from there, I researched how to keep it engaging long-term.
Trading Research Excerpt - Relevant Implications of Project Brief Constraints (Summary)
|
Trading Research Excerpt - Overview of Mechanics
|
I applied the conclusions from the research to create prototypes that could keep players engaged in trading over an extended play session. The first logical step was to set up a dynamic economy for them to trade in.
I prepared prototypes to simulate a basic economy driven by a supply and demand system. Every trading post would have its own consumption and production rates, and prices would fluctuate accordingly. |
Trading Prototype - Simulated Economy
|
Trading Prototype - Demand & Supply
|
Playtesting the prototype proved that trading felt very binary in a simulated economy if the only external influence on it was the player's input. Once a player knew the best locations for buying and selling a resource, there wasn't any new decision-making to do. Relying on research done, I iterated on trading prototypes and tried out various systems that fed back into the economy to find viable solutions.
Trading Prototype - Adapting the economy for a turn-based experience
|
|
Factions
Early on, I noticed that the player was not intrinsically motivated and needed to be explicitly assigned an objective for them to do anything, which didn't fit with the sandbox experience we wanted to craft. Goals from various systems were disjointed and existed in isolation.
To connect the systems we had and bring some cohesion, I did some research into what methods were employed by similar games to do so. One prevalent element was factions, so I analyzed them in a similar fashion to trading. From the conclusions made, I designed a faction system for our game. |
Factions - Research Excerpt (Summary)
|
Camera
One of the constraints we had in our project brief was "High-up 3rd person camera". Between design and art, we explored several possibilities regarding what it could mean for our game; design-wise, scope-wise and visually. At some point during this phase of uncertainty, exploration and discovery emerged as the most enjoyable aspects of the prototypes we had at the time, so we doubled-down on them.
The art team was initially concerned that their work wouldn't get showcased well enough from a more isometric-styled, high-up camera, so I decided to see how far I could push that constraint while addressing their concern. Since it didn't impact our existing designs much yet, all that was needed were some prototypes, for which I:
The art team was initially concerned that their work wouldn't get showcased well enough from a more isometric-styled, high-up camera, so I decided to see how far I could push that constraint while addressing their concern. Since it didn't impact our existing designs much yet, all that was needed were some prototypes, for which I:
- Collaborated directly with the art team to figure out how they wanted to capture different parts of the game world.
- Researched camera references from several games with a focus on exploration and discovery.
- Analyzed what moments of gameplay could benefit from an increased focus on the environment.
Discovery Camera Prototype v1
|
Discovery Camera Prototype v2
|
- Iterated on a hybrid, dynamic camera (inspired by Shadow of the Colossus) that would transition from a close-up to a much zoomed-out, high-up angle depending on vehicle movement.
- Added a "landmark view" to temporarily and seamlessly focus the camera on specific locations, through triggers or conditionally.
- Implemented a customizable settlement camera system to give world locations more emphasis and making their menus interactive.
Settlement Cam Prototype
|
Settlement Cam Prototype - Tools Demo
|
Ultimately, an open world game from that angle; with the concept we had so far, started to seem out-of-scope art wise. It was decided that we would go with a somewhat fixed camera angle to ensure that the horizon would never be visible.
Alternate Camera Prototype
|
With that new constraint, it made sense to take a more isometric approach for a 3rd-person high-up camera.
However, initial playtesting revealed that the reduced viewing range in the bottom-left half of the screen; with the new perspective, could often be detrimental to the exploration and combat experience. To counter this, I applied some of the camera tricks I picked up on when making the other prototypes:
|
UI
Over the course of the project, I made several UI concepts, later creating art assets and implementing them as well. Most concepts went through several stages of iteration, from early mock-ups in Miro to final implementation in Unreal's UMG.
Additionally, I collaborated with another designer in setting up technical and visual guidelines for all UI in the project. |
Settlement Banner Iterations
|
Settlement Banners - In-Game - Final Banner art by Kim Bolenius
|
Quest System
Another requirement from the project brief was quests. While we had concepts for what we wanted from quests in our game, how to set up the quest system was a big question mark for us moving into pre-production.
Since we lacked additional resources to devote to setting up the quest system, I decided to take sole responsibility for its delivery. However, to get started, I first needed to have a solid grasp over what exactly the quest system would need to tackle.
To answer this, I first researched quests individually and then frameworks made by others in the industry for handling quests in their games. For quests, I looked at several reference games that had scripted and procedural quests. Breaking these apart helped highlight what constitutes as a good or bad quest, improving quest design guidelines. It also helped me establish what we should be aiming for in our quest content, which helped me shape the final quest proposal. |
Quests Research Excerpt
|
Before I could get to the quest proposal however, I needed to research what the framework was going to be like:
- Studied several resources on the topic.
- Listened to GDC talks on implementation and tech design for quest systems.
- Researched Custom Quest; a Unity plugin for making quests efficiently, and learned of common pitfalls from its development post-mortem.
Quest System Research - Quest Superstructures Excerpt
|
Quest System - Excerpt from Quest System Proposal
|
My learning from the research allowed me to take an informed stance on how to proceed with the quest system. Utilizing my conclusions to build something viable and efficient for our project, I created a proposal for the quest system with the following decisions:
- The system would give complete freedom to a quest creator to script what they want.
- All player-facing core functionalities would be handled by the system itself. The main function of the system would be to track and visualize progress. Separating the quest script from this would also help with debugging.
- A quest manager would further offload work from quest creators so they never have to manage the status of quests.
- The system would be expanded upon as more content was developed to identify recurring scripts which would then become part of the system itself to also reduce the script work required to create more quests.
Quest System - First demonstration with an example quest
|
While the quest system was iteratively developed and expanded upon, the first time it was ready for quest content to be made through it was after 3 weeks of development. At this point, it was capable of the following:
|
This initial setup was also designed to be as plug-and-play as possible, which meant that all components for it could be exported and put anywhere else like a plug-in with minimal adjustments needed in the target project for the Quest System framework to become compatible with it.
In later iterations, a substantial amount of progress was made with more and more functionality becoming a part of the base quest component to make it easier for quest creators to make more content. More systems from our game were integrated into it and could be utilized directly from inside of a quest. Below is an example; from the production phase, of quests made using the Quest System's framework.
In later iterations, a substantial amount of progress was made with more and more functionality becoming a part of the base quest component to make it easier for quest creators to make more content. More systems from our game were integrated into it and could be utilized directly from inside of a quest. Below is an example; from the production phase, of quests made using the Quest System's framework.
Quest Example - Quest content and video by Roel Jansen
|
Quest Example - Total scripting required to set up 1st quest in the video using Quest System framework
|
Dialog System
While made during the development of the quest system, the dialog system is a component of its own integrated into base quest functionality. Throughout development, it has had its own iteration cycles.
The system supports localization, dialog threading and different portraits for expressions during dialogs. Though it was designed originally only for monologues (since that was all we required), it does allow for branching and optional dialogs through the quest system. |
Dialog System - First Prototype
|
After the first prototype, later iterations received several quality-of-life and polish updates to the dialog window. Text would flow in smoothly, with iterations later down the line also skipping spaces and line breaks. UI Nav support and dialog skips were similarly added to ensure it's not tedious for any kind of player.
Dialog System - Demo Release Version
|
Dialog System - Release Version - Final UI art by Kim Bolenius
|