Trading Functions [Cross-Save File/Cross-User]

[Timespiraled_RPG]

Hi everyone, I've been making a little project of sorts and as I was designing the crafting systems I got a flash of an idea.

Now, I'm no scripter, and my eventing skills are telling me that simply events won't do here.

I'm looking to know if either of these ideas are possible within the current RPG Maker VX Ace framework.

1. Allow players to sell items in their possession to a specific store. This store would hold those items as variables or database entries of some sort, allowing these items to be purchased by players from either:

• Another save file on the same computer.
• A different gamer on a completely different computer.

I am assuming the later would require a server/online host of some kind.

The idea behind the project is that as you are exploring an enormous Dungeon Region, there are no stores where you can buy items. Therefore, you turn raw goods and loot that you find (Leathers, Ores, etc.) into armor, weapons and consumables. These items can be sold to this database store and other players can now access them and vice versa.

As such, the main objective is to get a player driven economy and mercantile system going. Players will figure out what items are in hot demand, what items are not being purchased and work together to complete the game. As the game gets difficult, you'll need to rely on the items crafted by other characters (either yours if from another save file, or another player.)

It's an economic experiment so to speak.

===

I have no proposal as to how it would need to look, but the key functionality would be:

• The ability to sell and buy from a store. This store's items are only those sold by other players. (Example 1: Mark sells 20 Uncut Emeralds, 15 Iron Ore and 3 Fulminating Embers to the store. These items are now available to be purchased by other players (from a different save file or another player entirely.)
• The price of these items is not determined by the players at this time. When they sell the item they receive a flat amount of gold, and when players purchase the items, they buy it at a flat amount of gold. (Example 2: Mark receives 100G for each Uncut Emerald, 20G for each Iron Ore and 500G for each Fulminating Ember. If Bill wants to purchase said items, they might have a set price of 200, 40 and 1000 G respectively.)
• Items in the store would hopefully be able to be categorized by type. (Weapons, Armor, Materials, Consumables, etc)

Of course, as the only store in the game, players would need to sell items to make gold. 

I would make players need to select their professions (much like an MMO), meaning while Mark may be a Miner and a Jeweler, he is not able to make potions, weapons or armor. His resources would be sought after of course, as would the gems he carves, these having some benefit in-game.

===

Additional Content?

These are ideas that would compliment such a system, ones that I feel are not necessary, but would be useful:

• Messaging System: An online "chatroom" of sorts. The reason I mention this is as additional is that I see no reason why I could not simply create a forum with a chatroom, allowing players of the game to get together, plan, meet and chat.

===

I appreciate all help, advice and comments.

I am also willing to learn and understand what would be required. I figure if I can do it myself, it'd be a good lesson to learn.

- Matt

 

[Andar]

search around, there is a HTTP-script available for minimal online functions - Dekita made it and is currently checking interests, including interests in commissions for that script.


Your idea would probably be the maximum that script is currently capable of, but you'll need a server to run it and if you have no idea of how to program PHP and create a database you'll have to find someone who does this for you - both means payment as that isn't something that can be given for free (server is usually 10-20$ per month depenting on what capacity you need on the server)

 

[Engr. Adiktuzmiko]

the first method could probably be done with a short edit of my Shared Storages script, but the 2nd method would really need a script for sending and receiving data from a network

 

[Wavelength]

This is an extremely cool idea, and would introduce a lot of (potentially very positive) new wrinkles to the way your game is played.

I think my Limited Supplies Script would probably be pretty good for what you're trying to do with the shop, in a basic sense.

Now as far as making the data transfer across players... it's not too hard to do across files on the same computer.  Look in the help file for info on the "save_data" and "load_data".  In timeblazer, I'm using a $globals hash that I save under the System folder to track data across all files (such as high scores for action games and user options like music volume); I save the hash to the System folder every time it's updated and I load it every time the player starts a new game, loads a save file, or uses another function (like the Options menu) that requires it from the title screen.

