I don’t get a whole lot of time to work on World Serpent directly since I started my job but I’m learning a lot and in my free moments I’m redesigning a lot of the program on paper. I’ve also built a few prototypes to test ideas to incorporate later.

An idea that’s been percolating the last couple weeks is that I’ve been doing something fundamentally WRONG with my approach to organizing character data. This culminated in a realization yesterday regarding character kinship, and another this morning regarding factions and inventory.

It’s all well and good that a character should be associated with their stuff, for example. But that character doesn’t necessarily need to “carry it around with them” in the programmatic sense. All of their equipment can be stored in the same place (programmatically) as every other single piece of equipment in the game, and only called up as necessary. Among other things, this makes it possible to query the “game items” to find out how many swords are presently in circulation.

Maybe this seems like an obvious thing to some, but it’s a recent development for me.

One of the ideas I’ve been wrestling with for a while is how to organize factions. Sure, I’ve HAD this idea of spontaneous formation of factions for X, Y, and Z purposes, but a lot of my problems came back to, “where do the people come from?” There were additional problems regarding where the people go when a faction disbands, or how to track when a faction “promotes” to a new scope.

Many of my problems are actually addressed in the same fashion.

Characters (as in, those who would affiliate with a given faction) are stored in a Singleton “manager” object. Factions (as in, those with which characters affiliate) are stored in another Singleton “manager” object. When a character affiliates with a faction, they add the faction’s ID to their list of affiliated factions. Likewise, the faction adds the character’s ID to their list of affiliates.

Alternatively, a secondary object manages “relationships” between characters and factions, much as you would create a table in a database to manage those many-to-many entity relationships. Those relationships likewise become queryable. “How many characters belong to X faction?” Et cetera.

In a similar fashion, a character’s equipment is stored in a Singleton manager. The relationship between a character and their equipment (whether stashed or carried) is then stored in a secondary manager, which helps again, with those many-to-many relationships.

Sure it adds a layer of complexity and abstraction to the process, but at the same time it saves some headaches and it removes the dependency of some programmatic objects from others. Now a “character” doesn’t necessarily care if all the items have been loaded up, because really they only talk to the Character-Equipment manager whenever they need to find out how much stuff they have on hand. (And how often does a player actually read their character sheet anyway, amiright?)