Now that each station has it’s own set of commodities to sell and players can dock at stations, it’s time to get into the reeds and work with the buying and selling of goods.

The first step is to create the ability to actually own commodities. For this, I reworked the concept behind what the player is. Because this game is basically a “control panel” and the player doesn’t really have a presence outside of the windows on the screen, the concept of a “character” is really just a set of data points that we need to track. While the character’s ship is something that can be upgraded, it’s essentially a bunch of numbers that determine how many jumps you can make, how much damage you have and how much you can take, and which components you have purchased.

As a result, a cargo inventory has been associated with the character record, not the ship record. The main reason is that a player may opt to sell his current ship chassis for a “better” one (“better” has yet to be determined), and that would screw up inventory association with a ship. Because components can be upgraded as well, associating inventory with a cargo bay component means swapping associative values when an upgrade happens. By putting inventory at the character level, the inventory will always be with the character, leaving the capacity calculation dependent on whichever component we have slotted.

For that calculation, then, we need to work with adding and removing quantity to and from the cargo inventory. When a player buys or sells commodities, we’ll pass a positive (buy) or negative (sell) quantity to an action method that uses the positive or negative value as a determining factor in whether we’re adding/incrementing or removing/decrementing inventory.

When adding, we first have to figure out if we have the capacity. To do this, we check the currently slotted cargo bay component’s Capacity value against the count of inventory items. If we have room, we’re all set. If not, and if we do not yet have the commodity in cargo, we can’t complete the transaction. This is a failsafe check; we’ll never allow players to even initiate a transaction if they can’t fit it, or if they can’t afford it. If we do have the item, then we increment the quantity by the amount purchased. Right now, I don’t have a plan to limit quantity of an existing inventory commodity except by a hard ceiling of, say, 9,999 units. This might change later; I don’t want people stockpiling an infinite amount of inventory for a “rainy day”, but I don’t want Capacity to represent individual units of a commodity.

When selling, we take the original negative quantity and use the ABS() to subtract the quantity from the inventory. I had written the Remove method before I realized that I needed a negative value, so I created a dispatcher/factory that determines which method — add or remove — we invoke based on the positive or negative value of the Quantity we are passed. If the decrement quantity would take the cargo inventory to 0, we delete the record. We wouldn’t allow a removal operation to take quantity below 0 because that would not make any sense.

The reason we need to have both positive and negative values is that we also have a TransactionLedger object. When a player buys or sells, we record the product, the station, the quantity, and the price per unit value after we have added/removed the product and after we have credited/debited the wallet. We also record the date and time both as a means of sorting values and as a way to purge these records on occasion to maintain a responsive table. We can use this data to graph commodity prices over time, to remind players where they can buy and sell certain commodities, and give a window into where their money is going to and coming from.

Next up, I have to actually define ship components. I don’t have anything roughed out for this right now, although I have approached this topic in the past and have a vague notion of what I need to do. I’ll only work with the cargo bay components right now, as the goal is to get the buying and selling working before I add in more advanced mechanics like fuel and hit points.

Sound off!

This site uses Akismet to reduce spam. Learn how your comment data is processed.