A Quest System for our Cat-Game: Part 2
Table of Content:
Summary of Key Points
• Recap: I am working in a team to design a game where you play as a grandma catching cats. I designed the quest system to fit a hub & spoke model, but after the level became linear it needed a redesign.
• Level & Character changes: We opted for a linear level instead to lessen our scope, and introduced a new character named Ponpon as our main quest giver. The quests revolve around Ponpon's narrative as a struggling Cat Cafe owner.
• Revamping Quest systems: With a linear level came new challenges. We implemented a dialogue system alongside a quest board, but quickly realised that having only one place for quests was the way to go, and we scrapped the quest board.
• Designing Quests: When designing quests, I kept in mind Ponpon's character and narrative, as well as creating a natural progression for players to ease into the game, using the 4 step level design process as a foundation.
• Implementation: We used custom nodes and event triggers together in the dialogue system we had, which consisted of a branching tree diagram for each quest.
• Reflection & Learnings: Designing the quest system not only taught me a lot about quest design in general, but allowed me to learn a lot about level design too, because I had to look at it from a quest design perspective as well.
Recap & Early Developments
I am currently in my third year at Breda University of Applied Science, and have been developing a cat catching action adventure game, where you play as a grandma in an interdimensional Cat-world. We’ve finally decided on a name: Chasing Whiskers, and I’m happy to share that it is available on Steam for free! In my last Devlog I talked about how I went through the process of designing a quest system for this game. To do so, I stepped out of my comfort zone as well as my usual role as a level designer, and it was something that I had a lot of fun doing!
In the previous Devlog, I described the system as utilising a lock and key type progression. You would have a number of quests you could choose to complete at a given time, and they would allow for you to receive ‘offerings’, rewards that you could give to ‘statues’ placed around the level that would lock the progression. In doing so, you would be rewarded with a new level segment to explore. There were going to be three level segments in total, one locked as the final progression blocker and main end goal, and the other two containing the respective key halves to unlock that final goal area. We were utilising a hub and spoke level design system, with your character’s cat cafe placed in a central location as the hub, and biomes branching out as the spokes.
Here is an example of the early prototype system my programming lead, Daniel Kočan (LinkedIn), helped me develop in Unreal with custom nodes that we could call. It also allowed us to control the flow of quests to allow one quest to unlock other quests.
However, we still had a few problems with this system that we very quickly needed to fix. For one, we quickly realised that our hub and spoke design was going to cost us a lot of time to make, and was almost out of scope for the time remaining to make the game. We also had huge gaps in our world-building. We needed to define cats and also the quest givers in this Cat-world so that things could be coherent and we could establish a tone for the player.
So let me tell you about some of the changes we made to both our level and the quest system as a whole.
A Linear Level and a New Character
The first thing I did was to write down a series of worldbuilding questions that we wanted to establish for our game. Why is the player catching these cats? Who is running the cat cafe if it isn’t the player? Who lives in Cat-world? Together with the team we went over some of these questions and made some drastic changes for the sake of clarity and scope.
The first change that I made together with Jarno Fleurkens (LinkedIn), the other level designer on the project, was that we were going to scrap the hub and spoke model for our level. It required too many assets, and even at the small scale biome levels we had made, it was going to be out of scope. We decided that we were going to just do one level and keep it linear. This way, we could work a lot better with artists to do set dressing in a linear fashion, and overall iteration and integration of workflow was going to be much smoother. For this, we decided on the jungle biome that I had designed, and went back to the drawing board to expand it into a larger linear level.
The second change that we made was adding a new character, the quest giver. We felt like we wanted to have one centralised person giving out these quests to keep the scope small and to give a sense of world-building for who could inhabit this type of world, and one additional character was enough for our character artists to make. We took inspiration from our Japan inspired architecture, and decided on a Tanuki, a mischievous dog-racoon animal often in Japanese folklore. We wanted to aim for a character similar to Tom Nook from Animal Crossing, not necessarily evil, but definitely a bit greedy when it comes to money (or in this case, cats).
Our Tanuki was named Ponpon, and is the proud owner of a Yatai (food cart style) cafe that he is running, where his main customers were going to be cats. So a cat cafe, but in a more literal sense. This gave the player a reason to be catching cats, as they were going to be helping Ponpon with his cafe’s failing business, and in return, he would give you information or help clear the level obstacles to help you find your lost cat at the end of the level, the main motivation for the player character. It also helped to ground quests to a familiar face, giving the player more motivation as they build a bond with this new character.
Refactoring the Quest System
Since the context of quests had changed, as well as the overall narrative of the game, the quest system also needed a restructure. A big part of this was due to the shift from a semi non-linear level to a complete linear level structure, which interrupted the flow of progression from the initial proposal.
In the initial system, the hub and spoke design meant that we should have a number of quests available to a player so that they can have a sense of freedom to progress whatever areas they wanted. My original version had a Quest board with multiple quests that a player could choose to do, with completing one quest still unlocking more to appear on that board.
However, this new level was entirely linear, meaning that progression was always gated. At first I figured that keeping player freedom to a degree by allowing multiple options on a quest board was going to work just fine, since the level space was still open in the parts before the ‘gated progress’ blocker. The real problem came with the Tanuki character. Initially, I hooked up the system to display dialogue, which in turn would reveal quests on a quest board, like he had written up ‘errands’ that you needed to run.
While we kept this system in the prototyping phase to figure out what they looked like and how the exact quests were going to work, I quickly saw through playtesting that the board became confusing. Now you had two points of interests, and one was always bottle-necking the other. You couldn’t talk in an engaging manner with Ponpon to progress the story unless you completed his ‘tasks’ but you couldn’t just go to one place to get new ‘tasks’ since those only came from talking to Ponpon.
I quickly realised if we wanted to have a quest giver in this way, we were going to need to scrap the quest board idea. If Ponpon had a story to tell, then he needed to be the main focus for the narrative and the quests. Daniel, my programming lead, helped me set up a direct link from the system to the dialogue using a dialogue plugin (link) that allowed us to call events, which could set a quest to being active. In this new way, I was able to now tell a much more focused story and center these quests around Ponpon and his shenanigans within Cat-world.
And that was the next part of the challenge. Previously, all quests had just been written up in a manner that made them stand alone. I wrote them through the lens of helping out ‘one person within Cat-world’ rather than a specific someone throughout the course of the game. Since Ponpon was a more fleshed out character, and he was the main quest giver, I rewrote a lot of the quests to tell a more coherent story. I also included a bit more of a focus on how he would see the cats within the world as ‘customers’, and encourage the player to bring him unique ability cats in a way that was tied to the narrative. Let’s talk about how some of the quests were designed.
Designing Quests (as a Level Designer)
As this was my first time attempting to design quests, and really looking through both a narrative and level design focused lens, I took the time to research a few different ways that quests were structured in games. Ultimately, I followed a 4 step level design progression, as I felt it would suit the experience of the game and our target audience: casual gamers who were looking for a fun time to catch cats.
I started off with a quest concept that would onboard the player. In the four step process, this is known as Ki, out of ‘Kishotenketsu’, a four step Japanese narrative technique that I have used many times within my level design progression. The idea is to start with an introduction, and slowly teach the player what they need to know (known as ‘Ki’), before developing it further by allowing players to practice their moves (that’s the ‘sho’), and ultimately putting a twist on the knowledge to keep the player engaged (this is ‘ten’). Finally, the ‘ketsu’ stands for a conclusionary moment to end the level off, bringing all the learned knowledge together. With other designers in my team, I planned out the onboarding sequence to be directly tied to chasing a cat, which went over and under obstacles and taught you the basic controls. Ultimately that cat runs into a bush, and you are encouraged to speak to Ponpon to start your journey into Cat-world.
To facilitate this quest, I needed to make sure that I had a way to clearly explain to the player that the cat was hiding in the bush, and that Ponpon was a person of interest for them. I decided that I should learn a new skill and develop a short and simple cutscene that could showcase my intentions! Here is what I came up with:
The cat was then spawned back into the game when the first quest became active. I made sure to restrict its roaming area so that players would be able to keep it within their cone of vision, since most players at this point would not have much experience with the game.
The next step was allowing the player to practice catching cats. This was going to be the ‘sho’ part of Kishotenketsu, the ‘development’. I decided on a very simple quest: ‘Bring Ponpon more customers!’ The idea was that the player was able to explore the level for the first time during the game, so I also leaned into this exploration nature by allowing them to bring back any 2 cats they found in the level as part of the quest.
After they were able to get some practice in, I decided to introduce the twist, the ‘ten’. We had ability cats within our game that had abilities designed to change your approach to catching. I introduced the player to this mechanic with a bit of a longer quest I called ‘Blooming Business’.
In the quest ‘Blooming Business’, Ponpon asks you to bring him a ‘Flower Cat’ that shoots out pollen, which he claims will allow him to attract more ‘customers’ as the pollen might have similar effects to Catnip and be enticing to cats. Of course, the quest doesn’t go as planned and Ponpon quickly becomes allergic to the pollen he has spread around him, prompting him to move location which allows the next area to be unlocked and the game to progress forward. This serves as both a narrative element in Ponpon’s character and the story within Cat-world, but also onboards the player into the ability cats within the game. Overall, I’m quite happy with how this series of quests connect together to ease a player into the game, serving both a narrative and a gameplay purpose.
Implementation
Implementation went quite smoothly thanks to the help of a very modular system that Daniel had helped me build. It was a data driven state system, where we had three custom nodes that would interact with the quests inside a Blueprint, one when the quest was activated, one when the quest was completed and one to update it. This helped us section our quests off correctly, and a big game data tracker with all our needed variables were saved so that even when exiting out of the game you were able to continue where you left off!
The most challenging part of implementation was the dialogue. We were limited to interactions between the grandma player character and the Tanuki character not being too long or complex. In fact, the grandma didn’t have any kind of speech bubble at all, only responses in the form of scripted answers that a player could click to move the dialogue along. The system used a plugin, but it had a few flaws. Moving nodes around could often break things, and we found we didn’t have the time and scope to implement multiple branches. I opted for the solution of branches that converge again very early on, essentially giving the player the idea of their choice changing the dialogue, but in reality there was only a slight difference in the response before everything continued down one dialogue tree again.
By far the most useful thing was the events on dialogue. This is how we triggered quests and how we were able to call other events, like removing progression blockers, or teleporting Ponpon to a new location. The conditional checks allowed us to also play with the branches that the player would be taken to, allowing us to do things like loop back around or skip a branch that was already visited by the system.
While the writing took a large part of the time since getting a clear tone and vision was important, the overall implementation went quite well for first time quest designers!
Reflection & Learnings
While I could go on and on about the changes we made, the quests I designed or even scrapped, and the system as a whole, I feel that one of the most important aspects of this project has been its learnings.
As I mentioned in the previous Devlog, I am learning to be a quest designer, but have fundamentally started and practiced mostly as a level designer. However, the majority of my work on this project has definitely been a mixture of both, especially after taking the initiative to design a system like this and to have ownership over quests and the level. I think this was important for me to do, as I was able to refine a lot of my technical knowledge that I would not normally be compelled towards, as well as learning how to balance narrative, gameplay and navigation in a level. I learned how to design spaces that facilitate player expression through gameplay, but still guide you enough that you are able to know what to do and where to go without directly holding your hand; and how to teach the player to gradually learn and sharpen their skills (especially their cat catching skills!) while not making it an obvious part of the gameplay loop or dialogue itself.
I definitely don’t think that this new system is perfect either. It was a lot simpler to set up since everything became linear, streamlining the iteration process and allowing us to think about cause and effect a lot more clearer without any extra branches from a non linear system. It matched the level well, and in general maintained the player’s focus on one narrative and one centralised quest giver that became core to the game.
That being said, this was also the most challenging part of the system sometimes. Whatever quest you wrote and gave the player would have to be the quest that they had to complete, meaning that some players found certain quests to be ‘chores’ rather than fun gameplay, as you had no freedom. If a quest was confusing or boring, you were stuck doing it if you wanted to see the rest of the game. While I tried my best to avoid these kinds of quests, I by no means did a perfect job, and can definitely see the repetition of catching cats becoming monotonous. One approach I tried to take to fix this was by implementing 2 new types of quests, one where you had to locate an item in the level, and one where you had to use the cats to interact with specific objects to progress instead of bringing them back to the cafe. I think these things added a small breath of variety to the mix, but ultimately we could have designed a lot more variety in our quest types to really keep a player connected with the game.
Overall, this was a great learning opportunity for myself. I can definitely say that if I had a second try, I would bring in a lot of knowledge that could only improve what we have ended up with now, and I learned that I really enjoyed being a quest designer! It was fun to think in so many different hats together in one go. While I was already doing this as a level designer, it added a completely new layer when looking at it from a quest perspective, one that I really enjoyed.
If you want to take a look at the final product of what we ended up making, you can play our game Chasing Whiskers for free on Steam.
I hope that this was a fun read of my experiences and I hope to see you around in the next Devlog!
Comments