Part 11: Class beginnings
This series of posts is dedicated to building tools that support a simulation of simplified D&D gameplay. To implement the simulation I’ll be using git, Python, PostgreSQL, Elastic, and Docker. The idea behind these blog posts is to document my progress through this project and interesting bits I find along the way. If you’d like to start from the beginning, have a look at part 1, where I talked about where this idea came from, and what I’d like to accomplish. The github repository for this project holds the latest version of the files mentioned in these posts. To follow along, part 6 describes how to set up the environment. In this part, I’m adding to the discussion about classes, creating the basic player character class with python classes that will be used for the simulation.
About the cover photo: It’s Christmas time and the gaming/computer table has been overrun with the tradition of puzzles for the holidays. So, I’ll use this as the background for this week’s theme. Like the classic, “A Charlie Brown Christmas,” where the main character is puzzled about how he feels about and fits into the holiday picture, I imagine a player creating a character feels kind of the same way going into a new campaign. A player has the more complicated task of making a player character come to life with storytelling and roleplaying. The simulation doesn’t have to worry about that. It will, however, have to worry about generating all of the variations of a class that a player may be considering. That will drive the data and class design.
In the last post, I listed the Standard Character Altering Class Features (SCACFs) that are listed in the SRD for each of the classes. When the simulation builds the characters for a series, each combination of all the Character Altering Class Features (CACFs) should be represented. To facilitate that the lu_character_altering_class_feature_option table has been created to lay out all the available options. In practice, I would usually normalize the table to at least get the features out of it. I’ve held off publishing this post a couple times because I tried exactly that and it became just too cumbersome to work with. At this point, it would appear that having a single table housing the features and their options is the easiest way to keep moving forward.
Requirements for the PlayerCharacterClass and each class’s class are fairly straight forward. CACFs can be specified by sending in an array describing them or be randomly selected. Each of the classes has their own varied features that will be best suited by having the class inherit it from a PlayerCharacterClass. That way specific defaults, like class ability array order, or weapons, can be defined in the classes specific class. If one class handles magic differently (I’m looking at you Warlocks), it can be defined in the PlayerCharacterClass and inherited by Bards, Clerics, Sorcerers, and Wizards, while Warlocks override the default behavior. The naming convention used will be <ClassName>PCClass.py for all of the classes inheriting PlayerCharacterClass.
Each class also has a set of records in the lu_class_level_feature table. This table is the data equivalent of the handy tables in the SRD, basic rules, and Player’s Handbook that describe how the class features change given the character’s level. All of that data has been organized and loaded up so that a character created at a certain level will have the correct features available. Basic tests were written in test/test_PlayerCharacterClass.py.
That’s all that needs to be done to get the races and classes are in place. In the next post I’ll be laying the groundwork for character creation. Until then, Go Play!