A Loud Argument

There are always casualties in war Lister. If there wasn't it would just be loud argument with lots of shoving.

So, PERCOM, the Battlestar character utility, is pretty much finished ! Thanks to unit testing I've got the Cortex trait system in place, and a nice dialog for selecting a trait with a given dice value. The skills, traits and equipment has been changed over, and the currency units have gone from credits to cubits. The only leftover is the archetypes . They wont take long, all I really need are :

• Pilot
  
• Marine
  
• Commander
  
• Technician
  
• Medic
  
• Scientist
  
• Civilian

And the civilian one is going to be unbiased, all skills and attributes will have equal weighting. So aside from the archetypes, and perhaps finding a better name (I hate PERCOM) its done. Perhaps I'll call it recruiter.....

The next issue I want to face is this : Combat with more than a couple NPCs. This gets really bogged down really easily. A 10 vs 10 fight really gets a lot of dice rolling and slows down the combat a lot. Previously I've mitigated this where I can by having fewer but tougher opponents.

But the upcoming campaign I'll be running involves a party of cadets and training officers. Thats a lot of potential NPC's, and a lot of dice rolling that is out of player control. This is distracting and the GM often feels the need to rush this so the players don't feel excluded.

How am I going to fix this problem ? Well, thinking on it, I have two options.

Mathematical Option
Use some maths so the NPC combat boils down to 1 or two dice rolls. Ideally two, with the PC friendly lot get one roll that the PCs can make and the hostiles one roll that GM makes. A little table (probably a spreadsheet) will distribute wounds to the losing roll, depending on the roll difference.

The Software Option
All the NPCs (even Cylon skin jobs) are held in data files from PERCOM. I could write another program that reads all those characters in and runs the NPC side of combat. Each character would be player or hostile flagged, and have a selection mechanism for picking their immediate target. It would track wounds, stun and have and handle initiative ordering. You would need to be able to add the players but mark them as players.

You hit a "start round" button and each NPC makes an attack or the action lined up by the GM in the software. When a player takes an action it can pause and ask for the dice roll. It would need to let the GM just skip the action if something was happening beyond its ability to track. It would also need adjustments to wounds and characters on the fly. Player attacks would have to be entered manually, of course.

Essentially it would just be a character spreadsheet, with macros. The disadvantage is that the NPC actions would just become the GM reading "Fred aims at the third cylon, fires, and scores a glancing blow." before clicking next.

So Which One?
I favour the software solution, but then it sounds something cool to write. I can't see how to realisticly shorten the combat with the mathematical solution without ending up with arbitrary values and results that seem beyond control.

Its more than a Loud Argument isn't it ?

Hooray for Unit Testing - Part Two

Following on from my last post about refactoring my character program from Serenity RGP to Galactica, I can now report that last night I finished fixing all the unit tests. So when I ran the program did it work or crash out badly? How comprehensive was my unit test coverage?

In theory , with all the tests fixed it should start. I should see Traits appearing as Dice values rather than Major or Minor. I timidly started the app, bracing myself for the biggest stack trace I'd ever seen.....

And it worked. Just like that, started up and displayed a character, with two complications (a D4 and a D2) and one D6 Asset. Wow, I hadn't expected that . Hoped for, but not expected.

Then I tried to add a new Trait and it bombed. Oh well, close enough to be pleased with. I was planning to refactor the GUI anyway, listing a bunch of Traits to choose from as a straight list , with each dice version of a trait as a seperate choice. I want a list of traits with each dice in a column to the right. Click on the dice for the trait you want.

Also on the boned list were the archetypes. This was a system where you could set up certain types of character (Fighter, Politician, Toilet Cleaner) and each archetype had weightings to favour or disfavour attributes and skills. Since the skills set and trait list were changed between systems I've dumped the old archetypes for now, I'll either retranslate them from Serenity or just write them again.

Now, should I look at the non-rectangular windows effects in java 6 and see if I can get the app to work with cut off corners?

Hooray for Unit Testing

I'm faced with doing asome NPC's for a Battlestar Galactica campaign thats coming up in my local RPG group. Now the systems pretty similar to the Serenity one, both being different versions of the Cortex RPG system. The big difference is in Traits, which in serenity can be Minor or Major in Serenity now can be a Dice from D2 to D20.

For example :

"Allure (minor)" becomes "Allure (D2/D4)"
"Dead Broke (minor or major)" becomes "Broke (D4-D12)"


I've got an NPC program for Serenity which I wrote and evolved over two campaigns and I'm reworking that to work with Galactica. My Trait object's go from being having an enum of Major Minor and Both, to having a list of dice types. This just means removing a field and replacing it with a List, and correcting all the ensuing errors that occur, followed by some UI work. Nothing major.

But can I be sure that something subtle isn't broke, some small corner of the app that shall remain forever buggered? No, you never can be. But the unit testing coverage gives me a lot more confidence that I would have had without it. I'm not even through fixing all the errors but I know that the three major parts of the app that touch traits now work with the the dice list, and I haven't even run it yet.

Unit testing lowers refactoring time. Hooray for unit testing !