Example of my LOAD command:$globals = load_data("System/Globals.rvdata2") rescue ok = false

Example of my SAVE command: save_data($globals, "System/Globals.rvdata2")

(If it fails to load, because there is no file there or the file is corrupt, it sets the "ok" local variable to false, which is the way I tell it to create a new $globals hash and then save it.)

If you need some more info on constructing Hashes, check out this documentation.

This should give you the skeleton of what you'd need to make such a system that will work across different save files on the same computer (assuming they can be found in the same folder).  If you want to expand it to all users in the world, you're getting into very tough territory.  People like Dekita who are really good at integrating simple network functions into RPG Maker (something I know literally zero about) might be able to help you out.

 

[Timespiraled_RPG]

Thanks again for the comments, I do believe however that I have a found another idea for creating a "trading" system of sorts, without the use of a server.

It would be a little more complicated for players of course, and requires time on my behalf as well. 

===

VARIANT TRADING OPTIONS 1 AND 2

Option 1: Player to Player Trading - Free Market Economies

Instead of selling to a mass market, players trade on a 1 on 1 basis. A script would be required I believe.

At game creation, each player is given an 8 digit code, corresponding to their in game player ID. This can be handled by events.

On online forums, chats, social networks, players can market their wares for a price. This would give an incentive to actually create a player economy.

Example 1

Mark is a Blacksmith in game and has produced a few items, notably a Superior Mithril Greatsword and 5 Mithril Bars. He goes online on the Dungeon Delve Forums and makes a new post in the Marketplace section, something along the lines of:

Mark's Smithy

Game ID: 11039037

Hey guys, I'm a Blacksmith on Dungeon Delve and I have the following items for sale at the moment:

Weapons

Superior Mithril Greatsword [1500 G]

Resources

Mithril Bars x5 [50G each or 220 for five]

PM me if you're interested or post below with your Game ID. We can haggle the price as well.

Now, imagine Ella wants to buy the Mithril Bars and she is fine with that price. She PMs or posts, and the deal is set. Both will go in game and do the following:

Ella (Buyer)

Ella goes into the Trading Options and selects Purchase. She selects from the long list of items the ones she desires and the quantity. She then inputs the amount of money she is paying for the item, as well as Mark's Game ID.

This information would exist in the form of a Text File/Code/Object, one which could be sent between players. My hope is for the creation of a text file. This Virtual Transfer contains coded information detailing the following: The Seller, The Buyer, The Gold Sent, The Items Desired and The Quantity in a coded form. This VT would be called an "Order"

She sends the Virtual Transfer to Mark.

Mark (Seller)

Mark will enter the Trading Options menu/store and selects Sales. The script would detect the Virtual Transfer, placed within a designated folder in the game files.

Mark could select this Virtual Transfer in the Menu and would see that to receive the Gold sent (220G) he needs to remove 5 Mithril Bars from his inventory. He selects to do so, the items are removed from his inventory and he receives the money. 

This creates a new Virtual Transfer, this one a "Package" containing the seller, the buyer and the items (quantity and item id again.)

Mark then sends it to Ella, who places it in the designated folder. This time however, opening the Trade/Store shows her that she has "Unopened Goods". She selects the goods, and they are added to her inventory. 

Troubleshooting

• Virtual Transfers are keyed between buyers and sellers to prevent mass trading and are deleted upon completion (removal of items from inventory and acquiring of items.)
• This does rely on a confidence system. I suggest a Forum based approach precisely to enforce the rules. Merchants who rob other players (by accepting the gold and removing the items from inventory, but never sending the Packaged Goods). Hopefully the fact that the items NEED to be removed to receive gold reduces incentive to commit fraud.
• Slightly convoluted to say the least but allows a free market of items. Players will figure out their own economy (based on Gold availability, item availability, item value, etc.)

What this would require

