I have several campaigns' worth of experience GMing for a fairly rules-light d20 system called Roleplaying is Magic, and I'm taking my group in a different direction for the next campaign: a superhero spinoff. Whatever changes I needed to make to the core rules are done, and balanced based on collaboration with other GMs, but I want to introduce a simplistic crafting and upgrade system which we've not really covered before:

  • the players have a home base that they start at before a session, and have equipment and other gear within the base that provides stat buffs
  • the players have the chance to collect a resource (let's call it Scrap) during a session
  • in-between sessions, players can delegate NPC members of the team to expend Scrap to build equipment upgrades that resolve between sessions
  • however, at any one time, multiple upgrades will be available and the players will have to decide amongst themselves which upgrade would be the most beneficial based on how much Scrap is available, the item's value to the team, how long it will take to resolve the item build time etc

For an example:

The team's deployment jet fighter currently has room for improvement.
Our scientist NPC can build a Nitrous Injector to improve its speed and evasion.

Costs: ## scrap | Speed increase: ## | Time to resolve: # weeks

The problem is, I'm not sure how to go about valuing this Scrap resource so that it is

(a) clear to players that it is a finite resource and does not appear in abundance to pay for all purchases by the endgame,
(b) provokes thoughtful discussion between the players of which purchases would be most beneficial to the team in the long run, and
(c) is balanced based on how much scrap would realistically be needed to complete the item.

My initial thought is to give items extra attributes which are known only to the GM like 'Complexity', 'Size' and 'Value', each with a level of 1–5, then assigning each of those levels a Scrap number like so:

Level    Scrap Cost
1        5
2        10

So that when it comes to calculating how much Scrap would be needed for an item, you simply add the level numbers together:

The team's deployment jet fighter currently has room for improvement.
Our scientist NPC can build a Nitrous Injector to improve its speed and evasion.

  Costs: 35 scrap | Speed increase: ## | Time to resolve: # weeks
  Complexity: 3   | Size: 2   | Value: 2   | Scrap cost: 35 scrap

However, short of slowly and painstakingly determining these values for every possible item and upgrade in the game, which is a horrifically large task considering the freedom of upgrades I want to make available in the future, I'm not sure how to go about it.

Is there a simple or similarly formulaic solution you would suggest for this scenario, or am I just going to have to knuckle down and work it out manually?

  • 3
    \$\begingroup\$ With the exception of doing it all by hand, have you considered using an excel spreadsheet to input your solutions? \$\endgroup\$
    – user22635
    Apr 29, 2015 at 16:15
  • \$\begingroup\$ What does 1 unit of scrap buy? How often will 1 unit of scrap be available to PCs? \$\endgroup\$ Apr 29, 2015 at 16:40
  • \$\begingroup\$ @JonathonGarza I think that would be the most appropriate way of doing it 'by hand'. Lord knows I don't have the patience or the penmanship to legibly write it all on paper. And the formulas for addition and so on would be timesaving in themselves. \$\endgroup\$ Apr 29, 2015 at 19:35
  • \$\begingroup\$ @HeyICanChan I think scrap would be akin to some chunks of scrap metal; I don't have a set economy in place for it yet, but the most likely use for a single unit of scrap would be to create a box of ammunition for a rifle or crossbow. As I say, scrap would become available within missions, (so, left lying around in the environment in a session). I would likely inform the players if they could plainly see it in a room. \$\endgroup\$ Apr 29, 2015 at 19:38

1 Answer 1


You're actually pretty much all the way there. The Complexity/Size/Value system you mention would probably work pretty well, and making a mapping between a particular total value and the scrap is a good way to go about it.

You ask if there is a way to forumlaically determine how much scrap you should give out, or how much scrap things should cost, and the simple answer to that is no. What you're doing here is basically the core of mechanical game design; figuring out what to reward players, and how much those rewards should be worth. The only real way of figuring out that kind of information is to playtest and iterate.

Broadly speaking, you should have an idea of how much scrap you expect to give out per session, and how much scrap an upgrade will cost. For example, maybe you expect to give out about 10 scrap per session, with higher amounts as the players get more powerful. This could mean that your players do a series of lightning raids over three sessions, finding 7, 5, and 18 scrap respectively. It could be that they find a huge box worth 50 scrap at the end of a 5-session adventure. Maybe they could find 5 scrap in the open, and have a chance of finding 10 more if they search carefully. The important thing is to have at least a first-order approximation of how much scrap your players will have at a given time.

Similarly, you should keep in mind how much scrap an upgrade should cost, to help you tune your cost table. For example, maybe a minor benefit that only applies sometimes costs 5 scrap, a huge benefit that applies all the time costs 100, and everything else is in between. The important thing to keep in mind is roughly how much scrap you want your players to spend to get a cool new ability.


(a) clear to players that it is a finite resource and does not appear in abundance to pay for all purchases by the endgame,

There are three things that you need to do to make this work. First, tell your players outright that scrap is rare and difficult to come by. Make sure that they are aware, out of game, that scrap isn't something that will be trivially acquired, and that their in-game characters know this. Second, make sure there isn't a simple or easy way to generate scrap, and that you have tight control over the amount of scrap going into the economy. If players can make new scrap by say, blowing up enemy fighter jets, then you will introduce complex new incentives and possible exploits that can backfire spectacularly. Third, make sure that you create enough ways to spend scrap that players never have enough to buy everything. If you give out 100 scrap in a mission, then the players should have 200 scrap worth of useful options available to them afterwards.

(b) provokes thoughtful discussion between the players of which purchases would be most beneficial to the team in the long run, and

This is pretty much on you. The thing that makes players the most interested in discussion is when several options are all attractive, but they have to pick one. To achieve goal B, you're going to have to come up with cool things for the players to buy. The cost of options isn't going to significantly affect how much they consider each option, unless specific options cost exorbitant amounts. One tip here would be to make sure that each option is clear on what its effect would be. For example, for the Nitrous Injector, make sure the players know exactly how much more speed and evasion they're getting if they buy it.

(c) is balanced based on how much scrap would realistically be needed to complete the item.

Honestly, this is something you can mostly ignore in practice. One way to get by this is to say that what you call 'scrap' is actually filled with high-value phlebotonium, which is what makes it so valuable. The Nitrous Injector isn't hard to make because you don't have the steel and nitrous oxide to make the object, it's hard to make because you can enhance the parts with phlebotonium from your scrap, which is what makes them more efficient.

It's going to be very very difficult to have scrap be a fungible resource for making cool stuff and have it coorespond to a specific amount of mass without causing problems when you tune the system down the line.


Make sure to get player buy-in before following the advice in this section.

Designing the numbers for a system like this is not easy, and things can get out of hand unless you fix the system as you go. Remember that most games that you see (either tabletop RPGs or video games) have gone through a pretty intense testing process before they are released, and making a complicated system like this without giving yourself the ability to change things if it doesn't work is setting yourself up to fail.

First, come up with some numbers that look like they work. Then, save those numbers someplace and don't look at them for at least a few days, preferably a week. When you come back, look at them again, and see if they still make sense. If they don't, adjust them and repeat. The reason to do this is that it's sometimes very difficult to see a design error as you're making it, and it's often obvious in hindsight. Letting yourself sleep on it and clear your mind lets you bring a more fresh perspective to your designs, and helps avoid errors.

Once you have numbers that you're happy with (or you run out of time), show them to your players. You don't need to be specific about this, and you probably shouldn't show them the acquisition rates in any case. If you tell players "you'll get about 10 per session" and they go 3 sessions without any, they might feel like you're depriving them of their rightful loot, whether or not they are justified. The main thing you want to show them is what kind of stuff they can get for what cost. See what they think about your cost structure. If they feel like there are a bunch of different interesting options at various price points, hurray! You've got a decent pricing scheme. If they feel like some options are super awesome, or super weak, take another look at your numbers and the power of the options you're offering. They may or may not be correct about how powerful things are, but it's important to at least consider their opinions.

Once you have a set of numbers that both you and your players are happy with, bring them into play. See how they actually work in the game. The most important thing to remember here is that you need to be ready to change the tuning of either acquisition rates or costs if it turns out that you screwed up somewhere. There is absolutely nothing better for testing your design ideas than actually seeing them in play, and it's important to be flexible and willing to change once you see how it plays out. If the players end up with too much scrap, either raise costs or lower the acquisition rates. If they have too little, then either lower costs or raise acquisition. Keep doing the 'write down numbers, wait a bit, look at them again' process if you have enough time, it really helps weed out problems that are hard to see in the moment and obvious in hindsight.

Hopefully that's helpful. These guidelines are applicable to most game economies, and I think that they'll work well for yours.

  • \$\begingroup\$ I'll give it another day or two to see what other people have to say (if any), but that was clean, concise, and very helpful. You've done me a great service with your answer. Thanks. :) \$\endgroup\$ Apr 30, 2015 at 0:56
  • \$\begingroup\$ Sorry! I have been distracted with many a thing in the last month and a half. Your answer was very helpful in organising the base layer of my economy and I'm very thankful. :) \$\endgroup\$ Jun 11, 2015 at 14:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .