Tip for Big Combats: Make a Table of When Reinforcements Arrive

DFRPG Arden Vul session 24a ended with the PCs in the dungeon, chasing retreating Settite guards down the stairs toward the Forum of Set.  So I knew that session 24b would start with a big set-piece battle.  Exactly how big, I was a bit fuzzy on, and the players had no idea.

So I went through the area around the Forum of Set and found every NPC that might possibly be involved in the fight.

I first identified the ones that were close to the bottom of the stairs where the PCs would arrive, and guaranteed to be attentive and hostile.  Basically, the ones they just chased down the stairs, plus the guards on duty in the Forum whose actual job was to fight off intruders.  Those were the Turn 1 opponents.  I made a list of those to make sure I remembered to tag them all as combatants in Foundry at the start of the fight.

I then went through everyone else in the Forum to figure out who would actively close with the PCs and fight, who would stand their ground and fight only in self-defense, who would hide, who would run away, who would go get help, who would hesitate and wait for instructions from their superiors, etc.  Most of these were pretty obvious, but there were some NPCs who could conceivably react in multiple ways, so I made reaction rolls for those.  High rolls were good for the PCs (usually meaning the NPC would only fight if personally attacked), and low rolls were bad for the PCs (usually meaning the NPC would actively help defend the Forum).  

I then repeated the process for other rooms in the area, compiling a list of everyone who would participate in the defense.  (The ones who would not participate could just be left off the list, saving time.)

The next step was figuring out how long it would take each potential responder to hear the news of the attack, get their equipment ready, and reach the Forum staircase where the PCs were likely to be.  For example a guard 50 hexes away might take 10 seconds to hear the news, 5 seconds to get up and grab their weapons, and 10 seconds to run to the battle, meaning they would join the fight on turn 25.

The last step was to make a table, sorted by the turn each combatant would arrive where the PCs were.  Then I could happily ignore all the offscreen action before then and focus my attention on what my players could see.  So if there were hypothetically 50 total NPCs involved, but only 10 of them started near the PCs, I could just play those 10, and ignore the other 40 until they arrived.  I just had to track turns, and when I got to a turn number when my table said some reinforcements were due, I could add their tokens to the map at the edge of the PCs' line of sight and add them as combatants in Foundry.

I want a consistent world.  I want things to make sense.  I want verisimilitude for my players.  I want a fair fight.  But I would also prefer that a combat turn take 5 minutes rather than 10 minutes, so it's good if I can avoid spending precious game time meticulously moving tokens around outside the players' line of sight.  If the players can't see something, the exact details don't matter.

So the takeaways are:

1. If there are things that you can just as easily roll before the session as during the session, you might as well roll them before the session.  Pre-rolling some NPC reactions let me take some NPCs out of the fight, saving time during play.
2. Feel free to put your data in the form that's easiest to use in play.  A map key with NPCs placed in each room is good for a static dungeon where the PCs are the only ones moving, but it's not ideal for a fight where the PCs are fairly stationary and the NPCs are moving toward them.  So make a new table, with the data in the most useful order: which turn each reinforcement will arrive, in ascending order.

How I'm dealing with friendly NPCs in DFRPG Arden Vul

Arden Vul is full of NPCs, some of them in town, some of them in the Halls.  Some of those NPCs are actually adventurers who might be happy to visit the Halls.  Some are friendly to the PCs, and might be happy to accompany them.

But I'm not generally letting the PCs bring NPC companions into the Halls with them, for meta reasons.  My general rule is that I limit delves to 5 PCs, because each additional player or token slows everything down.  NPCs don't slow things down quite as much as PCs do, because they don't add additional players, just additional tokens.  But they still add significant overhead.  I tolerate this for key PC powers that they paid points for -- the GOAT's summoned animals are annoying to manage, but he's a druid and summoned animals are a major part of a druid's powers so if I allow druids I pretty much have to allow summoned animals.  But I'm not letting PCs buy the Ally advantage (which isn't in DFRPG, only GURPS, so it appears Kromm agrees with me), or pay hirelings to come into the dungeon with them.

So, basically, my rule is that if you rescue an NPC in the Halls, they may stick with the party until you get them back to town, and they may be your friend in town or even let you hire them in town to do non-dungeon jobs, but they're not coming back into the Halls with you.  Because I don't want to deal with a party of 15 dragging the game to a crawl, making it less fun for everyone, and eventually killing the campaign.  Of course like all rules there may be very specific exceptions -- if one particular NPC really wants to do one thing in the Halls, they may ask to come along for one targeted mission.  (As an example, Thalia, the ranger the PCs rescued in Session 21, really wanted to kill the vile 4-armed baboon Umsko.  But since Uvash already killed him, she no longer needs to go back to do that.)

Note that this kind of rule varies from campaign to campaign, and from game system to game system.  If I only had 2 players, I would let them each bring an Ally, and probably have them run each other's Allies.  If I were running a very lightweight system with no VTT maps, I could be freer with NPCs, as they would require less work to keep up with.  So I'm not saying that GMs who allow tag-along NPCs are wrong, just that it's something to carefully consider rather than blindly allow.

How I Do Surprise, Initiative, and Turn Order in DFRPG

One of the DFRPG Arden Vul players asked how I do surprise and initiative.  I think I do them pretty much by the rules, but then most GMs probably think that, and yet they still do slightly different things because it's impossible to write RPG rules that are perfect and complete.  (This is the RPG version of Godel's Incompleteness Theorem.  If you can write perfectly clear rules for it, it's not complicated enough to count as an RPG.)

I use "Initiative" to mean the order in which combatants move in a role-playing game, and "Surprise" to indicate a special situation at the beginning of some RPG combats where some combatants don't get their normal actions until they recover.  ("Turn order" is a synonym for "initiative.")

GURPS initiative is different from initiative in most other role-playing games. Because there are active defenses, everyone's turns overlap.  Also, because all the turns overlap, there's a fixed turn order for the duration of a combat, rather than constant re-shuffling.  Surprise means that some combatants suffer Mental Stun and lose their turns until they recover, then proceed normally after that.  Dungeon Fantasy RPG slightly tweaks the basic GURPS surprise rules (see Exploits page 26).  I follow the DFRPG rules, but there's a certain amount of GM judgment required.

The first thing to consider is surprise.  There are three possibilities for a two-sided fight: nobody can be surprised, one side can be surprised, or both sides can be surprised.

Rule zero of surprise is that if there's no chance of surprise, you don't roll for it.  If two groups approach each other across clear terrain in broad daylight, you're done.

When there is a chance of surprise, you have to think about whether only one side can be surprised, or both can.  If two groups approach each other across clear terrain in pitch darkness, and one of those groups has Darkvision, they have a chance of surprise and their opponents do not.  Life isn't fair.  On the other hand, if two groups who've both been sneaky both turn a corner at the same time and end up meeting each other at close range, they both have a chance at surprise.

The rules say you can only achieve surprise if you're being sneaky (meaning you move at half speed), or you have some advantage that makes you sneaky by default (like Invisibility).  If you're loud, brightly lit, and stinky, then you don't get to roll.

For a one-sided contest, you roll the sneaky side's worst Stealth versus the other side's best applicable detection roll: Per (a good default if you have no specialized senses or detection skills), Vision (assuming you have a chance to see your opponents), Hearing (assuming you have a chance to hear them), Smell (I don't allow this for humans unless the opponents are extra stinky, but something like a guard dog with a really good sense of smell could use this to detect invisible and silent foes), Observation (if you've trained it up higher than your base senses), whatever the GM agrees makes sense.  If the sneaky side wins they get surprise, otherwise no surprise.

