Welcome to the Code Mines, our (mostly) weekly development blog on Administratum. In these posts we’ll be talking about the process of building Administratum, the thought behind some of the features, and our approach to making it the best tool for campaign management on the web.
As I’ve been building Administratum, the most requested feature has been the ability to edit games, and rightfully so! After hours of intense gaming, the last thing you want to do is meticulously proofread your homework. It’s only natural to record the bare-necessities and want to come back to it later.
But this begs the question, why can’t you edit games? Or at least, why couldn’t you until the Big Game Editor Update?
Even if it’s just editing your victory points. That should be simple, right? I mean it’s one integer. What could it cost? Ten lines of code?
But there’s a reason why it’s taken so long for Administratum to get support for changing the past, and let’s get to the bottom of it. So, grab your hardhat, pickaxe, and flashlight as we delve into the Code Mines.
The Grandfather Paradox
Go back in time, kill your grandfather, but now your father isn’t born so you don’t exist to go back in time to kill your grandfather. What happens, what’s the solution? Turn out, I have discovered a truly remarkable solution for this paradox which the Code Mines is too small to contain.
But the paradox is also like the one that faces Administratum when you edit a game. Imagine winning a game and earning a Victor Bonus that grants you an additional Requisition Point. You use that Requisition Point to increase your Supply Limit, and you add another unit to your Order of Battle. But alas! You review the game and realize your mistake – you actually lost the game! So you edit the entry in Administratum. You change the past and now what happens?
You’ve already spent the Requisition Point – does Administratum rewind that? What about that new unit of yours? Shame if the timestream snapped it out of existence. How far does this change ripple? If you recorded a game with that new unit, does Administratum change that too? How corrupt is this new future, how insidious and vile, is nowhere safe?
And what of your Requisition Points? What if you were at zero when you H.G. Wells’d it? Do you enter the shadow realm of negative Requisition Points? Do you owe 1 RP to the bank? Do you go to RP debtors’ prison, do not pass Go, do not collect $200?
How far should Administratum go to rewind time? How aggressive does it roll things back? Does the fourth ball fall back up the cliff and take the place of the third?
But I Digress – Let’s Break it Down
Fortunately, these questions were things I considered long, long ago when Administratum was but a twinkle in my eyes. I knew what the solution looked like, even back then. I also knew it wasn’t actually a Grandfather Paradox, but dang is that catchier term for the problem than the more accurate description of “software be hard, yo”.
To dig into how this works, let’s look at an Order of Battle. Administratum refers to these generically as “rosters”, so I use the two terms interchangeably.
Now this isn’t actually what a roster looks like in Administratum, not by a long shot. But for the sake of this delve into the Code Mines, it’s accurate enough.
You’ve got your standard entity identifier, along with some properties which describe your roster. Requisition Points, supply limit, and the number of unclaimed rewards you’ve got waiting for you.
When you record a game, Administratum creates something that … well … doesn’t even look like this. But again, it’s close enough to be useful here.
When this game is recorded, Administratum applies the Victor Bonus by incrementing the roster’s “requisitionPoints” property, nice and straightforward. And reversing this reward, in the example roster from above with 3 RP in the bank, it’s also simple. If you edit this game to be a loss, then Administratum handles it easily.
Administratum simply backs out the reward. You’d drop down to 2 RP and go about your merry way.
The complication in this example is when you are sitting at 0 RP and you tell Administratum to remove one. In this case, I took the high road when building Administratum. I did the noble thing. I simply brush my hand of the matter and let you know there is a problem.
It’s a simple solution that doesn’t get in your way. But it was just a matter of checking a single integer, why the fuss? That seems like it should be a day-zero feature!
Will the Real Complication Please Stand Up?
The complication isn’t handling this one specific roster, this one Victor Bonus, and editing the game in this precise way. It’s handling it for all possible roster configurations, all possible Victor Bonuses, and all ways in which a game can be edited.
Administratum currently supports 14 different Victor Bonuses. Most impact the roster (e.g. Requisition Point, Increase Supply Limit 1x), but some impact individual units (for example, Marked For Greatness 2x). Some look like they should be tracked on a unit, but are actually tracked on the roster until you claim them (like “unclaimedWarlordTrait” from the example roster).
Additionally, some Victor Bonuses affect the same field as other bonuses, but do different things to it. Increase Supply Limit 1x and 2x each give you unclaimed uses of that requisition, but a different amount of them. Some Victor Bonuses affect multiple fields, like “Increase Supply Limit, Rearm and Resupply”. All bonuses are tied to fields that have a minimum (you can’t go negative), but only some of them have maximums (can’t have more than 5).
And don’t forget about the bonus for winning a game in Wars of Faith! Can’t leave that out. And don’t forget that the field itself is a freeform text field, so you can actually type whatever you want.
Okay, that’s kind of complicated-
Hold on, I’m not done. So far I’ve only talked about this in context of changing a win to a loss: removing a reward.
But you can also change a loss to a win, which means adding one of these rewards where it wasn’t one before. Largely this is simple, as this is identical to recording a victory in the first place. However, it’s still another thing that Administratum must handle correctly.
And then we have one final case: keeping a win as a win, but changing the Victor Bonus. This creates a fun combo: all the complexity of removing one reward stapled onto to the complication of adding a different one.
Well, At Least That’s Everything
Administratum just needs to handle all the different victor bonuses: the ones that affect single fields and the ones that affect multiple fields, affect them in different ways, are subject to minimums and possibly maximums, rewards on rosters and rewards on units, and whether you are adding and/or removing the reward(s).
All of that and you can finally edit the Victory Points of a game.
Pay no mind to the other dozen top-level properties of a game. Surely no one wants to change a game’s date? Or change its mission, opponent, or size? Surely no one wants to change which campaign a game is associated with? Surely.
And surely campaign owners haven’t been asking to edit games that are associated with their campaigns. Why, that would require its own separate delve into the Code Mines!
Oh. Oh, wait no. The opposite of all that. Those all have been asked for, and they all shipped in the Big Game Editor Update.
At least that’s everything. Game editing is finished and I never have to worry about it again. Surely nobody will ask to add or remove units to a game, or change how many units they destroyed or how much XP they earned.
Surely.