• I've attempted doing this with Events and I'm rather certain that it could be somewhat feasible but relatively ugly in terms of multiple "Choices" and "Variables".
• Therefore, a Script which could handle the transference of items would be perfect. A Purchase, Sell and Receive option would be required.  Encrypting and creating a Virtual Transfer as well, containing the Buyer ID, Seller ID, Gold Given, Item ID, Item Amount.

Option 2: Player to Host Trading - Weekly Markets

This second option would remove the player economy and instead become a flat trading system.

Players would sell items to the store. A script converts each sale into a proof of sale object/code that contains the following information:

• Item sold
• Quantity sold
• Seller ID
• The Sale Number.

This last point is important to prevent fraud. For example, this is Mark's first few times selling an item to the store. He sells a Pretty Rock and a Copper Bar. The Pretty Rock is a Junk item and therefore does not go to the Market. Instead, it simply gives Mark gold for having sold it. The Copper Bar is a Marketable item (script tags perhaps) and thus the script would generate a code indicating: Mark's Game ID - Amount Sold - Item Sold - Sale Number (1 in this case, this being the first Marketable item Mark has generated.)

The information above should be encrypted to prevent falsifying.

This file could be sent to the host, in this case myself.

By running these Proof of Sales through a decryption tool/script each week, I would receive a list of all Marketable items sold and their quantity. I then simply modify the Map containing the vendor by changing the Shop Event to contain the sold items and the quantity of those items from the previous week/time period.

Troubleshooting

• To prevent Market Switching, that is switching between a collection of saved Map data to access past shops, each time you access the following week's shops, a variable is increased in some way. If you were to load a previous week and your shop variable is higher than that week's number, the shop would simply say "It appears that my wares are out of date, perhaps you should try changing back to the latest wares?"

===

So there we have my two proposed ideas. Are these easier to do? They don't require a server. Let me know!

 

[Sixth]

You can not generate the players' ID with events. That would mean it is a game based ID, which means multiples of the same ID can be gotten, and that would obviously break your system.


Giving any kind of identifier for players will require a server which stores the already distributed IDs, or else the game would not know which ones were already distributed. And to use a server successfully, you will need to send and get data from the network. And this leads to the initial suggestions given by the others who posted here.

 

[Timespiraled_RPG]

You can not generate the players' ID with events. That would mean it is a game based ID, which means multiples of the same ID can be gotten, and that would obviously break your system.

Giving any kind of identifier for players will require a server which stores the already distributed IDs, or else the game would not know which ones were already distributed. And to use a server successfully, you will need to send and get data from the network. And this leads to the initial suggestions given by the others who posted here.