(Note that, for me, worst Stealth literally means the worst Stealth in the group.  I don't use the "part of the problem or part of the solution" rule to let a mostly sneaky group ignore a non-sneaky member, unless they actually take appropriate action like having a quiet person sneak ahead while leaving the loud person behind.  This means that every adventurer should have some points in Stealth, and every adventuring party should figure out how to get the least stealthy person in their group better at it.)

For a two-sided contest, it's a contest of each side's worst Per-based Stealth.  This is a clever way to combine both Perception and Stealth into a single quick contest.  Losing side gets surprised, and on a tie both sides are surprised.  (I don't think I've ever seen mutual surprise in several years of running DFRPG, but it'll happen someday.)

Once you're done computing surprise, you mark everyone who was surprised as Mentally Stunned, and then you do the usual turn order.  GURPS turn order is Basic Speed first, ties in Basic Speed broken by highest DX, and ties in both Basic Speed and DX broken by a die roll.  I also let players freely move down (later) in order, but once they do so, they can't move back up, as that could potentially be exploited to get two turns in a row.  (So, if your slower friend is in your way, you can either take a one-time Wait maneuver to Wait until your friend goes, or you can permanently move below your friend in turn order.  The advantage of the latter is that only some maneuvers are valid after a Wait, while if you just delay your spot in the turn order you can take any maneuver.)

The basic effect of Mental Stun is that you Do Nothing on your turn except roll to recover from Mental Stun, and all your defenses are at -4 as long as you're stunned.  So being surprised can get you killed.  The roll to recover is an IQ roll, with +6 for Combat Reflexes, so a rule of thumb is that dumb combatants need Combat Reflexes.  (Smart combatants might want it too, but they already spent all those points on IQ...)

With FoundryVTT keeping track, I'm happy to do individual initiative.  Groups of identical monsters will all be clumped together in turn order anyway, since they have the same Basic Speed and DX.  If a player controls multiple tokens and they're not clumped together and this bothers the player (because they prefer to move all their tokens together) or the GM (because the player loses focus when it's not their turn and this means getting their attention back more often), then a player can move all their tokens down in turn order next to their slowest token.  But this is definitely a place where house rules are fine -- if you want to do side-based initiative, you can.  You just have to decide whether the side with the fastest member goes first, or the side with the slowest member goes last.

I should also mention where new combatants slot in.  Basically, if you magically summon something in the middle of a fight, I don't let it do anything immediately on the turn it appears, but it slots into its normal spot in the turn order the next turn.  (Summoning sickness from Magic the Gathering in my GURPS?  It's more likely than you think.)  On the other hand, if something comes onto the battlemap from offscreen, it's probably in the middle of a Move maneuver in its first turn (though it could be Concentrate instead if teleportation is involved) and then can take any normal maneuver when its turn comes around again.

Finally, I do not modify turn order due to effects during a fight.  If someone casts Great Haste on you, you get two turns, but they're right next to each other, not spread evenly across the turn order.  (So as long as you know that nobody on the other side took a Wait maneuver, you can cheesily All-Out Attack on your first turn and then take a maneuver that allows a defense on your second turn.)  If you get slowed and only get to move every other turn, you stay in the same place in the turn order, just with a Do Nothing every other time.  If you drop your backpack or pick up a wounded companion and your encumbrance level changes, that effects your Move and Dodge, but you still stay in the same place in the turn order.  The only things that modify turn order are Wait maneuvers (where you temporarily delay your turn until triggered, take your action immediately, and go back to your usual spot in the order), and voluntarily moving down in turn order (which is usually a once-per-combat thing to move after an ally.)

As an aside, I like the DFRPG surprise rules better than the GURPS Basic Set surprise rules, because they make "no surprise" more likely, while in the Basic version, if surprise is possible at all, you only get "no surprise" if the modified d6 rolls are exactly tied.  (So, assuming reasonably close surprise modifiers, only about 1/6 of the time.)  On the other hand, I like that the Basic rules give a reason to have a leader (many PC parties clearly do not) and for the leader to have Combat Reflexes and Tactics and high IQ.  So maybe I'll write my own surprise rules someday that combine the things I like.  But I'm avoiding house rules in Arden Vul, so using my interpretation of the DFRPG rules as written.

My Megadungeon Conversion and Prep Sequence

So you've got a big megadungeon for D&D and you want to run it in GURPS.  The adventure only has GM maps available in black-and-white (or even old-school anti-1970s-photocopier blue-and-white), and you want player-friendly full-color detailed maps in your VTT.  How do you get there?

The first step is to read the whole adventure before making the final decision to run it.  You don't want to start running the first level of the adventure because it started well, without knowing that level seven isn't finished or sucks and then start changing everything at the last minute once you realize you're in a corner.  That way lies Game of Thrones Season 7.  Converting a good adventure is much easier than finishing an unfinished adventure or fully rewriting a bad adventure, so make sure you like the whole adventure (or at least 95% of it with a concrete plan for how to fix the last 5%) before you start running it.  It's well worth a bit of reading to avoid starting something you won't want to finish.

The next part is going back to the start and figuring out the basic challenges at the start of the adventure.  What is the entry point, or in the case of a megadungeon with multiple entrances, what are the most likely initial entry points?  How hard are the challenges there?  Are there any likely first-session TPKs?  If so are you okay with that, or do you want to insert some hard or soft barriers to prevent them, so you don't lose your players before they get invested?  Hard barriers would be something like an unpickable locked door between the PCs and the Totally Out of Depth Boss Monster, where the key is a couple of levels down guarded by a Less Unfair Boss Monster.  Soft barriers would be direct warnings or fuzzier rumors that a certain area is really dangerous; PCs can still go there and get killed if they want, but they can't are slightly less likely to blame the GM.

Once you know how hard the start of the adventure is, you can figure out about how many PCs you want and their rough starting power level.  You need to know this before you start recruiting players if you don't already have them; some spoiled power gamers will want to skip any game where they don't get to start as a demigod, while some old-school hardcore types will dismiss any game where their PCs start already knowing how to walk as too easy for them.  The point isn't to judge anyone's preferred style of play; it's to honestly communicate so that you get players who want to play the same kind of game you want to run, so everyone is more likely to have fun and stick around.  You also kind of need to know this before you start converting the first level of the adventure, so you know where to set challenges.  For example, if you have a D&D module where the adversaries on level 1 are mostly small groups of orcs with 1 hit die, designed to be a reasonable challenge for level 1 D&D PCs, then if you're starting with 125-point GURPS characters, maybe those goblins should have weapon skills in the range of 12, damage low enough that they're unlikely to down a well-armored warrior with a single hit but high enough that the squishy mage feels vulnerable, damage resistance somewhere around 2, maybe some sub-optimal weapon choices like unbalanced knobbed clubs and no shields instead of harder ones like broadsword and shield, and use mook rules so they go down or run away after one solid hit rather than fighting forever like horror movie boss monsters.

Then I think you want to fully convert enough of the dungeon for the first few sessions.  You don't need to convert a whole 15-level megadungeon before you start running it; if you or your players don't love it and you quit a month in, you don't want to have spent months of prep time.  But you want to be far enough ahead of your players that there's no significant chance of them hitting a totally unprepped area.  I think doing 2 or 3 levels is enough to start, depending on how big the levels are, how many accessible entrances there are, how long your play sessions are, and (if you know your players) how likely your players are to crash dive versus make sure the current level is pretty clear before going deeper.

What comes first, the maps or the room descriptions?  Up to you.  You already have both the maps and room descriptions from the original adventure, so you have a place to stand either way.  My advice would be to do one at a time though, as switching modes between editing maps and editing text has a cost.

My choice is to first look for nice VTT maps that other GMs have made available.  If you run a very popular old adventure like Keep on the Borderlands or Ravenloft, they will definitely be out there.  (But it will be harder to find players who aren't already familiar with the adventure.)  If you run something newer or more obscure, they may or may not be.  Also, it's common for GMs to start running a megadungeon and not finish it, so you'll find a lot more level 1 maps than level 15 maps.  Once you find or make map images, keep in mind that you might also need to make time for manually drawing line-of-sight-blocking walls, and adding dungeon dressing, and testing your maps with an NPC token to verify that they really can fit through the narrow passages and the secret doors aren't too obvious.

As far as converting the room descriptions, I see three major phases.  I don't need to convert plain text, as text is universal across game systems.  But I need to convert monsters, and treasure, and ability/skill checks.  I find the skill checks the easiest to convert, so I do those first.  Need to roll 4d6 under DEX to make this climb?  I'll call that a straight Climbing roll (which defaults to DX-5) in my GURPS conversion.  Lifting the lid off this sarcophagus needs a Bend Bars check?  I'll call that a ST-6 check and say there's enough room for up to 2 PCs to participate.  Maybe give a bonus if they use a lever or something.  I don't need to anticipate everything players might do, just give a starting point for the challenge level, so when they do something unexpected my level of needed in-game improv is something like "I'll call that a +3 bonus" rather than having to rethink the whole framework.

Monster conversions basically fall into two buckets: easy and hard.  The easy ones are the ones that someone has already converted.  If there's a common monster like a goblin, there are probably already 7 GURPS versions of it, so I pick one.  I check my piles of official GURPS books, Gaming Ballistic's Nordlond bestiary, the GURPS wiki, Enraged Eggplant's blog, do a web search for "GURPS monstername" in case someone else has it on their blog or it shows up in a forum post, etc.  I might tweak it a bit, then I'm done.  If it's a monster that I can't find an existing conversion for, because it's obscure or sometimes only found in this one adventure, I do it myself, and that's 30 minutes of my life gone.  (More if it's a really complicated monster.)

Treasure conversions also come in two kinds, easy and hard.  For really basic stuff like coins I make up a formula and stick to it.  First I read enough of the adventure to see how generous or stingy it is with treasure, then I make something up like 1 gold piece in the adventure means $1 or $5 or $0.1 or whatever in GURPS dollars, then I can translate the total value back into flavorful fantasy coins and gems.  One caveat here is that it's easier to add more treasure later than to take away treasure you have given, so err on the side of less generous to start and then become more generous if it becomes clear you need to.  Stuff like gems and jewelry is about as easy as coins.  The hard stuff is magic items.  Some of the simpler ones are formulaic, like you might say that a D&D +1 longsword becomes a fine, balanced GURPS broadsword.  But if you have to convert something like a Rod of Lordly Might that has like 7 different powers, it can be tedious.  Note that if something is too annoying, you can just substitute something else.  Your players won't know, and as long as the substitute item is something they like, they won't care.  D&D modules tend to be full of scrolls and spellbooks, which are important in a Vancian system, but not so much in a point-based mana point system, unless they contain secret spells that are otherwise hard to learn.

The other thing to think about is the starting town or towns.  Is town a safe zone or part of the adventure?  What goods and services are available there?  What is in ample supply, what requires an availability roll, and what requires a trip somewhere else?  It makes sense to detail town a bit before starting, as your players might want to take the location in mind before making their PCs.  ("The only temple in town is to Mitra?  What a great coincidence that my PC is a devout, consistently-tithing follower of Mitra!")  I don't think a mostly-safe town typically requires a lot of game mechanic conversions, though I personally convert things like "5% chance of a minor magic item appearing in the market" to "minor magic item appears in the market on 4-" just to use fewer kinds of dice and simplify my VTT macros.

My final conversion tip is the TODO note.  If there's something that's really annoying to convert and you just don't feel like it today, leave a TODO note in your conversion and move on to the next thing.  When you finish your first pass at converting the level, search for TODO and maybe go back and do any that seem important, and leave the others for later.  The point is that you don't have to do everything in order, but you do want to remind yourself if you skipped something so it doesn't surprise you in play.

Once you've got enough of the adventure converted to start playing it, you have to make the decision to actually start.  It's tempting to say "one more level to be safe", and if you enjoy prepping more than playing that's fine, but if you don't it could be painful to prep more than you end up using, so try to find that balance between fear of your players overtaking your prep and fear leaving prep unused.

Once you actually announce the game and start recruiting players, keep in mind that much of the time you previously spent prepping the dungeon will instead go to talking to prospective players, introducing new players to each other, helping players build their PCs, etc.  I find this stage the most difficult part of the process of running a campaign.  When you're just prepping you're just prepping and it's just you and nobody else cares so your decisions have no real impact (yet), and once you get into the swing of a campaign it gains its own momentum and if it's going well the players help you keep it going, but the first time you post in some Looking for Players forum looking for the right 5 players and not being sure if you'll get zero or 50 is a bit tough.

The first few weeks of a new campaign are pretty busy dealing with new players and new PCs and (maybe for some players) new rules, so you might not have much time for dungeon prep.  This is why it's important to prep ahead enough to give yourself some runway.  At some point things calm down: the PCs (or maybe just some of them) survive their first few delves, the players (or maybe just some of them) like the game enough to keep playing, the GM handles things well enough to keep running it, the new players get to know each other and start helping each other so the GM doesn't have to do everything, and you start a regular loop.  For me, running a weekly game, it looks like this:

• Friday: game night.  Send reminders ("Game tonight at 8, get me your updated character sheets by 7 if you want the updates in effect for this session"), do last-minute review of the part of the adventure they're most likely to visit, actually run the game.
• Saturday: Post-game writing.  Write a recap, sum up all the loot found, award XP.  See if any players have immediate responses like "we need to find a wizard we can pay to identify that sword" or "we're definitely going after the lizardmen next week" that can give clues on what to prep next, and add notes to the todo list.
• Sunday: Short-term prep.  Go back through the last session's log and mark dead monsters as dead and taken treasure as gone in your conversion notes; you remember well enough now that you don't think you need to, but you probably won't remember so well when your PCs come back to this level in 6 months.  Resolve any town stuff that can be resolved out-of-game.  Make any short-term changes in the areas of the dungeon affected by the PCs' recent actions.  (Do the ogres put new guards in the upper guard post to replace the ones that got ganked?  Do the oozes to the west take advantage of the portcullis the PCs left open to add themselves to the random encounter table for the east?  Do we need a couple of new rumors to replace some that got used?)  
• Monday: Announce the next session and ask the players who will be available for it, to see if you have a quorum and help you and your players plan ahead.  (Alice: "Bob's not going to be here Friday so we won't have Gronkar the Tanky, so maybe this week is a bad week to do a frontal assault on the gnolls."  Clarence: "Maybe we should consider a scouting mission on the swamp level instead."  GM: "I haven't looked at the swamp level in 6 months but I'll add that to the todo list.")  
• Tuesday-Thursday: Long-term prep.  Once I'm confident that whatever we probably need for this week's session is ready, I can go back to working on the unfinished level 3 levels below the deepest the PCs have been.  For a simpler dungeon you might just go top to bottom.  For a more complicated and less linear dungeon you might be thinking in terms of what unprepped area they're most likely to discover next, rather than just prepping in order.  (You won't always guess right, which is fine.  Make your best guess, and keep prepping something almost every week, and eventually you'll get to all of it.)

In theory, eventually you'll have the whole dungeon converted and prepped, and you can drop the long-term prep part of the weekly loop and only make little tweaks in response to your players' actions, until they finish the campaign.  Now you're on GM easy street, basically running an adventure on rails, like people who run adventures for the systems they were actually designed for without changing anything.  If that gets boring, you can always start converting another megadungeon...

What Happens if PCs Get Stuck in the Dungeon?

If you run an RPG only when all your players are available, and some of your players have lives outside your game and will have to sometimes miss a session, then eventually your campaign will die due to non-attendance.  (You play week 1, but then you skip week 2 because Alice has work, and you skip week 3 because Bob is sick, and you skip week 4 because it's Clarence's kid's birthday, and by the time week 5 rolls around everyone has forgotten about the game.)

So the obvious solution is to run your game even when only some of the players are available.  And the corollary is to end each session somewhere safe, where you can easily swap out PCs between sessions if necessary.  Then 80% attendance is no problem at all.

Unfortunately, in the eighth session of the Arden Vul campaign, the PCs got teleported somewhere that they didn't have an obvious safe way home from, and then kept looking for treasure right up to the time limit, which included lifting the lid off a sarcophagus with 3 minutes to go in the session.  Opening a sarcophagus at the very end of a session brings very real risks of a fight starting that they can't finish until the next session, and that's what happened.

So how do we deal with PCs ending the session in the dungeon?

First, this is where the correspondence between real time and game time breaks.  The players will return a week later, but for the PCs, no time has passed.  As far as the PCs are concerned, it's still Demmasday the Third of Legarios.  It's still their eighth delve into the Halls of Arden Vul.

Second, as long as the PCs are paused in the dungeon, no XP is awarded, and no previously awarded XP can be spent.  They have whatever loot they found, but they can't easily sell it yet.  They don't get a week of free healing, or a chance to roll Carousing or Research, or time to go shopping, or even an hour to cast healing spells and rest.

Third, there's no easy way to swap PCs in the dungeon.  The ones who are in the dungeon are the ones who will be in the dungeon until they get back to town.  So if a player can't make it next week, they'll have to pick else someone to run their PC.  (At least for the start of the session; if they make it to town partway through the session, they're free to swap PCs.)

Overall, I expect that after this happened once, the players will be a bit more aware that it can happen again, and might somewhat modify their tactics to avoid that outcome.  Then again, they really like loot and XP, and might press their luck again to avoid coming home empty-handed.  It's ultimately up to the players when to go back to town; it's up to the GM to design appropriate rewards for doing so and consequences for failing to do so.

All the Ways the PCs Know They Can Go in Arden Vul

One of the players posted a list of all the ways they could explore next on the campaign Discord.  Here's a shortened version:

• 2 caves behind the waterfall (beneath 35-40' of rough water)
• Ruined tower near the base of the waterfall (ghost)
• Secret entrance 2/3 of the way up the Long Stair, leading to the Great Cavern
• Ruins of the city of Arden Vul
• Northern island
• Multiple watch towers
• Square tower near Forum with bronze double doors
• Square tower (bees)
• Square tower and cistern (baboons)
• Down the Well of Light (baboons and giant 4-armed baboons)
• Pyramid of Thoth, move statue west 
• Halls of Thoth (halflings)
• Great Chasm
• Lever on top of triangular pyramid, teleporter to Well of Light
• Beastman territory
• Stairs down, behind secret door in baboon mosaic
• Chute down, opened by manipulating a statue
• Pyramid of Thoth, move statue east
• Black portal (demons)
• Selket statue, teleporter to Great Hall (beastmen)

At least so far, Arden Vul has a large branching factor.  The PCs choose where to explore, and then instead of having one less choice (as they would if they exhausted a dead end), they usually find a couple more choices.

This makes prepping the dungeon more difficult for the GM, because I can't always guess where players will go next, so I have to have a lot of areas prepared.  This is probably good though, because it gives me incentive to prep more each week, so I'll finish prepping the whole adventure sooner.

I think having a lot of choices is good for players, because if they get stuck in one place they can go somewhere else.  However, it does require players to have good memories, or take good notes, or buy Eidetic Memory, so they don't forget about all those loose ends.

Current Foundry VTT Configuration for GURPS

About a month into DFRPG Arden Vul, here is what we're using in Foundry VTT.

Core VTT software:

Foundry VTT version 12.

This is the latest stable version.  I try to avoid updating Foundry in the middle of a campaign, because even though Foundry core tends to be stable, it takes a while for modules to support the new version, so if 13 or 14 or 15 comes out and we're still playing Arden Vul, I'll stay on 12.

System:

GURPS 4e Game Aid (GGA)

This is what everyone uses to run GURPS on Foundry.  It's great.  DFRPG is GURPS for most purposes; there's no need for a separate Foundry system for DFRPG.

Modules:

About Face

Controls token facing, for games where facing matters.  Works great.  Sometimes the little arrows it projects into adjacent hexes to show facing get lost, though.  You can tweak the size and color of the arrow, but I'd really like one that automatically contrasted with the current background color.

Combat Booster: Turn Marker, Recent Actions and more

The "Turn Marker" module didn't get updated for v12, so I tried this one instead, and it does indeed mark the token whose turn it is.  I'm not using the other features.

Dice So Nice!

Animated pretty configurable dice.  This is probably the most popular Foundry module, so if you've used Foundry you probably know about it.

Hide GM Rolls

In base Foundry, if the GM makes a private roll, the game tells the players that the GM rolled dice, just not the exact roll.  This properly shuts that up, so I don't have to waste time making fake die rolls to keep my players guessing about when I'm actually making hidden Per or wandering monster checks.

Hurry Up! Combat Timer

Puts a timer on each token's turn in combat.  By default it's 5 minutes, which is forever, but at least it reminds everyone why combat is slow.  (Quit complaining about traffic if you are traffic.)  If things bog down I'll gradually reduce the time limit.

libWrapper

A dependency for other modules.  I don't use it directly.

Monk's Wall Enhancements

Adds support for one-way doors.  It doesn't do every kind of one-way doors though.  For example, you might want a realistic door that only opens from one side, but once it's open, you can pass through either way.  But if a one-way door is more restrictive than it should be, the GM can move tokens for players.

It also has other features, like if you drag an intersection point of two walls, it moves both walls, not just one.  But the one-way doors were why I added it.

Ownership Viewer

Puts player colors next to tokens, journal entries, etc. to show who has permissions.  Permission issues are annoying so making them easier to spot is good.

PopOut!

Lets you put a character sheet in a separate browser tab or window.  This is a huge quality-of-life improvement for some players.  (Less so for GMs because we need to juggle lots of sheets.)

Token Attacher

Lets you attach a wheelbarrow token to a PC token and then when the PC moves, the wheelbarrow also moves.  And then you can attach the halfling token to the wheelbarrow token and now the PC is pushing the halfling around the map.  You can do much more with it, like building complex prefabricated objects out of lots of tokens, but that's the basic idea.

Tokenizer

This is an easy way to attach portraits and token pictures to tokens, and reuse one image for both.  The UI isn't amazing, but once you figure it out, it's pretty quick.

Universal Battlemap Importer

Lets you import a .dungeondraft file as a scene with the walls and lights intact.  Manually walling a complex scene is a lot of tedious work, so if a map was built in Dungeondraft and the wall data is already there, better to use it.  (But most of the maps I'm using are plain image files so I'm mostly stuck manually adding walls.)

Z Scatter

If you put multiple tokens in the same hex, it offsets them a little so you can see and click on them rather than playing the "which token is my token hiding under?" game.  This is great and should be the default.

Automated Seek Earth

As mentioned in a recent post, the Seek Earth spell is great for treasure-hunting wizards but can be hard on the GM, especially in a megadungeon with hundreds or thousands of locations.  "Which of these 117 rooms with gold is the closest, and what's the direction and distance to it?" is a hard question to answer in real time.  And you really don't want to bog down play while you dig through the adventure trying to guess.

But this is the kind of thing computers are good at.  I have complete maps of the dungeon, and I have a room key.  So in theory I should be able to automatically look at the room key to find all the rooms with gold, then compute the distance from the current room to each of them, and return the direction and distance to the closest.  So I decided to automate this.

I figured the coding would be pretty easy and the data entry would be a pain.  I was half right.  It turned out that tagging which rooms had which metals, which I thought would be annoying, was actually pretty quick.  Finding the global (x,y,z) coordinates of each room, which I thought would be pretty quick, was actually annoying.  Once those were done, though, finding the closest room with the target metal was easy.

The first bit of annoying data entry was condensing a list of about 1000 full room descriptions to a text file of one line per room: the global room label, then a colon, then a comma-separated list of metals.  A sample line:

4-6: silver, copper

This is saying that room "4-6" (level 4, room 6) contains silver and copper.  Pretty straightforward.  Also entirely manual; one could in theory do some intelligent parsing of the PDF, but I think that process would be tricky and error prone, because of overloaded terms, like "g.p." in OSRIC sometimes meaning a literal gold piece coin, and sometimes being a unit of account like "a 500 g.p. diamond."

The manual data gathering was not exactly fun, but I had already dug through the adventure and converted treasure from OSRIC to GURPS (which is easy for stuff like coins and gems where I just made up a mechanical formula, sometimes not so easy for magic items), so it was really just looking at my existing room conversions, finding the rooms with treasure, and copying just the types to another file.

The next part was creating a file of global room label to (x, y, z) coordinates.  I picked a spot at ground level northwest of the dungeon as my (0, 0, 0) basis point, and then the x coordinate of a room was yards east of the basis, the y coordinate was yards south of the basis, and the z coordinate was yards above the basis.  (The basis point was chosen so that x and y were always positive and z was always negative.)

I thought I would be able to automate this with OCR (optical character recognition).  People have been telling me for 30 years that OCR is a solved problem now.  Unfortunately, people are often wrong, and OCR is still a pain.  I tried several different OCR tools, handing them images of individual dungeon level maps from the adventure PDF and asking to get all the room labels back, along with their (x,y) pixel coordinates in the map image.  I got some of the room labels back, with the correct locations.  I also got some partial room labels back, like "4" instead of "41".  And a bunch were missing.  After a couple of hours I concluded the off-the-shelf OCR software wouldn't cut it.  It was entirely possible that I could train my own custom AI model to do OCR specifically on dungeon maps and I could get it good enough to work, but that would require generating a bunch of correct training data, which reduced to the original problem I was trying to solve.

However, I had another source of room data that didn't need general purpose OCR: the room labels on my Foundry VTT maps.  For convenience I put labels (visible to the GM only) in or near every room on the Foundry maps, so I don't have to flip back to the original PDF maps to see which room the PCs are in.  Foundry has an API that lets you see all the "drawings" on in a scene, with their X and Y coordinates and any text.  So in theory you could write a short macro in JavaScript to find all the labels, then filter to only the ones that started with a digit (which were more likely to be room numbers).  I didn't know the Foundry API, so I didn't know if this would be a 10-minute task or a few hours of ripping my hair out.  It turned out it was actually easy enough that I got an LLM to write the script for me in a couple of minutes.  AI is oversold and overhyped (see: OCR in previous paragraph), but when it works it saves time.  Now I could paste the script into Foundry, paste it to a function key, and hit that key on any map to spit out a tab with text containing a line like this for every room:

Basement: 8: 3460,2671

Here the map title is "Basement", the text of the label (the room number within the level) is "8", and the x,y pixel coordinates of the label within this image are 3460,2671.  Initially I just had the last 3 fields, but I found that putting the map names in there as well let me easily combine all the output into a single file, rather than needing one file per map and manually ensuring that the filenames were the correct map names.

One annoyance here is that some of the levels in Arden Vul are big and (for performance reasons) need to be split up into multiple maps in Foundry.  Let's say a level is 4 maps (NE, NW, SE, SW).  Now I need to have x and y offsets per map to specify the global x,y coordinates of the top left corner of the map.  I also need a z offset per map to specify its global z coordinate (I made this fixed per map rather than varying by room, which is wrong but probably close enough.)  Finally not all maps are at the same scale, so I also needed a pixels per yard scale value for each map.  (I went with separate x and y scales just in case, though I think for sane maps you could get away with one scale for both.)  I ended up shoving all this data into a single file I called map_xyz.txt, which was full of numbers that were kind of painful to compute, but it was only one line per Foundry map so not a ton of work.  A sample looks like:

#map,x0,y0,z,x_scale,y_scale

Arden_Vul_Ruins,0,0,0,0.0638,0.110

I also needed a mapping between my Foundry map names (designed to be player-visible) and the level abbreviations used in the adventure's map key.  For example:

Arden_Vul_Ruins: AV

(This is a simple case of a 1:1 mapping, but the hypothetical large level I mentioned earlier that needed 4 Foundry maps would have 4 different Foundry map titles all mapping to the same adventure level abbreviation.)

Finally, with all the data files completed, the actual code to parse them and spit out the closest gold was mostly a matter of coordinate conversion (x,y in pixels within a single map to x,y,z in yards in the game world).  Once everything was in nice coordinates, you can use high school trigonometry to find the distance between any two points (square root of the sum of the squares of the differences between the x, y, and z coordinates).  A couple thousand rooms is huge for a megadungeon, but it's tiny for a computer, so no real cleverness is needed in the algorithm: just find the distance from the caster's current room to every other room in the dungeon that has the material they're searching for, sort the distances in ascending order, and return the first one.  (I actually return the first several, in case the caster has marked the first hit or three as already known and to be ignored.)  The spell is supposed to tell the caster the distance and direction, so I return the distance along with the delta_x, delta_y, delta_z, and room name.  Then the GM can lookup the room name in the adventure and confirm it's a good hit, then fuzzify the distance and direction numbers as much as they want, and tell the player the results in game terms.

A sample run and output line is:

./seekearth.py -t treasures.txt -p map_prefix.txt -x map_xyz.txt -r rooms.txt -f silver -s 3-2 -n 1

distance  x_dir  y_dir  z_dir room

      29    -28      4      0 3-17

This is saying that the wizard in room 3-2 is casting Seek Earth for silver, and the program should only return the nearest hit.  The program said there is silver 29 yards away, x_dir -28 (so 28 yards west), y_dir 4 (4 yards south), z_dir 0 (same elevation), in room 3-17.  As a GM I'd fuzz this to "you sense some silver about 30 yards to the west."

This is definitely programmer-friendly UI not enduser-friendly UI, but as I'm the only user right now, it's fine.  I don't have any plans to turn this into a scratch-and-sniff turnkey Foundry macro, as the GM still needs to check the PC's spell roll, apply correct distance modifiers, lie about the results on a critical failure, possibly provide better results on a critical success than a regular success, etc.  My philosophy is to only automate things that benefit from automation and go back to doing something more important, not try to create a perfect jewel of software.  As a result this whole project took a couple of hours.  (Trying and rejecting OCR solutions was actually the part that took the most time.)

Anyway, the code is up on my GitHub.  The Arden Vul data files are not, but I'll post them eventually, along with the rest of my conversion notes, after I'm done running the megadungeon.

Dealing with Information Spells in a Megadungeon

Vael, one of the PC wizards in DFRPG: Arden Vul, started with the Seek Earth spell.  For 3 mana, Seek Earth lets you find the direction and approximate distance to the nearest significant amount of any one type of earth, metal, or stone.  It also lets you exclude known quantities of the item.  It uses the Long-Distance Modifiers, which mean no range penalty for up to 200 yards away, up to half a mile at -1, and distances beyond that hardly matter in a dungeon.  Its only prerequisite is Magery 0 or Druidic Power Investiture 1, so essentially every mage, druid, elf, or half-elf can have Seek Earth for one character point.  And every skilled specialist wizard (IQ + Magery 18 or better) gets it at skill 16 or higher for one point, so they cast it for only 2 mana, and it succeeds 98% of the time (16- on 3d6) if the correct mineral is within 200 yards.  If you're rolling against 16, 17 is just a normal failure, costing you one mana point and letting you try again.  Only an 18 is a critical failure, letting the GM lie to you about the presence or location of the item (or possibly summon a demon or whatever other fun comes up on the critical spell failure table), so only once in 216 times does casting this spell really have a chance to hurt.

This is tremendously useful for loot-hunting PCs.  You Seek Earth for gold or silver, exclude whatever your group is holding and any source you previously detected and don't currently want to mess with (example: hoard of a dragon big enough to swallow you whole), and then your GM fumbles through the adventure trying to find the next closest source.  You then make a beeline for the treasure.  If it's unguarded, free gold.  If it's guarded by mooks, you get to beat them up and take their lunch money.  If it's guarded by something scary, you have a warning so at least it's less likely to surprise you, so perhaps you see it and leave, or maybe you design a good tactical plan and apply all your buffs before you alpha strike it.

So from a player point of view, Seek Earth is yes.  But from a GM point of view, it's potentially a huge pain, especially in a large dungeon where you might have to go through a lot of rooms looking for the appropriate treasure.  How do you deal with this?

First, even though the spell says "nearest", players probably won't hold you to that.  If there's some gold 40 yards to the north, and you miss that room when scanning your map and room descriptions and instead send them to a room 70 yards east, will they notice?  Probably not; if they already knew where the gold was they wouldn't need the spell.  Will they be mad if they realize weeks later there was some closer gold and you missed it?  Probably not; it still gave them a bearing on some nearby gold.  So as long as you're not deliberately hosing your players, best effort is fine.  So if you're not prepared for this spell, I think it's totally reasonable to just look at the map, eyeball the nearby rooms in approximate order of how close they are, and then check each room description for the metal in question.  Stop at the first reasonable hit rather than spending ten minutes trying to be certain you didn't miss one.

Second, it says "significant" but doesn't define it, so you can set your own threshold and ignore anything below that if you want.  (I mean, you're the GM, you can always do whatever you want, but here you absolutely need to because the rules as written are fuzzy.)  Feel free to ignore monster pocket change and focus on bigger piles if that's more fun.  Conversely, if you don't want to have your PCs zoom past every other monster straight to the big boss's loot at the end, feel free to have it pick up the 17 closer treasures first, even if they're small.  You have options.

Third, NPCs, at least smart ones, know that spells, especially common spells, exist.  Common spells should not be automatic win buttons.  If the PCs aren't the only wizards in the game, then smart powerful rich NPCs might put their best stuff in lead-lined rooms, or orichalcum chests, or no-mana zones, whatever it takes in your setting.  It's not fair to have every single gold piece in the game hidden like that and make the spell useless, and it's kind of silly to have a chest worth way more than the treasure inside it, but the players should not be able to assume that there are never countermeasures available.

For the specific case of Arden Vul, now that I know a PC wizard is going to cast Shape Earth for gold and silver a lot (and he mentioned diamonds were another possibility, and that he might take Seek Magic soon), I'm planning to make a supplemental dungeon key with just room numbers and treasure.  Here are the rooms with gold, silver, diamonds, and magic.  If I wanted to get fancy I could make a file with the (X, Y, Z) coordinates of each room (maybe automatically extracted from the coordinates of the hidden room labels I put on the Foundry maps), and then write a little program to find the distance from a room to every other room, sort ascending, then spit out the label of the first room with the appropriate treasure (for me), and the direction and distance to it (for the player).  The code is easy; most of the work is data entry.

Is that work really necessary?  No, you can guesstimate.  If most of the time they're searching for something that's fairly common in a dungeon, you can probably just check a few nearby rooms until you find some, then stop.  And if they search for something rare, you can search the adventure PDF and find all instances of the thing they're seeking and then give them the closest.  I think it's worth automating in my case because I know this PC (and probably any other future wizards or druids in the game, if this one gets eaten) is going to cast Seek spells ten times per session and this campaign could run for years, so I'd rather do some work up front during downtime to save time during play, but it's totally up to each GM how they handle things like this.

My final tip is for players: if you want to play a PC with a power that's hard for the GM to adjudicate, give them a heads-up ahead of time.  Maybe they'll ban your favorite toy, but better to find out sooner than later.  Or maybe they'll lean into it and help you make it work, but they can do a better job of preparing for it if they know it's coming.  Treasure detection is a pretty straightforward (if data intensive) case to handle.  Divination is much worse, so warn the GM before playing a diviner, and don't get mad if they only let you tell the future once per session rather than every five minutes.  Seek MacGuffin can short-circuit a whole adventure, if the point of the adventure is finding one MacGuffin, so discuss it first.  (In some cases the GM will be thrilled you can do it, because that saves them a lot of time spraying around clues for you to maybe figure out.  In others, they might need to improve their adventure so that it's still fun even if you've made the finding part trivial.)

Things I Want to Do Differently This Time Around

I've been running RPGs for decades, so I have Habits and Tendencies and Opinions.  To some extent GMs attract and keep players who like the games they run, so there is some consensus in long-running groups, but it might not be complete.  So I think it's important for GMs to both get feedback from players, and to analyze their games and think about what they can improve.

This is particularly important for DFRPG Arden Vul because it contains several players from the DF Whiterock campaign, that I stopped running after 2+ years and one of the players later picked up and finished.  Since I know that one lasted a long time but eventually fell apart, how do I avoid quitting or losing players this time around?

My first goal for improvement is to keep rules consistent throughout the campaign.  I made two rule changes in DFW that players didn't like.  I thought both made sense at the time, but I was wrong on at least one of them, and not clear enough for the reasons on either.

One was limiting players to 3 attacks per turn no matter what was on their sheet, for a combination of game balance and speed of play.  It's not fun when one player's turn takes too long, but that's better handled with an explicit turn time limit rather than indirectly with an attack limit.  And it's not fun when the PCs get too powerful and wipe out enemies too easily, but that's fixable by adding more or better enemies.  So for Arden Vul I'm removing the attack limit, but might impose a time limit if combat length becomes a big problem, or some players' turns take too long.  (But not at the start, because we don't know if we actually have a problem yet, and also because some players are new to GURPS or Foundry and deserve a grace period to learn before being forced to play faster.)

The other was slowing down the rate at which character points were awarded.  I never promised any particular number of XP, but players got used to me lazily handing everyone 4 points per 4-hour session, regardless of accomplishments, with maybe some bonus points on top if they did something special.  When I saw that PC power was growing a bit faster than I wanted, I first stopped handing out bonus points, which nobody complained about because they were pretty rare anyway.  Then I slowed the regular reward from 4 to 3 for PCs over a certain point level, which caused minor grumbling.  When I slowed it from 3 to 2 at a higher point level, it caused a revolt.  Even if I never promised anyone 4 XP per session, it became expected, and changing the behavior from the expected caused problems.  Relevant xkcd.

So this time around I'm going to make it clear that PCs get 0 to 2 XP per session for loot (with 1 being pretty easy to achieve and 2 being hard, and the required threshold going up over time with PC point level, but the exact table of loot thresholds not (yet?) public), 0 to 2 for exploration (again 1 being pretty easy and 2 being harder, but the exact amount of exploration required not (yet?) public), and then again the possibility of bonus points for achievements (which I'd like to make more common this time, but small).  So with more variability in reward and more explanation for how the awards are given, I'm hoping that if players want more XP, they try to make their PCs achieve more per session, rather than whining about the GM.  I'm envisioning players figuring out the thresholds to get 1 loot XP and 1 exploration XP every session and always aiming to hit those, then going for either big loot or big exploration for a third XP (with loot being easier if you know where some loot is and think you can beat whatever might be guarding it, and exploration being easier if you know where some unexplored territory is), and then looking for things that might get them bonus XP.

My second goal is to actually finish the megadungeon.  That's a tough one because it's huge, but I think it's achievable if players are oriented toward accomplishing large goals (rather than enjoying killing wandering monsters and searching for every last copper piece), though I suspect there will be some turnover of PCs and possibly players along the way.  Ultimately it's up to the players what they do, though; the GM provides challenges and incentives and hooks but the players act.

My third goal is to play fair in both directions.  Players deserve consistent rules and rulings and to be allowed to use all the fun ideas they have and the cool stuff on their character sheets, but NPCs deserve a chance to win too, and if one of them rolls a massive critical hit against a PC who's out of Luck and Bless, no mercy.  I'm going to set the scene and then let the dice decide.  My one grudging concession to real life on that one is that I sometimes skip wandering monster rolls near the end of a session, if that would force pausing a probably-meaningless fight across sessions and deny PCs access to town, because of an arbitrary real-world time limit.  What I should do in that case, now that I think of it, is make the roll anyway but hit them with the wandering monster early next session instead of late this session, satisfying both the players' need to stop at the agreed time and the wandering monster's need to get a fair shot at eating a delicious PC.

My fourth goal is to have an entertaining GURPS recap blog with a few hundred loyal readers, which requires good source material (Arden Vul is awesome), the players doing fun stuff (I'm sure they will), and consistency.  Because this will be a voice game, I won't have complete logs to refresh my memory, so I'll try to write the recaps every Saturday morning before I forget too much.

My fifth and final goal is to listen to my players better.  A GM can't do everything players ask for because a lot of what they ask for is "let us win more" and if you always do that the game becomes a cakewalk and actually becomes less fun for most players.  But you can bend their requests in a way that gives them some of what they want while preserving some game balance.  For example, one request I got from a couple of players last time was "if a PC dies my next PC should get all the points my old PC had," which would remove all penalty for death (except the time to make a new PC) and takes a lot of tension out of the game.  But starting new PCs all the way back at 125 points might be too harsh the other way, if it causes players to play too cautiously.  So I've announced I'm going to award new PCs a fraction of their players' previous dead characters' earned XP, with the exact fraction not (yet?) public.  If this rule actually gets exercised multiple times then I need to be consistent, so the players will eventually figure out the formula, but I don't need to tell them yet.  Another one is "yes, but".  I need to be open to more weird player ideas unless they're actually a threat to the game, rather than just a challenge to my expectations.  One player wanted to play a rotating stable of hirelings rather than one consistent PC, so I'm letting him do that.  Another player wanted a weird backstory that didn't really fit the setting, but that's fine, Irthuin is a big continent, he's from a remote spot on the map that isn't detailed in the setting, and if any details about that spot become important I'll ask him.

Finally, no plan survives contact with the enemy.  Any plan for a perfect campaign goes out the window as soon as you add the chaos of actual players, and GMs need to forgive themselves and their players for mistakes made in good faith and just try to keep things going and keep them fun as best they can.  The main GM response to most setbacks should be "Noted, we'll fix that next time, next game scheduled for next week."

First game Friday night, half of the PCs done and the other half mostly done, I've got this huge megadungeon about 1/3 prepped and I'm pretty sure they won't be able to reach the other 2/3 in the first session, let's go.

Roll20 vs. FoundryVTT for GURPS

After using Roll20 for the 2-year DF Whiterock campaign, and using Foundry to run J.C. Connors' Hogwarts oneshot for two groups, I think I've got enough data to decide which to use for my next campaign.  To avoid burying the lede, I'll tell you that I prefer Foundry.

From the player's point of view, both VTTs are web-based, so if you have a computer and a supported web browser, you can play.  This is great compared to VTTs that require that every player install client software on their computer, because not all players are computer experts.

One difference is maturity.  Roll20 has been around for several years and is pretty entrenched as a popular VTT.  Foundry just hit the one-year anniversary of its release, so it's not brand new anymore, but it's not as mature.  In particular, right now we're in the middle of a transition between the 0.7.x and 0.8.x versions of Foundry, where the newer versions have more cool features but not all modules have been ported to the new versions yet.  So, basically, if you're already using Roll20 and you're happy with it, switching will cause you work.  Both products have marketplaces where you can buy things like tokens, but Roll20's is more mature and has more stuff.  Roll20 has a larger community of players who know it.

Another difference is the cost and payment model.  Roll20 is "freemium": it's free for basic use, but you have to pay for some features, like dynamic lighting and API access and more storage space.  If you pay, it's a subscription model (about $5/month for "Plus" and $10/month for "Pro", with a 15% discount if you pay for a whole year at once), so you'll have to keep paying periodically if you keep using it.  Foundry isn't free at all: you have to pay $50 for a license.  But once you have it, it's yours forever and you don't have to keep paying.  So which is cheaper is going to depend on what features you need and how long you want to use it.  If you're happy with the free version of Roll20, or can't afford a Foundry license, then free is good.  On the other hand, if you need any of the features that require paying in Roll20, and use it for more than a few months, Foundry's one-time cost is going to be cheaper than a Roll20 subscription.  Note that both VTTs are free for players: if the GM pays the cost, then any players hosted in the GM's games don't have to pay again.

Roll20 is Software As A Service: your games are hosted on Roll20's servers.  This has both advantages (there's less computer stuff for the GM to set up) and disadvantages (if their servers are busy hosting too many other games, your performance will suffer).  Foundry, on the other hand, is downloadable.  The GM has options: they can run it on their own computer, or they can go rent a server somewhere in the cloud and run it there, or they can use a service called Forge that's specifically aimed at hosting Foundry.

The ability to run your own server is nice, as you have complete control, but it also means you need to manage some things for yourself, which perhaps requires more computer skills than some GMs have, or takes time that the GM would rather spend elsewhere.  I chose to run Foundry on my Linux desktop, behind a home router, for minimal setup.  I had to setup port forwarding on my router for my players to be able to connect from outside my network.  And then I chose to setup a DNS name so I could tell my players "connect to hostname:port" instead of "connect to IP address:port".  I also had to setup accounts and passwords on my Foundry instance for all my players, a minor annoyance.  (Warning: Foundry's passwords are currently not stored in a cryptographically secure manner, so you want to be extra careful not to share them with anything else.  I recommend that the GM pick long random passwords for every player and put them in a password manager, then the players put their own password in their own password managers.)  For me, the big advantage of self-hosting is that, because I already automatically backup my desktop every night, I get nightly backups of my Foundry game.  If I mess something up, I can revert to a previous backup.  This gives great confidence to try things, knowing that no matter how horribly I mess things up, I can only lose one day's work.  So if I ever decide to move my Foundry instance off my desktop to a dedicated server somewhere, I'll make sure to do daily backups of that server too.

Another difference is the wealth of add-on modules available.  (Here, I use "module" to mean "code library" not "RPG adventure".)  Roll20 has been around for a long time, so it has developed support for a lot of game systems, but the JavaScript API support (which requires a Pro subscription to use) is somewhat limited.  Foundry has, in my opinion, a much better API, so there are already a ton of modules available, some of which do pretty impressive things.  General advice is start with the basics and not go crazy installing dozens of modules at first.  When I ran DF Whiterock in Roll20, I used one module to improve combat order tracking, and it was great.  For the Hogwarts adventure I ran in Foundry, I used a few modules: Dice So Nice for pretty animated dice, Actually Private Rolls so players can't see when the GM makes private rolls (as knowing that they rolled, even if you don't see the result, leaks information), PDFoundry for integrated access to my GURPS PDFs from inside Foundry, with hotlinking from the character sheets to rules references, and Turn Marker to put a marker under the active token in combat.  Plus Nose and Nick's unofficial GURPS system, which includes character sheets, importing characters from GCS or GCA, clickable skills and attributes on sheets, and a bunch of other stuff.  When I used Roll20, there were several GURPS character sheets available but I didn't feel like any of them were amazing, so we didn't really use them heavily, mostly using paper or PDF character sheets instead.  (One player did use a Roll20 sheet.)

The time setting up the VTT can be dwarfed by the time setting up an adventure, though.  It really comes down to how much the GM wants to show on screen.  If you want to run a game mostly "theater of the mind" and not use maps or virtual character sheets, then you don't really need a VTT at all: any chat client with a dice rolling plugin will do.  If you do want maps, then the amount of prep time required is directly proportional to how many maps you want and how pretty you want to make them.  I don't have any artistic ability, so I scrounge the Internet for maps and tokens, using free ones if available, or buying battle maps or token packs I like from artists.  If you can't make your own maps and tokens, it ends up being a lot easier to run a fantasy game than other genres, because so many of the maps and tokens out there are aimed at that genre.  DF Whiterock was based on the published Castle Whiterock adventure, which came with black and white maps, so I ended up digitally ripping the maps out of the PDF adventure with the pdfimages tool, then using the GIMP image editor to trace the maps to create background images, then pulling the background images into Roll20 to make base maps, then doing my dungeon dressing by finding tokens for furniture, rubble, doors, etc. and placing them on top of the background maps, and then manually adding lines to show where walls blocked line of sight.  This was a lot of work.

Doing maps in Foundry is pretty similar to doing them in Roll20.  You create a "scene" which is just like a Roll20 map, then you pick a background image, then you can add "tiles" which are background images that sit on top of the map (like furniture) and "tokens" which represent actors (like PCs, NPCs, or monsters).  And then you paint walls for your map to block line of sight, and add light sources.  One advantage that Foundry has over Roll20 is that doors are specifically supported.  In Roll20 I spent a lot of prep time placing door tokens with line of sight blockers under them, and then a lot of game time manually swinging the door token to the side and removing the line of sight blocker when a player opened the door.  In Foundry, when you're placing walls you can designate part of the wall as a door (or a secret door, or a window, or a one-way door) and then players can interact with it: click to open or close.  (Unless it's locked, in which case trying to open it makes a noise, and the players know their PCs need to unlock the door in-game, at which point the GM can click it to unlock it, and then the players can interact with it as a normal door.)  The killer feature I'd really like is auto-walling, where the computer interprets the art and figures out where to put line-of-sight-blocking walls and doors.  I believe that's doable for simple maps and really hard for complex maps.  Of course, if you buy your maps from an artist that fully supports your VTT, they can create the walls for you.

Doing tokens in Foundry is also pretty similar to doing tokens in Roll20.  Foundry does a few things better.  For one, tokens come with a facing arrow, so if you play a game where facing matters and use tokens whose facing is not obvious, you don't have to manually add facing indicators to your token art.  For another, Foundry has the distinction between "prototype tokens" and "tokens".  Basically, the prototype token is the mold from which all tokens for a particular actor are forged, while the token is one instance of a token on-screen.  For a singleton character like a PC or a named important NPC, this is a distinction without a difference, so you can click a checkbox to say "link actor data" and establish a 1:1 correspondence between the token and the actor, so that for example if you remove some hit points from the token in scene 1, those hit points will still be lost for the token for the same actor in scene 2.  But for an actor like "generic spear-orc" where you might have 50 different instances of the token across different maps, you can drag as many of the token as you like onto the screen, and each will have independent stats based on the prototype.  Wounding one does not harm the others.  In both VTTs, tokens can have vision and lighting.

"Fog of War" is another feature of most VTTs.  The players can only see roughly what their PC should be able to see.  Roll20 supports a basic version of Fog of War by default, where the GM manually uncovers parts of the map.  Then it supports Dynamic Lighting as a Pro feature, where the GM spends a lot of time adding line of sight blockers, and players can see what their token can see, based on lighting and vision and line of sight.  Foundry inverts this: dynamic lighting is the default, but there is a module available that supports manually cleared Fog of War for GMs who prefer that.  There are also options for whether previously uncovered parts of the map should remain uncovered simulating the PCs remembering what was there, or should go dark again, forcing the players to remember (or map!)

One complaint I had about Roll20 is that it wasn't great for large maps: if you made the map too many pixels, you got warning popups about performance, and used up more of your limited storage quota on their server, and your players with slower computers might notice decreased performance.  This disappointed me because when I wanted a huge map for the Immense Cavern level, I had to break it up into multiple maps, which was more work for me and less seamless for the players as we needed to do manual map moves whenever their tokens crossed a map boundary.  It also meant that long-range battles didn't happen much.  Unfortunately, the Hogwarts adventure didn't feature any huge maps (the biggest one I made was about 100 yards by 55 yards and worked great), so I haven't actually stress-tested Foundry there.  (I mean to do so at some point in the future; feel free to remind me if I forget.)

In Summary:

• Roll20 is cheaper if you only need the free stuff.  Foundry is cheaper if you want advanced stuff.
• Roll20 is more mature.  So it has more players, more art packs, more D&D adventures, etc.
• Foundry is more flexible in terms of hosting.  Roll20 is simpler because there's only one way.
• Foundry supports doors.
• Foundry has better APIs for add-on modules, and thus more cool and useful modules.
• Foundry has better GURPS character sheets.
• I like Foundry better and plan to keep using it for future games.

Frontstabbing: A House Ruling

In GURPS and DFRPG, if you start your turn in the target's rear hex, it doesn't get a defense against your attacks.  (Unless it has Peripheral Vision or something similar.)  This makes backstabbing pretty good without any special abilities, just the ability to get behind your opponent.

However, if you're highly skilled with an impaling weapon, but not very strong, like Zaber in DF Whiterock, backstabbing isn't ideal, because most opponents have armor on their back.  You'd really rather stab them in the eyes, which often gets you DR 0 and a free brain hit (for quadruple damage and a good chance at a knockout).  However, if you can reach their eyes then they can see you coming, so they get a defense.  (Quite likely at -2 for a side attack, but any defense is way better than no defense.)

Unless you're invisible.  If you're invisible, and they don't have See Invisible, and they don't hear you coming or smell you, then frontstabbing should work about as well as backstabbing.

So my house rule on frontstabbing was basically: if you're invisible and approach an enemy from the front, it's a contest of your Stealth vs. their Hearing.  If you win, they didn't hear you coming, and they will have no defense against your invisible attack.  In DFRPG, Invisibility goes away after one attack, so only the first attack will get this benefit, but one good eye shot is often enough.

The other possibility is smell.  For simplicity I don't give most opponents smell rolls, unless they have an exceptional sense of smell (like many canines), or the frontstabber is particularly stinky.  (See, a reason for PCs not to dig through latrines for treasure!)  The No-Smell spell comes in handy if you want to sneak up on scent hounds; Zaber actually used it to pickpocket a sleeping ettin guarded by a dire warg of his magic ring.

What went right in DF Whiterock

It's bittersweet that the DF Whiterock campaign ended before the PCs quite reached the bottom of the dungeon, but we kept the game going for over two years, so most things went mostly right.  Peter asked for a post about things that went well in the comments, so here goes:

Converting a D&D 3.5 megadungeon to DFRPG (with a few other GURPS things thrown in) was work, but mostly went pretty smoothly.  GUPRS is a very flexible system that can emulate most other games.  Probably the hardest part was converting enemy spellcasters, because there are so many differences in the magic systems.  The easiest part was converting DCs to GURPS skill penalties and monetary treasure in gold pieces to GURPS $; I did both of those purely mechanically.  And thanks to all the people who put conversions of D&D monsters to GURPS on the Internet.

The house rules for building a DFRPG character with 125 points and no templates worked pretty well.  Players seemed to have fun making characters, and the first few sessions were pretty challenging.

The rules for improving characters, where points spent on skills could be traded back when attributes based on those skills were raised, were pretty popular.  (It seems that anytime you let players do more than the official rules allow, they're happy.  So this was not surprising.)  Not limiting characters to templates provided a different challenge than most GUPRS Dungeon Fantasy or DFRPG games.

Five players played in a majority of the sessions, and four played in a vast majority.  I had only played with one of the players before, so this showed that it is possible to assemble a reasonably cohesive group from random people on the Internet.  Of course it's not quite as easy to do it this way as to use a group of people who already get along: we had a few players who dropped out due to intra-party conflict or because it just wasn't the right campaign for them.

Making "Sense of Duty: Adventuring Companions" not count against the disadvantage limit had the intended result that everyone took it, and then the intended result that PCs who didn't get along kept it at the level of verbal sniping (and occasional Levitation), rather than violence.

Having a dedicated Discord for the campaign seemed to keep everyone in the loop.  We mostly knew if we were playing on Friday and who was showing up, and everyone mostly had their characters ready to go.

Roll20 mostly worked okay.  The fact that it's web-based is nice because people can play with their phone or tablet when away from a real computer.  On the other hand, it doesn't work nearly as well with a phone or tablet as with a real PC.  And it doesn't support large maps very well, so some of the larger levels ended up being many maps rather than one map, which was annoying.

We got a surprising amount of roleplaying for a dungeon crawl.  The PCs made both allies and enemies.  (Of course the allies tended to survive longer than the enemies.)  And they each had enough of a personality that when a player was out and someone else ran their character, we got fairly accurate mockeries.

The game featured a lot of combat, and the players got pretty good at combat tactics against various enemies.  Outflanking enemies to hit them in the back happened a lot, especially once everyone had Flight all the time.  Sacrificial Parry was used a ton.  And the players were constantly trying to balance Deceptive Attack, Rapid Strike, and hit location penalties.  There were also a lot of stunning attacks, via Rapier Wit, the Stun or Death Vision spells, or Kiai.

This player group had more of a hive mind than most I've seen: everyone shared their character sheets with each other and gave each other advice on how to improve their characters, and the group mostly functioned as a collective with respect to equipment.  This was pretty effective.

The Premature End of DF Whiterock

The Bad News

I ended the DF Whiterock campaign today, after over 2 years and 100 sessions, but before the dungeon was finished.  (The Thane was the end of level 12 out of 15, so they were about 80% done.  Though they had skipped level 5, the underwater level.)

I'm disappointed we didn't finish, but I wasn't having fun anymore, and running this game was way too much work to continue doing if it wasn't fun for the GM.  I know some of the players weren't super-happy with the way it was going either.

What went wrong?  Ultimately I think a mismatch between player and GM expectations.  From my point of view, the players wanted continual increases in power, and complained about not getting enough points or treasure.  Meanwhile I was trying to keep the adventures challenging for the increasingly untouchable PCs.  Giving them more power was the last thing I wanted to do, as I thought they had too much already.

Also, in the game world, the PCs had defeated the Thane of Narborg, who appeared to be the ultimate boss behind the orc and human slavers who had dragged them into this adventure in the first place.  The fact that the red dragon Benthosruthsa was probably allied with the duergar was not clear enough to them.  I had Chauntessa clue them in a bit more last week, but they still didn't have enough motivation to do her dirty work.

Things I'd do differently if I ran this again

1. Award character points for accomplishments rather than play time, to give the players a reason to go faster.  And award fewer points overall from the start.  (If you set a low baseline rate of improvement and give bonuses for significant achievements, players are happy.  If you set a high baseline then slow it, players whine.)

2. Make the dungeon a bit smaller.  As written, it's the surface level with human slavers, then two orc levels, two trog levels, the underwater level (which our group skipped except for one brief encounter with the hydrohydra), the underground river level, the Immense Cavern, three duergar levels, the Demonhold, two levels of Burning Maze, then the final level with the dragon boss.  I think it could be reduced from 15 levels to 9 by removing an orc level, a trog level, the underwater level, two duergar levels, and the Demonhold.

3. Figure out voice or text ahead of time.  It appears that most players have a very strong preference for one or the other, so voting each session isn't a great idea.  (We stopped voting after text won about 20 times in a row, but at least one player was never happy that the game was text.)

4. Write up more ahead of time to make sure all the players are on the same page.  One player quit early because this was too much story, not enough mindless hack-and-slash for his vision of DFRPG.  I guess you can never do enough Session Zero.

5. I probably wouldn't use Roll20.  Making dungeon maps in Roll20 is too painful, because there's no support for doors, and you have to do line of sight blocking manually by drawing all your walls again on another layer.  If I had to start a new game today, I'd probably choose MapTool because it's the most mature cross-platform VTT available, even though its scripting language is gross.  FoundryVTT looks great, though it's really new and doesn't support enough game systems yet.  And the future not-Windows-only version of Fantasy Grounds might also be a contender.  Of course, the grass is always greener on the other side.  I know everything I hate about Roll20 after using it for two years.  I'm sure the others have warts too; I just haven't found them yet.

6. Give more blatant clues on what the PCs should be doing next, rather than expecting them to figure it out.  Player agency is great, but when there's only one dungeon prepared, the PCs always need a good reason to go into it.

7. Writing long detailed recaps for every session was a lot of work.  I think I'd try to farm that out to the players.

Random observations

1. If you remove mandatory templates from Dungeon Fantasy / DFRPG, the PCs will be more powerful.  You need to account for that when handing out points.

2. Wizards get drastically more powerful as their spell skills reach 20 (which is achievable with a stock 250-point wizard) and 25.  In particular, Flight-25 is "all the PCs fly all the time."

3. Bless is broken.  Luck is really good.  Having one of them is pretty good: it means fewer dead PCs.  Having both is probably too much.

4. Great Haste is broken.  I ended up limiting attacks per turn to 3 to curb the worst abuses of it, but just eliminating the spell would probably work better.

5. Mass Daze is often End Fight.

6. Everything in DFRPG is aimed at 250-point characters.  Balancing 125-point or 500-point characters is an exercise for the GM.  Getting it right is tricky.

7. In this particular adventure, wandering monsters had very little effect.  The PCs usually felt overpowered enough that nothing on the wandering monster table would be much of a threat, so wandering monsters were mostly a waste of time.  This probably contributed to a lack of urgency, as the players found no cost to slowly moving around looking for every secret.

8. Different players like different things.  I think (borrowing the terminology from Robin's Laws of Good Gamemastering which I think all GMs should read) our group was one Roleplayer, one Tactician, one Butt Kicker, and two Power Gamers.  (They might disagree with those assessments though.)

The Future

A couple of people want my Castle Whiterock GURPS conversion notes, so I'll throw those up on Github at some point and post here when I do.

I have a couple of GURPS oneshots I'm thinking of running for a group of friends and maybe at a (virtual?) convention: the Star Trek and Harry Potter adventures from 1shotadventures.com .  (So if you think you might want to play in those, don't read them.)

I'd also like to run The Traveller Adventure (for Classic Traveller, from 1983) in GURPS.  That's another campaign-length adventure, like Castle Whiterock, but it's 156 pages, versus about 800, so hopefully it wouldn't take as long to run.  It's kind of the polar opposite of Whiterock though: SF vs. fantasy, trading vs. combat, a subsector versus one town and one dungeon.

House Rules about PC Names

Here are some completely meta, non-power-affecting, house rules about player character names that I'm thinking about for future RPG campaigns I run.

One hard rule is going to be "no accent marks."  I don't measure the exact amount of time I spend writing game recaps, but I suspect it's about 1/3 actual writing, 1/3 reviewing Roll20 logs for details I can't remember well enough to keep one of my players from pointing out an error later, and 1/3 putting the accent mark in Seépravir's name.  So future names in games I run will be rendered with only plain ASCII characters.  (Now, it's entirely possible that in the original Elvish or Dwarven or Chinese or Vilani or Klingon or whatever language the character's name comes from, the character's preferred spelling has accent marks or runes or emoji or heiroglyphics or non-Latin letters or space holograms.  And that's totally fine.  I'm just saying that when I render it into English for use at the mostly-English-speaking gaming table, I will stick to ASCII so I can type it faster.)

The corollary is that if your character has a long name, we will end up abbreviating it and using the short version most of the time.  So players should put some thought into the short version of their name, that their companions will actually use most of the time.  Maybe that's their full legal name; maybe it's just their nickname.  They can write a longer version on their character sheet if they want.  (Sometimes there's just no time to say "Look out, Helgevottir Hirgebottom, rocks are falling.")  Note that this has real world parallels in groups like the military and hockey teams: it's just more convenient to have a short nickname when you need to yell orders or warnings quickly.

The final rule is "only one PC with the same first initial at the same time."  Just because being able to refer to people with one letter is convenient.  (For example, when maintaining a text box of active spells, being able to type "Flight: Z, P, G" is awesome.)  Obviously this limits games to 26 characters at a time.  Which is also a good rule.  (I prefer 4 or 5, but 27 is right out.)

Character Point Rewards Versus Speed of Play

The intent of DF Whiterock was a "zero-to-hero" campaign, in the tradition of old D&D, where you start at first level and progress until you become super-powerful heroes (or, more likely, a total party kill).  This contrasts with the Dungeon Fantasy rules, where you start at 250 points, which is already pretty badass.

To achieve the "first-level" feeling, I made the initial group of PCs start at only 150 points, rather than 250.  I originally planned on 125 points, half the Dungeon Fantasy level, but I thought the Dungeon Fantasy disadvantage limit of -50 points was too much and would result in PCs with more disads than players would actually remember to play, so I changed 125 + -50 to 150 + -25.  Adding in 5 more points for quirks and 5 more for "Sense of Duty: Adventuring Companions" not counting against the limit (because I didn't want intra-party violence), PCs started with 185 positive points.  This achieved the goal of making them weaker than usual Dungeon Fantasy starting characters, but I don't know if it quite got the "first level" feeling right.  In particular, these PCs weren't nearly as brittle as first level D&D characters.  (Though, GURPS characters take longer to make than D&D characters, especially if you're not using templates, so maybe that was the right call.)

The other half of zero-to-hero is rapid advancement.  I knew I wanted to give out more points than usual.  I also knew I didn't want to spend a lot of time figuring out how many, or cause inter-player drama by giving some PCs more points than others.  So I decided to go with a flat 5 points per character per session to start, with occasional bonuses for significant achievements.  (I deliberately didn't make this a fixed announced rule though, because I thought I might need to change it later.)  To encourage participation, points only go to PCs whose players are actually running them: if you're not there and your PC is played by another player or the GM, no points for you!

Early in the campaign, I gave a few bonus points for accomplishing significant things, but then I felt that PC advancement was going a bit too fast, so I stopped doing that.  Also, bonuses that only happen in some sessions mean that players who miss those sessions feel bad.  Eventually I cut rewards from 5 per session to 4, then (at 400 character points) 3, then (at 450 character points) 2.  Not really sure exactly what I will do in the future.

We've only had one PC death so far.  New PCs have joined the campaign at a point level higher than the original 150 points (because such low-powered characters would be badly outmatched by the current dungeon level), but lower than the lowest existing PC (because it feels unfair to let a new PC cut in line).

What happens when players figure out they get the same number of points whatever they do, and that death has consequences?  Well, I guess it depends on the players.  For my group of players, they explore very slowly and carefully, take few risks, and try to find every bit of treasure.  Is this fun?  Sure.  Does it makes the game take longer?  Absolutely.

So, what kind of things could I do next time to encourage faster or braver play?

• Give fewer points for participation, more for accomplishments.
• Have more clear time limits.  If you don't do X by Y, you can never do X because Z.
• Make points transferable to a new PC, so PC death matters less.

I'm not completely unhappy with how advancement has gone, so I don't really see the need for extreme changes in this campaign.  If I were to run Castle Whiterock again for a new group, I think I might go with even fewer points to start, and change starting rewards from a flat 5 points/session to something like 2 points/session for participation, with lots more rewards for doing things.  Figuring out all those exact bonuses is more work than just handing out flat points per session though.  Everything is a tradeoff.

Individualism vs. Communism in RPG Parties

When we played AD&D as kids, the party mostly worked as a team.  Except at the end of the adventure, when we divided up the magic items.  At that point we rolled dice to determine the order of picks, and then each player would usually take the best available item, not necessarily the best item for their character to use, or for the party's overall effectiveness.  It could get merciless sometimes.  "Yes, I'm a fighter, and yes, I can wear armor, so no, I don't really need the Bracers of Defense AC 4, and yes, your mage really could use them, but, you see, they're worth a lot of money.  Do you have an equal item to trade?  I guess I need to keep them then."  Level training was expensive in AD&D, so there was always a need for large stacks of gold pieces.

That was before GURPS, and before Gordon Gecko in Wall Street, but most of us played like we had the Greed disadvantage.  Maybe that's the way most American boys were in the 1980s, or maybe it was just us.

Many years later, the current group of 5 PCs in the Castle Whiterock campaign amuses me, because they want to play almost exactly the opposite way.  Almost all found items remain "party property", unless they are easily divisible (like cash or items that everyone agrees are useless that should be sold and turned into cash).  Occasionally someone asks if they can buy an item that only they want from the party, but most of the time, they just ask to use it, while not needing to take ownership.  PCs freely loan money to each other to help them afford major purchases.  To put it bluntly, they're a Communist Party.  They're trying to win the game as a group, and don't really care too much about whose character gets what treasure.  (The one exception is that the PC who bought Wealth, and thus sells all the party's treasure at a much better price to everyone's benefit, gets a bigger cut to compensate him for spending all those points.)

So, as a GM, is this okay, or is this something I should try to stop?

For the most part, as a GM I think inter-PC relations are up to the players.  They can do what they want, as long as one player isn't completely ruining another player's fun and thereby threatening the existence of the game.  The big exception is that if a player gets points for a disadvantage or quirk, they need to earn them by playing it.

One obvious DFRPG disadvantage related to money is Greed.  If a PC takes Greed, they should pretty much wreck the idea of a Communist Party unless it clearly works in their personal financial favor all of the time.  "All for one and one for all", not so much.  "What's mine is mine and what's yours is ours," sure.  Maybe this could work if there was one Greedy PC and the rest just let them keep an unfair share of the treasure because they don't care.  Dwarves in DFRPG have Greedy by default, so if you want to have a Communist Party, you might not want any short bearded folks ruining it.

Another one is Wealth.  The GURPS 4E rules say "The GM should not allow wealthy PCs to bankroll their poorer associates.  This makes below-average Wealth little more than 'free points.'  The
GM might allow rich characters to hire poor ones."  Basically, if anyone collects disadvantage points for below-average Wealth, they can't be propped up by a collective in a way that makes that not matter.  ("A Disadvantage that is not a disadvantage is not a Disadvantage.")  So if you want to make a Communist Party, probably everyone should have at least Average Wealth.  Or, if someone insists on playing a Poor PC, they should be reduced to the status of mere hirelings, to earn those disadvantage points another way.

The other one is Miserliness.  A miser might be okay with pooling the treasure, as long as they get to be in charge of making sure nobody spends any more of it than necessary.  A Communist Party needs a quartermaster (someone has to track all that party-owned stuff), so if there's a miser, they probably need to take that job.  If some other party member has a spending-related disadvantage (Compulsive Spending, Compulsive Carousing, Compulsive Gambling, the need to eat an expensive diet of health food to maintain Chi abilities, etc.) then there's going to be conflict.  But maybe it could work if enough cash is paid out to each PC to more than handle their own basic upkeep, and only the remainder is kept in common.

The other problem with party-owned items is what happens when the party composition changes.  If a PC leaves the game, it seems reasonable that they would want to take their fair share of the party's stash with them.  (If a PC dies and can't be resurrected, they probably have heirs who'd want their share.)  Conversely, if a new PC joins, the existing group is certainly free to share their resources, but if any of them object, the system might fall apart.

It might be interesting, though possibly out of pseudo-historical genre conventions, for an adventuring party to be a formally incorporated business entity with actual legal rights, shares, a board of directors, etc.  That would be a way to get the advantages of a Communist Party (the PCs pool their resources to try to win, and only the players who enjoy accounting have to worry about accounting) while putting a capitalist face on the system.  ("We're totally going to liquidate this and all be rich someday, just not yet.  We're still in startup growth mode, you see.  Plowing all the profits back into the business.  Dividends are for later, after we run out of dragons to kill and rob.")

There's more than one way to have fun playing an RPG.  Perhaps individual versus group ownership of items should be part of your next Session Zero.