top of page
Guilded
A strategy game where players send their adventurers on quests, taking their likes and dislikes into account.
Developed for Capstone 2019-2020
Onboarded to the project in January 2020
Gameplay Trailer and Development Information
-
Team Size: 13
-
Roles:
-
Systems Designer
-
Technical Designer
-
-
Tools: Unity 3D, C#, Adobe Suite, Google Suite
-
Full Development Time: ~6 Months (Mid-September - Early May 2020)
-
Logged Hours:
-
Individual: 125+ hours
-
Total: 2500+ hours
-
-
Platform: PC
Note: Trailer created by Zachary Phillips; music in trailer by Max Johnson
Intent Statement:
Guilded is a game about characters, groups, and their stories. Players take on the role of the leader of an Adventurers Guild, where they send adventurers on quests, accounting for how well they work together based on their skills, personalities, and relationships with one another. With procedurally generated characters, narrative, quests, and items, every playthrough of Guilded is different from the last, and every ridiculous conflict will have varying outcomes. Similar to games such as Rimworld and the Sims, the motivation for playing this unique strategy game is as much about progression as it is about the stories you create by playing.
Personal Contributions:
-
Designed and contributed towards several systems, including adventurers' inventories and adventurer death
-
Programmed and implemented various things, such as the tutorial and UI hover-over effects
-
Worked to balance several important systems, including adventurers' EXP gains, adventurers' morale, and the in-game economy
Design Work:
Systems Design
Role and Design Process
When I first joined the Guilded team in January 2020, my goal was to help them create and develop a variety of fun, interesting systems they were looking to implement in-game. My tasks in this role included designing an inventory system, designing a death mechanic, and redesigning the existing economy system to make gold a more valuable and more interesting resource.
Designing the Inventory System
First, I set out to work on the inventory system, which my teammates and I agreed would help make the procedurally generated characters even more interesting. My first design for this system allowed adventurers to hold five separate items: a weapon (which boosted their class' main skill and some random secondary skills), an accessory (which performed a variety of effects), two consumable items (which adventurers could use to help them complete skill checks), and gold.
Some of the team's other designers initially wanted adventurers to be able to have armor, as well, since that fell more in line with traditional RPG mechanics. However, I was cautious about adding armor into the game. Characters in Guilded do not have hit points, and while we had not come to a solid consensus on how we wanted the death mechanic to work at this time, we knew that we wanted it to occur only if adventurers failed to make certain skill checks while out on a quest. Because of this, I believed that adding armor to the game was unnecessary, and that it would only confuse players (who would likely assume it would prevent their adventurers from dying). I expressed this opinion to the other designers, and they agreed.
A screenshot depicting the original inventory UI, which we retained until late in development. Note that there are sections for a weapon (top-right), an accessory (top-left), two consumable items (middle), and gold (bottom).
As the semester progressed, our plans for the inventory system steadily changed. First, we decided to make weapons be procedurally generated, rather than set. We realized that doing this would help to make them even more interesting and engaging, and it would help them fit with the game's use of procedural generation for other systems (including the adventurers and quests). To accomplish this, I spent some time collaborating with our two narrative designers, Jeffrey Friedman and Genevieve Guimond. We eventually decided to make weapons feature three key components: the weapon type, the material, and an adjective. The type influenced which classes could equip it, while the material and adjective both determined its gold cost and which stats it boosted. For example, a warrior could wind up equipping a "Wooden Axe of Nightmares." This made weapons a bit stranger, which helped them better match the atmosphere we wanted to establish in-game.
Unfortunately, as we approached our deadline, my team realized we could not complete every aspect of the inventory system. We ultimately decided to cut accessories (which were referenced in-game but lacked functionality) and consumable items. We were, however, able to keep weapons and gold, since their systems functioned as necessary. As such, while we did have to significantly cut down on the system to get it working in time for release, we were at least able to implement a fairly robust set of procedural weapons in-game.
If adventurers have enough money, they can choose to visit the blacksmith between days at the guild to either upgrade or replace their current weapon.
Designing the Death Mechanic
Death was a mechanic that the original team had wanted to implement for quite some time, and it was one that I was eager to tackle and try to balance. Originally, the harshest penalty players faced for failing a quest was that they would not earn any gold, which could severely hamper their ability to complete the current event. Death was meant to add an extra touch of suspense to sending adventurers out on quests.
I initially designed death to be an uncommon-but-devastating occurrence. This is because it could take several in-game months to train an adventurer from Level 1 to the point where they switch to an evolved class (Level 11), so making death too common would only frustrate players and make it incredibly difficult to raise a strong adventurer. As such, we designed perilous quests to make death less common and easier for players to avoid. Perilous quests are incredibly difficult quests, where adventurers have a chance to die whenever they fail their skill checks. In exchange, however, succeeding on a perilous quest rewards players with a massive amount of gold. Additionally, because adventurers cannot die on non-perilous quests, players are able to ignore them if they are particularly attached to their adventurers and do not want to risk any of them disappearing.
An early screenshot depicting two adventurers dying on a perilous quest.
To make death even less likely, I originally designed perilous quests so adventurers would only have a chance to die if they failed three or more skill checks. However, my teammates feared that this was too limiting and made it incredibly unlikely that adventurers would ever die. Because of this, we all agreed to make any failed perilous check have a chance to result in death, instead. We soon found that adventurers were dying far too often on perilous quests, which led to players (and even us developers) avoiding them during test sessions. To fix this, we significantly reduced the likelihood of adventurers dying on perilous quests. This, in turn, made perilous quests much more approachable and much less frightening.
Redesigning the Gold Economy
Prior to onboarding, gold in Guilded served three purposes. First, it acted as a general reward for clearing quests. Second, it acted as a goal for players to reach, since they needed to acquire 4,000 gold before the end of January to clear the first event. Third and finally, it allowed them to hire new people into their guild. While this was sufficient at first, we soon realized that players did not have anything fulfilling to spend their gold on, which made it feel useless once they cleared the first month and no longer had to make a heavy payment. As such, I decided to expand the gold system to give players areas to sink their money into.
First and foremost, I developed a salary system. At the end of each in-game week, players would have to pay each of their adventurers a certain amount of gold. Failing to make this payment would result in the adventurers taking a heavy blow to their morale, making them more likely to leave the guild down the line. I initially designed the salary formula to be as follows:
(FullMonthsAtTheGuild * 5) + (Level * 5) + (HighestSkill * 2). This meant that salaries quickly increased as characters leveled up and improved their skills. As a result, players would have to send them on more difficult quests - which they could now reasonably complete - if they wanted to make enough gold to fully compensate them.
The NPC screen, which contains sliders for each adventurer's salary. Players can move these sliders to pay their characters less than the requested amount, with increasing morale losses as they pay them less.
Another change I made to the gold system involved raising the cost of hiring new adventurers. Originally, new adventurers requested a fairly small down payment of around ~400 gold before they would join a player's guild. I changed this so adventurers would instead use the following formula: ((Level * 30) + (HighestSkill * 10)) + 100. This meant that new adventurers would become significantly more costly as their level increased, which would allow players to hire them for a high starting price without having to level them up. As a result, I hoped that hiring new adventurers would serve as a gold-sink on two fronts. First, players would have to pay the initial fees, which could be fairly high; and second, they would have to start paying the new adventurers' salaries each week. This also meshed fairly well with the death mechanic, since if a character died, a player would likely want to replace them as soon as possible in order to avoid losing out on any gold from quests.
An image of the in-game adventurer market. From left to right, the adventurers are requesting 555 gold, 696 gold, and 834 gold, respectively. Each of these values (and especially the latter two) are far greater than the old hiring fees.
Technical Design
Role and Development
While working on Guilded, I used my experience with programming to help the team implement several key systems. Some of these systems included the game's tutorial and tool-tips that appear when players mouse over certain in-game objects. Regardless of the system, I always strove to program them in a way that was clear, readable, and decoupled. This would help ensure that, if it ever became necessary, the team's programmers and our other designers could go in and make changes without needing too much help. I also ensured that my code always had several public-facing variables, which would let code-averse designers easily tinker around with them.
A screenshot depicting the tutorial in action. Two of its key components include a dark overlay that highlights relevant parts of the screen (center) and a dialogue box, which players can advance via a moving arrow button (bottom). Developers can edit the size and position of each overlay, as well as the text, in the inspector window.
Developing the tutorial was particularly interesting. As can be seen in the above image, my team wanted to make the tutorial a single, uninterrupted string of events that combined text, screen overlays, and player actions. This would give players some practical experience messing around with the core mechanics present in Guilded, such as sending their adventurers out on quests.
To make the tutorial function in the intended mannger, I set it up three major scripts. The first one displayed the semitransparent overlays, which developers could edit via the inspector window. The second script displayed dialogue strings according to passed-in values. Finally, the third one ran the tutorial event as a coroutine. To help establish a solid, easy-to-read timeline, I designed this coroutine as a series vertical "blocks" of code. Each block contained a single part of the tutorial event, which advanced either automatically (overlays) or via player interaction (dialogue and button-presses). I also labelled each group according to its part in the event, allowing developers to move them around and make changes as necessary.
Code taken from the beginning of the "Event" coroutine. Note that each block contains a single part of the event, and that the game stalls while players either read through dialogue strings or need to click a specific button to advance. Click here to see a larger version of this image.
While developing the tool-tips, I instead focused more on creating a simple, efficient script that would let designers attach the code to almost any in-game object. This helped to rapidly speed up the process of creating them while also ensuring that code-averse designers would never have to move beyond Unity's inspector. Originally, the tool-tips appeared as child objects of whatever I attached them to. However, I soon discovered this did not work well with the many world-space canvases present in Guilded, which caused the UI to appear off-screen or at a bizarre angle. To fix this, I created a dedicated canvas that would hold these objects, instead. This completed fixed the problem and allowed me to design tool-tips even for non-UI objects.
A screenshot of a tool-tip appearing when a player mouses over the calendar button (left) and the attached script players can edit to mess with the tool-tip values (right). Note that developers have a fairly wide variety of options, as they can adjust the type of tool-tip that appears, its direction relative to the mouse, and certain size values. Click here to see a larger version of this image.
A screenshot of some of the code used to create the tool-tips. When a player mouses over an object, the game calls either the "OnPointerEnter" event (for UI objects) or the "OnMouseEnter" event (for regular objects with a trigger collider). This makes it much easier to apply the tool-tips as need be. Click here to see a larger version of this image.
Gameplay Balancing
Role and Development
As development progressed (and particularly as we approached our release date), my team turned our attention towards balancing the myriad systems present in Guilded. During this time, I initially took responsibility for testing and balancing our game's leveling curve. I tested out several different formulas and communicated my results directly to the team, where I also noted anything else I found important (such as bugs or frustrating design elements).
Logs from two separate test sessions I performed over Mattermost. In the first test (top) I implemented a new EXP formula and played for nearly two in-game months. In the second test (bottom), I played through once again using a slightly modified formula, which allowed for a slower leveling curve. Click here to see a larger version of this image.
After spending roughly a week working on the leveling curve, fellow designer Jeffrey Friedman took over working on that system. I then moved to balance the game's economy, instead. Around this time, we realized that quest rewards often felt weak and unfulfilling. Easy quests offered pitiful rewards that sometimes fell below 100 gold, while perilous quests (which, at the time, were synonymous with hard quests) did not offer nearly enough gold to justify sending adventurers on them.
To mitigate this issue, I went into the game and modified the values for each quest's reward according to their difficulty. Originally, I used a simple catch-all formula that determined rewards based on a quest's difficulty and the number of skill checks adventurers needed to make along the way. However, I soon found that this did not work as well as I had intended, as it did not help to fix two of our core problems. First, it was still incredibly difficult to complete the first month's event, which required players to accrue 4,000 gold. Second, easy quests and medium quests were still ultimately more lucrative than perilous quests, since their numbers scaled at the same rate.
One of my tests shortly after implementing the universal formula. Around this time, I began setting up more in-depth goals and methods before each test. I also went into greater detail when describing my results. This allowed me to more easily understand and modify my results appropriately. Click here to see a larger version of this image.
As such, I decided to go back to the drawing board. Rather than using a universal formula for every quest, I changed it up using a modifier variable. This was a float value I applied to the formula depending on each quest's difficulty level, allowing me to create a much wider and more diverse range of quest rewards than before. It also made perilous quests much more lucrative, since most of them now gave upwards of 2,000 gold per run, while easy and medium quests averaged out to around 750 and 300 gold, each. After I made additional changes to these numbers, my team felt satisfied with the new quest rewards, allowing me to move on to testing another part of the game.
Around this point, I started looking into the morale system. In Guilded, each character has a morale meter, which increases or decreases depending on whether or not the player takes actions they like. For example, sending an adventurer on a quest with one of their friends will cause their morale to increase, while sending them on a quest with an enemy will result in the opposite occurring. If an adventurer's morale falls too low, they will leave the player's guild.
One of our core frustrations with the morale system was that most of the time, players would never get to a point where they would be at risk of adventurers leaving their guild. As such, I decided to make many of the numbers - and especially the decrements - more extreme. For example, initially, sending an adventurer on a quest with an enemy would result in them losing 5 morale. To make this a costlier decision, I made it so they lose 15 morale, instead. This ensured that they would lose morale even if they succeeded on the quest. I also changed increased the amount of morale they lost when players did not send them on a quest from 1 (after 7 days of inactivity) to a random range between 3 and 6 (after 1 day of inactivity). This made it far riskier to leave adventurers in the guild for too long.
One of the tests I performed while working on the morale system. When testing this system, I sent adventurers out in pairs and recorded their morale gains or losses based on their relationships and quest success rate. This allowed me to easily discover whether characters were gaining or losing morale too quickly. Click here to see a larger version of this image.
After performing additional testing and messing with the numbers even more, I have brought this system to a much more comfortable position, with there now being a legitimate risk of adventurers leaving a player's guild if they are not careful enough to treat them well.
Genevieve Guimond*
Narrative Designer
Meet the Team
James Van Nuland
Producer
Charles Grabber*
Producer
Zachary Phillips
Lead Designer, Product Owner
Joseph Siehl*
Systems Designer, Technical Designer
Jeffrey Friedman*
Narrative Designer
Maxwell Johnson
Sound Designer, Composer
Kenneth Taylor*
UI Artist
Grace Magnant
Lead Artist,
Environment Artist
James Griffiths
Lead Programmer
Marianna Messana*
Character Artist
Austin Laimos*
Programmer
* Onboarded in January 2020
RJ Bourdelais*
Tools Programmer
bottom of page