True, but assuming no more than 1000 players (even there it's a high number...) already an 8 digit code has such a slim chance of being repeated. If this is done by script, I'm sure we can go even higher and make that percentage chance virtually nil.

 

[Engr. Adiktuzmiko]

Depends on how you do it, but even if it's a randomized number, the fact is that you can still have repetitions unless a server keeps track of which has already been used... It might be slim, but the chance is there... And once it happens, you probably know how bad that could be for your game

 

[Zeriab]

Just generate a UUID. Risk for a collision is so low for this type of application to practically being risk-free.

You can generate one by using the standard SecureRandom code: https://raw.githubusercontent.com/sj26/ruby-1.9.3-p0/master/lib/securerandom.rb

Remove line 94 as Win32API already is in RGSS3 while trying to requiring it actually yields a LoadError. (Weird, right?)

With that code you can create a UUID like this:

SecureRandom.uuid p SecureRandom.uuid # See?
*hugs*

 - Zeriab

 

[Wavelength]

I don't think that I'd like serverless "player to player trading" with files in practice - while the idea is impressive, I think it would make for a very hassled and negative experience when used a lot.  I could be wrong.  Maybe it would be exciting for people.  But I think it would more often be seen as convoluted and unreliable busywork.  If you do want to make it a serverless system, "player to host trading" is probably the better way to go, but again, introduces some element of busywork that players have to deal with every week.

For both options: How would you prevent save-scumming based abuse?  (e.g., the player sells all their items, generates the file, and doesn't save their game, thus introducing the items to the market without losing them?)

For the "player to player" option: How would you prevent a player from copying a file to somewhere else on their computer, using it once (thus gaining the items and the file is deleted), and then using it again to gain two or more copies of those items?

 

[Timespiraled_RPG]

I don't think that I'd like serverless "player to player trading" with files in practice - while the idea is impressive, I think it would make for a very hassled and negative experience when used a lot.  I could be wrong.  Maybe it would be exciting for people.  But I think it would more often be seen as convoluted and unreliable busywork.  If you do want to make it a serverless system, "player to host trading" is probably the better way to go, but again, introduces some element of busywork that players have to deal with every week.

For both options: How would you prevent save-scumming based abuse?  (e.g., the player sells all their items, generates the file, and doesn't save their game, thus introducing the items to the market without losing them?)

For the "player to player" option: How would you prevent a player from copying a file to somewhere else on their computer, using it once (thus gaining the items and the file is deleted), and then using it again to gain two or more copies of those items?

As this is all theory, I would assume the following:

Against save-scumming, I imagine there exists a forced save option somewhere. 

As for the second, I would make the script only allow the particular "transaction" once, since the transaction I imagined would have an encryption of some sort containing sender ID, buyer ID, item, amount and the aforementioned transcation number.

Example:

Mark trades a Ruby to Emma.

Mark's ID is 001, Emma's is 002, a Ruby has an ID of 923, the amount of 1 is 1 and this is Mark's 48th trade thus something like this: 001002923148. Thus, you couldn't reuse a trade since the game would check that the trade ID hasn't been used before no?

Again, this is all just theory at the moment. I feel that focusing on simply cross-Save Files would be much more feasible.

 

[Wavelength]

As this is all theory, I would assume the following:

Well, that's fair.  I tend to think through the lens of "is this practical" moreso than "is this possible", so... like I said, I think that the idea itself, in an ideal world where you don't need to worry about implementation, is superb.  The market is such a great game element, and your ideas for files and transaction IDs are quite cool.

Against save-scumming, I imagine there exists a forced save option somewhere.

Yes.  There's a "save_data" RGSS command that can save to a specified file without user input; I actually use this in some of the recent additions I've made to timeblazer to do things like save High Scores to a separate file as soon as the player achieves one.

But there are several different types of save scumming you'd need to prevent, such as a player saving the same game to five separate files, then selling all the goods to the market on one (or four) of those save files.  Even if you force a save, they've still got the items in their "real" save file, and the market now has a lot more goods.

As for the second, I would make the script only allow the particular "transaction" once, since the transaction I imagined would have an encryption of some sort containing sender ID, buyer ID, item, amount and the aforementioned transcation number.
Example:

Mark trades a Ruby to Emma.

Mark's ID is 001, Emma's is 002, a Ruby has an ID of 923, the amount of 1 is 1 and this is Mark's 48th trade thus something like this: 001002923148. Thus, you couldn't reuse a trade since the game would check that the trade ID hasn't been used before no?

I think this approach is mostly solid, but there would still be ways around it.  For example, you could still import the Ruby into ten different save files (you could make this harder using a global file to track trades, but I believe a careful player could still get around it by replacing the global file after each import).  Then the receiving player could make ten trades back to the sending player, thus turning one Ruby into ten (or more) with a friend's help.

If a player is cheating in a game where the economy is limited to their own computer, well, the only person it's helping or hurting the experience of is themselves.  But if the economy is truly global, then a few cheaters can completely destroy the experience for everyone else.  I guess this is why I'd recommend either going all the way and figuring out how to implement this on a synchronous server, or just focusing on the local cross-file functionality and forgetting about ways to "fake" a global market.