Guilded
Description
Guilded is a game about people, personalities, and their interactions with the world. Players take on the role of a guild master, and must give quests to their adventurers, making sure they know how characters interact with each other to ensure success on every quest.
This started as a senior capstone project in the fall semester of 2019. We were given the opportunity to move forward with this project in senior production in the spring of 2020 - increasing our team's size and being able to make something great!
My Contributions (Fall Semester)
For the first half, our team was only five people. A lot of what I did was centered around setting up systems for loading in files, generating characters and quests based on the parameters in those files, or other factors.
Mostly, I created a flow where a "pool" object interfaces with a class called the XMLloader. That reads in from files, to hold all data from the files in memory during run time. Then, when we need, we can create something random from those pool objects! For example, an NPC pool would contain all possible NPC names, along with data for those NPC's "jobs" in game. Another pool for the quests holds everything related to quests, which are generated in a "madlib" style.
NPC personalities was the part that scared me, but it actually didn't turn out to be too difficult. We figured that NPC personalities can just be separated into quartiles for how they would act in game. A character with a "65" in empathy, wouldn't act much different from a character with "55" in empathy. But, a character with "-55" in empathy would act quite a lot different from a character with "65" empathy.
However, it's important to note, that the NPC does not control the logic for how it would act based on their personality, or otherwise. Other things ask what an NPC has, and force the NPC to react accordingly. This is important for decoupling of code. With systems needing to only interface with an NPC object with a few generic accessors, and then they can do what they need with an NPC.
Moving into the Spring Semester
In the spring, semester, we continued to work on the project. This was also my first time as a lead programmer, which was a little scary.
It took me a little while to get used to being a lead. I've always been used to just sitting there and doing tasks, but I had to take on a more managerial position. It took me a little time to warm up to the idea of it. That I needed to just trust my programming team. Although, after the first two weeks or so, I had 0 doubts about the team!
We first started work on the embark system. Creating a system that made sending out adventurers on quests a lot more fun. However, I had to spend some time fixing up my tools, and expanding the deed system that I created. Our new narrative designers wanted deeds that could branch out and tell even more stories. This meant that I had to go back and refactor the original loader, as well as expand the deed system I wrote to make it a tree.
Those two really weren't bad. The only difficult part with setting up the trees for branching deed paths was ensuring that the correct one was picked. To do so I used an array of child nodes for each deed. When a deed was resolved, I'd return a tuple with the index of the child node to use, should a child node be used.
After that though, my work got a lot easier. I was able to move to a more managerial position as lead programmer. I got to work closely with the artists to ensure that our art asset pipeline was working, and that everything was looking good, and we still had a consistent 60 FPS. I also helped write some shaders with regards to our day night cycle, and helped our artist with moving UVs on the river in town to give it a sense of movement. (As an aside, I really wanted to write a realistic water shader using tesselation and subsurface scattering, but the lead artist vetoed that)