Quest dialogue progression setting function build to be reuseable for both progressing dialogue and jumping to a part
Quest navigation in quest menu
System balancing in Google Sheet
Using formatted .csv file to import quest data into the engine
Highlights
Creation of Attribute-Based Potion Brewing Gameplay
The game's goal is to teach players about history in a fun, interactive way, with its target audience being college/high school students who want to learn about history. With this in mind, I wanted to design a calm and puzzle-like cooking mechanic without a time limit.
Since the potion's attributes cannot exceed the bars, players get to experiment with different orders of adding the ingredients and how they affect the potion.
With the difference threshold giving grace to the players, they can choose to move on with imperfect but acceptable potions or try until their potion is perfect.
With the nature of the puzzle, there could be multiple solutions to meet a quest's ideal attribute, encouraging players for experimentation.
The brewing idea was inspired by a Reddit post about different cooking mechanics in games.
Quests
When creating the quests puzzles and level progression, I first created a spreadsheet to visualize the pacing, difficulty, and keep track of the puzzle answers, communicating with the narrative designer to keep the narrative and gameplay progression cohesive.
To give freedom to the players in accepting and completing quests, the quest system combines linearity and non-linearity. The levels affect the number of ingredients player use and the attributes they have to manipulate. Within the level, players can choose their own order and number of quests to complete, with the exception of level 1, the tutorial.
Required potion column shows the kind of potion the player will have to make according to the narrative, which is taken into consideration when setting the ideal attribute of the quest potion.
With the difference threshold shows how much the actual potion attribute can differ from the ideal attribute. Higher difference threshold = easier to pass the quest. With it, players can choose to move on with imperfect but acceptable potions or try until their potion is perfect. It also allows the designer to control how much mastery they want the player to have over the topic/learning objective of the quest.
Best recipe column shows the quest puzzle answer with the least amount of adding ingredients. It is formatted as: ingredient number - amount. With the nature of the puzzle, there could be multiple solutions to meet a quest's ideal attribute, which encourages players for experimentation.
The note column shows each quest's purpose in teaching and challenging the players with something new, allowing for a balance between player skill and difficulty.
The brewing idea was inspired by a Reddit post about different cooking mechanics in games.
Quest Balancing
I created spreadsheets for easier communication between different team members and set up a pipeline for implementing data into the engine.
I designed and implemented a spreadsheet-driven workflow to streamline balancing and updating quest-related values. By exporting data as a .csv file and integrating it into the engine, I automated the process of populating quest parameters, improving efficiency and reducing manual implementation time.
This system also enabled cross-disciplinary collaboration, allowing the narrative designer to directly edit quest descriptions within the spreadsheet, eliminating the need for in-engine updates and significantly accelerating iteration speed.
I designed this spreadsheet to make the communication between teammates easier, with straight forward best recipe.
To see the player feel and test the core mechanic, I created a simple physical prototype and play tested it with my peers. I was able to get the feedback that the potion brewing mechanic using attributes were fun and engaging.
Early Slide Deck of Game Overview, Systems, and Objects
With the paper prototype, I created the slide deck to pitch the concept to my team and measure the scope of the project.
Early Builds
The first two slides show the example core gameplay prototype I presented to my team, mostly consisted of non-game developers, to communicate on the options for the core gameplay.
After communicating with my team with the goals and the scope of the project, I started delivering weekly prototype builds to the team to communicate the progress and make sure everyone stays on the same page.
Prototype 0: The customer asks for a random potion and player gets xp if they click on the right potion.
Prototype 1: Added a game over condition and suspicion meter as well as a map and an area where the player can talk to an NPC.
Prototype 3: Implemented the potion brewing gameplay where ideal attributes were randomly generated each round. Also created UI elements for the potion attributes, like ideal attributes and potential attributes when drag-entering the ingredient into the pot.
Prototype 5: Added attribute bars to make the gameplay less feel like a math quiz. Also added some art assets and implemented the difference threshold since the ideal attributes were randomly generated and not always possible to match exactly with the available ingredients.
Prototype 7: Added a quest system, quest menu and inventory UI, and dialogue system. Got rid of the randomly generated ideal attributes for more linear gameplay.
Prototype 9: Added some UI buttons and implemented map UI and some written assets. Reorganized NPC classes to easily create many of them with customizable properties like appearance and quest ideal attributes.
Prototype 10: Added unlockable areas on map that unlocks as players level up.
Prototype 12: Implemented more art assets and polished UI according to player feedback. For instance, updating potion brewing bar color from green when unacceptable and yellow when acceptable to be green when acceptable and yellow when unacceptable to make it clearer.
Prototype 14: Updated gameplay progression according to the narrative design. Created and implemented functions that allows for non-quest giving NPCs and dialogues as well. Also created various interactions and level up events for during the game and the ending.
The prototypes afterwards consisted of bug fixes and asset implementation, including script, UI, and art.
An alternative pitch of the game that was a turn-based RPG. It allowed the player to attack the inquisitor and the inquisitor (AI) to attack the player using a random attack.
How the Core Brewing Mechanic Evolved
Currently, there are two outcomes when players submit a potion for a quest: they can either pass or fail. The early prototype of the game allowed for a spectrum of pass, the player getting higher reward the close they brew the potion to the ideal potion attribute that is randomly generated. However, this idea was scrapped as we moved to a more linear quest structure with set number of total quests.
Reflection
What went well:
I was able to stay motivated and consistent throughout the semester while working on academic and extracurricular activities.
I learned a lot about Unreal Engine in general and developing 2D games in it. I was also able to get more experience with Object Oriented Programming and optimizing workflow by creating reusable functions and data and string tables.
My team was able to create a playable game by the due date and present at the Japanlab Expo.
Obstacles:
As an educational history game, our team included non-developers like script writers and history researcher, which made communication very important and challenging. The solution I came up with is to come with a visual/playable prototype every meeting to ensure everyone was on the same page and the design was easy to understand.
Future Improvements:
I would make the UI Navigation more player friendly. For example, allowing to start brewing in the quest screen.
I would like to start utilizing public and private classes more.
The problem in design is because we had to reduce the scope towards the end, the difficulty of quests within the same level and what they learn from the levels vary and are not in order. Once we add more quests, I would like to add quests that allows players to have enough practice to properly learn the mechanics and different ingredients.
Currently, the suspicion meter doesn't really have a use since the players can know when brewing if the potion will be accepted or not. I want to adjust the design to make the gameplay higher stake.
I want to implement an endless challenge game mode after the player clears the game once where they can just brew to match randomly generated potion attributes with a high score leaderboard.
.svg)
