Obligatory GitHub repository link.

The last several days I’ve been working on enabling factions to hire other factions. Actually, I wrote in the faction-hiring process pretty quickly–I’ve spent the last several days refactoring and debugging it.

I wrote an algorithm to choose among a crew’s relationships, based on the presence of relationships with a given status (-3 to 3). A crew is MOST likely to receive a call from one of their allies, but even their worst enemies have a 5% chance to call on them for work.

Weird though it may seem, this is a built-in method to break out of “eternal wars” between the crew and… other factions, as completing a job brought to you by another faction improves your standing with that faction. Of course, botching the job makes things worse between you. There’s always that.

Last night I ran a simulation where a crew was able to improve its hold after pulling off a job for an enemy they were at war with–it was a pretty cool coincidence. I mean, aside of that specific event, there isn’t currently a way for a crew to advance once they’re “at war” with another faction. (It’s something I’ll fix later.)

One of the things I plan on inserting into the typical job, is a chance (upon a badly rolled check), that a rival or enemy faction will appear as a “complication.” In this way, it’s possible while performing a job for Enemy Faction A, to get a complication where Enemy Faction A shows up to cause problems. It’s like a built-in system for random betrayal!

Because really, one of the things Blades in the Dark warns against is “screwing with the players” during the payoff part of a score. If they complete a job, they should get paid. And I’m down with that. But it seems logical to screw with them during the job itself.

I have a weird bug that’s eluding me at present–about one in ten jobs both increases and decreases the status with one faction. I don’t know why. I can’t reliably duplicate the bug, so I can’t isolate what’s causing it.

Ugh. I’m really looking forward to finding a good stopping point with Crews/Factions, because I want to implement either a database for storing the generator’s output… or monsters… or I don’t know… an overhaul of the codebase in service of either of those goals.

I don’t know if I’ll spin off the Blades in the Dark stuff into a separate project once I’ve finished, but it’s something I’ve considered. It has been a great learning experience but when I’m done I’ll abstract what I have into something I can use in the greater CharGen project.

UPDATE: Holy crap, I figured out what was causing my bug. So, in the original implementation of my faction-hiring process, I used two separate classes/enums to initialize and categorize factions (e.g. “crews” and “factions”). I had actually considered this problem before, where initializing a faction meant creating a relationship with other factions that hadn’t been initialized yet.

Part of the problem with one of my recent refactors is that it broke my previous implementation of crews/factions, leading to this weird problem where initializing the factions meant calling the list of factions before it had finished initializing.

I’m in the process of fixing the problem by implementing a design I had intended to do later–now it’s necessary because well, I reached the point of necessity. I wanted to create a Set of all faction relationships for ease of reference. This design comes with its own problems, which led me to finally realize why there are so few Set implementations in the standard Java library.

I mean, if my understanding is correct, part of the reason there are so few Set implementations is that to make an effective set (with add/contains), you need to define INDIVIDUALLY, whether an element exists in the Set. This has to be done on a case-by-case basis because there’s almost no guaranteed way for Java to know if you consider a Set to contain an element the way YOU consider it to contain an element.

My mind is blown.