Designing a Boffer LARP (Part 21)
+Klaus Teufel mentioned that I might be over-thinking things with regard to this game economy. I'll admit it, this is something I'm commonly prone to doing.
There is a goal in this game of keeping things easy and approachable for new players, and basically it does look like my economic structure is needlessly complicated...but bear with me for a moment as I explain my thought process.
I figure that an easy user experience can come from two directions. The first easy user experience comes from something simple, the mechanisms providing the experience are plain, basic, they simply do what they do, independent of one another...you only need to worry about one thing at a time. The second easy user experience is harder to pull off from a back end perspective, it comes from complex components working in harmony, with numerous systems synchronising seamlessly...but the user only needs to deal with one part of the system to interact with the whole.
The first user experience can easily come from a minimalist rule set, a lot of GM fiat, and a hefty dose of hand-waving to ignore the complicated bits. Personally I think that goes against more of the tenets of game design that I originally set for myself. It does keep things simple for the players, but requires a lot more work from the GMs, it also opens them up to accusations of favouritism if they're forced to make decisions without a good rule structure to back them up.
The second user experience has a lot of back end work to set up, but I'm aiming toward a database or spreadsheet that could allow players to submit their "turns" each month, and then when the next game hits, they can see the results of their between-game actions.
"I spend my next month cutting wood"
"I spend 50% of my next month smelting ore into metal, then 50% making metal horseshoes and farm implements."
"I need someone to spend the next month watching my stills, because I need to leave town, and the rum stills can explode if they aren't watched"
Suddenly we start getting people needing people, and a community develops.
I think that the game systems need to directly interface with the players in a logical way, anything that simply complicates things is an unwanted deviation, but if it pulls things into line in another way then it might be worth exploring.
As stated previously, this part of the game is generally handled by NPCs, but allows player characters to slot into the ecosystem at any point. Every action by a player character makes a contribution to the ecosystem and disrupts the equilibrium in some way. Too many people chopping wood, then the value of that work decreases. Too many people smelting ore, then ore becomes a scarce commodity and it goes up in price, All of these aspects are handled by a simple database where standardised orders handle the daily activities of the mundane NPCs, and custom orders can be entered by players at the end of each game session, then press the button and the output is generated (in the form of little information sheets noting relevant information that might be pertinent to each character's perspective in the grand scheme).
What I'm working through here is the back end of things, then I'll get stuck into the user interface.
So yes, I'm basically plunging ahead with this complexity. I just thought I'd take the chance to explain why I'm doing this and how it should fit together in the end game.
There is a goal in this game of keeping things easy and approachable for new players, and basically it does look like my economic structure is needlessly complicated...but bear with me for a moment as I explain my thought process.
I figure that an easy user experience can come from two directions. The first easy user experience comes from something simple, the mechanisms providing the experience are plain, basic, they simply do what they do, independent of one another...you only need to worry about one thing at a time. The second easy user experience is harder to pull off from a back end perspective, it comes from complex components working in harmony, with numerous systems synchronising seamlessly...but the user only needs to deal with one part of the system to interact with the whole.
The first user experience can easily come from a minimalist rule set, a lot of GM fiat, and a hefty dose of hand-waving to ignore the complicated bits. Personally I think that goes against more of the tenets of game design that I originally set for myself. It does keep things simple for the players, but requires a lot more work from the GMs, it also opens them up to accusations of favouritism if they're forced to make decisions without a good rule structure to back them up.
The second user experience has a lot of back end work to set up, but I'm aiming toward a database or spreadsheet that could allow players to submit their "turns" each month, and then when the next game hits, they can see the results of their between-game actions.
"I spend my next month cutting wood"
"I spend 50% of my next month smelting ore into metal, then 50% making metal horseshoes and farm implements."
"I need someone to spend the next month watching my stills, because I need to leave town, and the rum stills can explode if they aren't watched"
Suddenly we start getting people needing people, and a community develops.
I think that the game systems need to directly interface with the players in a logical way, anything that simply complicates things is an unwanted deviation, but if it pulls things into line in another way then it might be worth exploring.
As stated previously, this part of the game is generally handled by NPCs, but allows player characters to slot into the ecosystem at any point. Every action by a player character makes a contribution to the ecosystem and disrupts the equilibrium in some way. Too many people chopping wood, then the value of that work decreases. Too many people smelting ore, then ore becomes a scarce commodity and it goes up in price, All of these aspects are handled by a simple database where standardised orders handle the daily activities of the mundane NPCs, and custom orders can be entered by players at the end of each game session, then press the button and the output is generated (in the form of little information sheets noting relevant information that might be pertinent to each character's perspective in the grand scheme).
What I'm working through here is the back end of things, then I'll get stuck into the user interface.
So yes, I'm basically plunging ahead with this complexity. I just thought I'd take the chance to explain why I'm doing this and how it should fit together in the end game.
.png)
Comments