# Where to implement storable items

I'm creating a multiplayer online trading game. The things that are traded range from raw items to complex products. For example Steel is a raw item. Mechanical Assembly is a more complex item that requires 2x Steel and maybe 1x Rubber. Then Hydraulics is an item that contains 2x Mechanical Assemblies and 1x Electronics (which is another complex item). So and so forth.

These items will be created by me, players can't create their own items, so it doesn't need to be able to handle arbitrary layers of complexity for items.

If my example isn't clear, think Minecraft. You have wooden planks, which can be made into sticks. From there the sticks - combined with metals - can be made into tools. My game is nothing to do with minecraft or any sandbox building game, but it uses a similar progressive complexity to creating items that I want to have in my game.

My question is basically, how do you store something like this assuming that I will want to add more items in the future? Do you store it in a database or in a seperate library that the game uses?

EDIT

None of the items actually "do" anything, they are simply there to either sell, purchase, or combine with other items to make a more complex item, which can then be sold, purchased or combined... you get the idea. The items themselves would not have any properties, but the instances of the items would. For example an item that one player has would have a certain "quality" and if they were selling it a certain "price". An instance of that same item that a different player had would need to have a different "quality" and "price" if they were selling it.

I think the price part will not be required on an individual item because instead I would have a "sale" object which was for a price and contained certain items.

• You don't want to store Mechanical Assembly as 2x Steel + 1xRubber, you want to replace these 3 component items with one Mecanical Assemly item and store that. – Markus von Broady Nov 2 '12 at 12:43

If it's going to be an online game with constant communication between the server and the client, then relational database on the server side is the way to go. In SQL, for example, you can have the following tables:

TRADEGOODS (id, name) //examples: (3, "Steel"), (4, "Wood")
PROPERTY (id, name)  //examples: (2, "Sell price"), (3, "Buy price")
//example: (3, 2, 5000)   This would mean that the sell price for steel is 5000 credits.


Then you could have a table representing the inventory of the player:

INVENTORY(player_id, tradegoods_id, amount)


A simple transaction would be, if the player with the id 5 sells 10 steel to the shop, to reduce the 'amount' value by 10 where the 'tradegoods_id' is 3 (steel) and the 'player_id' is 5. Of course you have to check if this is a valid transaction... But I think you get the idea.

Edit: Important to note that your clients should NEVER access directly the SQL database. They only communicate with the server application, which will access the database when necessary.

• +1 for thinking ahead, though I wouldn't normalize the tradegoods buy and sell prices and your example lacks the "receipe" data – Thomas Nov 2 '12 at 11:03
• @Thomas Thanks, I'm glad you like the answer. It's incomplete, of course, since such a system can get very complicated very soon. In my browser-based MMO which I made for my MSc project, I had 30+ tables, half of which were part of the trade / storage / inventory system. I didn't normalize the trade goods back then - and this caused some issues when I wanted to add properties. I'm still not sure if adding new columns ("properties") to a table in a live system is OK... That's why I show a normalized solution here. – Marton Nov 2 '12 at 11:39

I think a big question you need to ask yourself is, what information actually needs to be stored? (And your question is a little vague as well)

If it's just a list of recipes (i.e., A + A + B = C), you could probably store it in something as simple as an XML document, which could then be saved locally to whatever's running the server and deserialized when needed. Simply assign each item an ID number (an int or enum should be fine) and serailize both the list of component IDs, and the id of the resultant product.

Using XML lets you make changes to recipes without having to recompile, or give each player a new build, which is a definite plus in a multiplayer game, I think.

• Thanks, I edited the question to try and clarify how the items would be used a little. – James Hay Nov 2 '12 at 3:07