I pulled off a pretty significant refactor after spinning off the crew/faction project.

Uh, at the point I reached I was no longer contributing directly (or indirectly) to the character generator project, and it just made sense to spin it off into its own thing. When I return to CharGen, I’ll most likely be writing a new faction system in code anyway.

Phew, it was a doozy of a refactor. I split off “Action” into its own object and moved around a bunch of the enums I’ve been using to differentiate between types (and types of types, and so forth). I also took the opportunity to move around more stuff into appropriate sections of the code. Things were only “truly broken” for about 20-30 minutes while I reorganized the project.

Then I ran it again, and everything was fine. Yay?

So, there’s a new GitHub link: Blades in the Dark

It has all my current progress on the faction system as derived from Blades in the Dark. It’s my intent to adapt the “best parts” of the faction system and eventually incorporate it with my existing Ladder system to create a more formidable faction system that accepts characters and monsters as members… for the ultimate purpose of creating a dynamic dungeon environment.

Really, the spinoff and refactor were necessary, as the “Blades in the Dark” portion of the project had outgrown the relatively small corner of the CharGen project it already occupied. The refactor moved hundred of lines of code into their own object(s) which made them more accessible to outside objects (Actions had really outgrown their inner class-status).

And it makes more sense to move BitD out of the 30+ class behemoth represented by CharGen, and into the more respectable uh, 8 classes that it is now. I will probably spinoff a few more of the inner classes as they outgrow their current confines, notably Downtime. While working on the refactor, I also noted some enums that likely belong in other classes, such as “Crew Activities.”

It made sense in the original context of my “Score” object, that Activities (which were random at the time) go into the Score object, since they were only used locally. I hope to create a “Job” object though, which is created whenever a Crew/Faction needs something done… that incorporates however many parts are actually needed/desired by the job-creating Crew/Faction, to be extracted during the actual execution of a Score.

For example, a Crew/Faction might want X objective completed, but not care about how it’s done–leaving the actual Plan portion up to the completing Crew. Sometimes a client will be more demanding, requiring X, Y, and Z to occur. But I can’t do that by passing a bazillion objects to the Score constructor, I’d rather create a “Job” ticket and have the Score pull out the required pieces.

Ultimately, I hope to pass the Score a “Job/Ticket” object, containing all the pertinent details. From there, it can pass the results to a “Downtime” object to sort out the various consequences and update the states of Rogues, Factions, and the like.

There are a million more things to do, so I’m going to cut this off here.