Aug 17, 2015

Posted by in Game Development | 0 Comments

The Almighty Credit

Despite wanting Project Universe to be a space trading sim, I’ve spent very little time working on the economics of the project simply because of math. Economics is something that people go to college for; my training is limited to one high school class, and the only thing I remember is learning how to write a check.

I’m not going to enumerate my struggles in this area because every time an attempt failed, my psyche immediately blocked it from memory in what I assume is a self defense mechanism I never knew I had. But I think this time I might have a system based on actual supply and demand concepts, although not at a level that would survive pedantic scrutiny (this is a game about flying stuff through space, so reality isn’t a cemented concept here).

The Humble Commodity

This pricing really only affects commodity items, which are basically “junk” that players will buy and sell for profit. They are things like luxury items, food, and minerals.

Commodities move around the game via the player or on their own. NPC trucking is a process that runs globally to simulate NPC merchant activity. Every period X a routine will run that redistributes quantities throughout the entire universe. There’s little logical science involved in this miraculous teleportation of goods, because most of it will be unseen by the player except in very specific, occasional snapshots when he docks and enters a commodity shop. But the spice must flow, and so must commodities in order to make it seem that the player isn’t the only one shuttling goods back and forth.

A commodity has a base price which will be predicated on the item’s class. There’s going to be a lot of fudging here as I try and put a sticker on the base “value” of wheat compared to the base “value” of rare vintage wine. The actual base price is merely a starting point; a proxy for how common the item is, or in more economic terms, how difficult it is to create (sourcing materials, time to create, and all that stuff).

Demand

Items are in demand at the class level. Everyone needs food, so commodity items in the food class will always be in high demand. Some items are needed, but not universally, such as weapons or medicine — there’s always wars and diseases to fight, even in the future. Other items are purely for luxury, such as jewelry or caviar. The demand for luxuries will generally be low.

The system will take the demand and use it with the base price of the item to get a baseline price for one unit (individual or tonne) via the formula:

(BASE $ * (BASE$ * (%DEMAND/100)))

I call this W$, which is short for working price. It’s where we start from.

Supply

All of my previous attempts to get a mobile price target to show to the player has been focused strictly on how to change the price based on the quantity of items in the shop at the time. That was dumb, or at least was an incomplete understanding of how this system needed to work.

The quantity itself is impossible to work with unless there’s a standardized baseline to compare it against so we can determine if we need to charge more (quantity changes in a negative direction as players buy) or charge less (quantity changes in a positive direction as players sell). The goal is to see the price per item rise as the item is bought, indicating an increasing scarcity, and to see the price per item fall as the item is sold, indicating an increasing glut. Other attempts to model this were lacking the baseline, which I now have in the form of the calculated W$.

Now, I have to track the last change in quantity, whether it’s by player or NPC, in order to set the price per item using this convoluted formula:

(W$ * (QTY – (Tx QTY/QTY))) + W$

You can see this in action in this Google Docs Spreadsheet.

When the player enters the commodity shop, he’ll see a price based on the quantity on hand that exists in the shop at that time and the change in quantity between now and the previous quantity. Say, for example, that there were 500 units of a relatively luxurious item in that shop before the NPC automation ran. After the NPC automation, there were 450 units of that luxury item. The cost of production is pretty high so the base price is set at 60 credits/unit (it’d probably be higher than that, but for sake of example…). Because it’s a luxury item, it’s not terribly in demand (10%) just because the percent of people in the sector who can afford it is significantly lower than those who cannot.

When the player arrives at this point, he’ll see that there are 450 units of the luxury item in the shop. He won’t know that previously there were 500 units, and he’s looking at a price that’s calculated based on the notion that this high-priced luxury item just sold 50 units, decreasing the supply while the demand stays the same. This scarcity changed the price from whatever it was before the NPC process ran to a calculated value of 396 credits per unit. If the player can only afford to buy 50 units of that 450 on hand, he’ll pay the 396 credit price, but as soon as he hits the CHECKOUT button, the price per unit will jump to 400 credits per unit.

Wildcards: Events

There can’t simply by a static set of parameters, although I guess if I wanted to make it a relatively simplistic system I could leave it where it sits now. But I like the idea that the universe is getting on along without the help or hindrance of the player, which forces the player to adapt to the situation for better or for worse.

Events (ideally) are game- or sector-wide actions that cause a change in factors which determine the price of an item in the market. It’s a separate system from pricing, although (on paper) events will impart modifications on different aspects of the game, several of which can affect pricing. For example, a plague in a specific sector will increase the demand of items in the medicine class, raising the price of those items wherever this event is in effect. If the player can source items in that class in a sector which isn’t feeling the effects of the event, then he can make a princely sum. On the flip-side, a process which makes items easier to manufacture might drop the per-item base price so that the price of a specific item or class is depressed despite the demand remaining the same.

Design and Testing

I haven’t yet made it past the spreadsheet phase, but there’s going to need to be some support work done before I can get to integrating this into my testing framework. I have to add the concept of “previous quantity” into the object that tracks an item in a shop inventory, and then create the methods that calculate the item price at that station. Events don’t factor into the equation at this point, as I haven’t even gotten to thinking about them in depth.

Leave a Reply

What do you think?