I’ve written at length on this site about a long-running project of mine, the UESRPG Character Generator (sometimes abbreviated as UESRPG CharGen, or UESRPGCG, if you like letter-salad). I figured a more comprehensive showcase was in order, as I’ll be retiring the alpha version soon in favor of a different UI framework.
The app has been indispensible for myself and my playgroup as we have worked through our first tabletop campaign together. UESRPG is a very complex system, and many of us were first-time players of tabletop roleplaying games. To ease some of the mathematical heavy-lifting, I took on the effort of providing a (mostly-) usable app which makes those calculations for us!
Features
Note: I’ll be adding pictures soon!
UESRPG CharGen has a handful of features to help players of UESRPG keep track of their character(s) and abilities. As anyone with passing familiarity with Elder Scrolls and/or tabletop RPGs will know, a fundamental aspect of one’s character is the set of statistics making up said character.
In the Elder Scrolls video games, these are typically broken up between Characteristics and Skills, where Characteristics are general traits and Skills are more specific ones. Skills are governed by a particular Characteristic; for example, the One-Handed Weapon Skill would be governed by Strength. The same principle applies in UESRPG, but certain Skills can be governed by more than one Characteristic.
We also have a set of Traits, factors calculated from a character’s Characteristics which affect several aspects of combat.
Characters may manage their Skills, which can be “rolled against” to accomplish in-game feats, such as swinging a weapon. Characteristics may also be “rolled against” for more general tests, like lifting a heavy rock. Rolling against Characteristics involves some occasionally tricky subtraction, so the app comes quite in handy!
Magic is also a large factor in the Elder Scrolls games. Spells function similarly to Skills, and provide an additional layer of rolling that has to be accounted for. Spells are cast under a particular Skill (so, a Fireball Spell requires training in Destruction, which is governed by Willpower). The app allows players to specify how much a spell costs, how “difficult” it is, the kind of damage it deals, what Skill it is governed by, and an optional name and description. When it comes time to roll for Spells, one can simply click on the Spell in the list, and the correct Skill and difficulty are automatically populated in the Roll section.
How do martial characters deal damage? There are several complicated stat tables available which serve to model weaponry in the tabletop game. The app handles this for players by allowing them to select a Weapon type and material, then crunching all of the numbers for them. When Weapons must be used, the player can make a Combat Style Skill roll and then make a quick extra roll to determine the Weapon’s damage result.
Extra considerations are required for ranged weapons, which have even more complicated stat tables to model ammo.
Of course, if characters must get into the thick of combat, they will want some Armor to protect themselves. As we have seen above, tabletop games tend to model things with… you guessed it… complicated stat tables! Armor is handled for the player similarly to Weapons. Players need only select a material, type, and location, and the app does the rest.
A key weakness of the app’s Armor system, however, is that only one piece of armor of each type can (currently) be stored in the app. If you equip a new “Left Glove” to your character, the old one gets blown away. Yikes! A proper inventory feature is coming up in order to address this.
Even if they can’t afford to equip themselves, characters need a way to calculate how much damage they’ve received. When a hit comes in, players can select the location their character has been hit in, and calculate the damage automatically. The location is significant because characters may not wear helemets (egads!) or be wearing boots that are less effective than their gloves.
Okay, so we have all the ingredients of a tabletop game going, but what about other useful utilities, like tracking combat turns? The app handles that too, albeit in a rudimentary way. Players can open up the Combat window to have access to all the controls they need to participate in Combat rolls. They can even track when the baddies take their turns by adding “remote” combatants to the turn order.
The Game Master can use this screen to step through Combat turns character-by-character, and it will even save an active Combat if the session happens to end before Combat does.
The final planned features before laying the “Alpha” version to rest are XP tracking and an Inventory. There is still a ton of information needed to proceed through combat accurately, according to the rulebook, but the features outlined here have been sufficient for my group. I plan to have a more complete implementation in the “Beta” project!
Bonus: Design Approach
At the beginning of this undertaking, I had a naive impression of the level of work it would take to produce a working character-calculator. As such, my process didn’t include much planning ahead, and I ended up with a heap of spaghetti code quickly.
Detailed in my 2017 post on MVC (Model View Controller), I recognized the need to employ more formal software design practices if I wished to expand the app to any considerable complexity. That refactor has exposed several more annoyances on the way, and I have learned quite a bit about producing more user-friendly code.
Generally, with each update I try to move everything towards a state where the Model, the underlying data objects that make up the game, is untouchable without going through the Controller layers, which serve to expose “public” behaviors to the Views. My hope for the future is to have data interchange between the View layer and the Model layer take place through use of something like messaging, which would translate nicely to potential networked features in the future (like online multiplayer).
A big struggle I have had to deal with in working this way is that there tended to be a lot of duplicate code between different Views. For example, every aspect of the UI has to take some action whenever the active character is switched. These behaviors often look the same or very similar. I’ve done some work to abstract these behaviors out a bit, which has gone a long way towards reducing “kludge” in the View code. I hope to do a write-up on these restructuring efforts soon, so I won’t go too in-depth here.
Conclusion
The UESRPG Character Generator has been, to be honest, a bit of a headache. This has stemmed mostly from my initial naivety towards the project’s complexity. Bad architecture to start with forced me to play catch up the entire time. Partnered with the work of developing content for the campaign, it became a struggle to find time and motivation to fix my past mistakes.
Once those mistakes were ironed out, it became much easier to expand, though I was still left without much testing to verify my changes. Overall, I’ve learned the importance of separation of concerns–minimizing the sweeping changes that can happen as a result of changing one line of code. Such practices also help ensure that existing tests don’t break every time a feature is added. However, the lower likelihood of test breakage is not an excuse for neglecting to write tests 😉
I’m hoping to carry these lessons forward to the “Beta” endeavor, which will mostly consist of switching over from Windows Forms to WPF (Windows Presentation Format). The conclusion of our first campaign will also reduce the buildup of fatigue, allowing me more energy to contribute to the app!