Hey guys! I have been working on a lil’ project of mine, and I wanted to implement a marketplace system. You can buy and trade weapon skins in this game I have been working on. I also want to make it so you can sell it though for a price you set with in-game currency.
I’m fairly certain I know how to do this with DataStores, but is it really possible?
I would assume that I would have to create a new data set for a Datastore every time someone uploaded a skin for sale, which might get messy quick. On top of that, the market would have to be constantly refreshing every minute or so.
Has anyone had past experience with this system? Is it feasible to do with dataStores? And if so, what was your strategy for accomplishing it (i.e. how did you store everything within the dataStore, how many dataStores did you use, how did you update the store, etc.)
The main issue I see with this is the datastore budget. A system like this needs a lot of datastore API calls for things like syncing the marketplace; posting, removing, updating, purchasing, bidding, etc; on top of the already existing data systems in your game for things like player and (possibly) leaderboard data.
Games that use a system like this often host their own data server(s) with a practically unmetered request limit and bandwidth (or at least much higher than Roblox’s) and aren’t limited by Roblox’s budgeting system. Although the number of requests should be possible with the budget, Roblox implemented it in a weird way where the budget isn’t released all at once but spreads it out over the minute.
Yeah, that was precisely my concern. Something like this would probably end up calling a data-store hundreds of times every second across all servers.
I was considering running my own server, but it doesn’t really seem possible considering I am only 14 and still live with my parents, and we have no server in sight at my house.
EDIT: Although, a solution could be to have a server keep the new items put on sale and new sales, and update them to the marketplace every minute as opposed to when it is put for sale/bought.
People often just use a standard web-host with root accessibility, or rent a VPS/Dedicated server from a host such as AWS. The only issue is that it’s not free, sometimes even expensive. The best strategy is to leave out a system like this until your game generates a stable revenue stream and re-investing some of that to rent a server in the cloud.
You need to take consideration that this would be very demanding in datastores, since anyone could post a skin. You also need to take in mind that exploiters might just crash the game or make data stores unusable by uploading skins, because I don’t see a way for the client to send the information to the server without using remotes, so secure your remotes by adding some limits like one upload by day. The only way to not make the game laggy is to set up some database and use it with Glitch and make post requests to it and make the server retrieve the skins with a get request.
Yeah, that’ll probably be my best bet. I do think though that some optimization (such as what I included in my above edit) could make this possible in the short-term with the resources Roblox already provides.
The issue with updating it once a minute is that it becomes hard for people to keep up-to-date with bids, you’d have to use a sorting system to sort based on bid time and bid amount but the feedback for the bidder would be immensely delayed. Imagine having to wait a minute to hear “Sorry, but your bid was lower than the highest bidder, please try again.”
If bidding isn’t involved, then trading would still become a pain since it’d take a minute for the trade content to be synced.
I’ve completely ruled out a bidding system earlier, as that is essentially impossible with what I have.
Oh, I just saw your edit. That’s true, another issue could be that within that minute, multiple people buy the same deal, creating duplicates and inflating the economy, making all skins essentially worthless.
Welp, my last-resort would be where you can pay a slot in the marketplace to sell your item, or at least put the sale up for a day. From there, people can send requests to you as to how much they want to buy it for. This might be the only solution, but it’s a wonky one at best.
I’m not too sure Datastores alone will make for a good implementation on the feature you want. They’re certainly useful for saving and loading data, but it doesn’t provide efficient callback functions for when new data is saved. And you also have to worry about cache.
But try using the datastore to load all products on the market when the game loads into some table on a server script say ‘productMem’. Like a local memory updated with messaging service.
If a player sells or buys an item, make the appropriate change to datastore; then use messaging service to let other servers know about the update. Then have a function listen to sells and buys through the messaging service (messaging service should also message your own game I believe), and use that to update ur table ‘productMem’. When the player wants to see what products are available use productMem instead of datastore, to avoid costly calls and misinformation by outdated cache.
That’s what I’m thinking of doing, but the caps given to this service is pretty small, such as a max of only 20 messages received per minute, per server.
It really depends on the context of your marketplace and how important it is in gameplay. A game replicating stock exchange would have significantly more transaction requests than a trade feature on a FPS game.
You’ll typically want a server to have at most 15-17 transactions per minute, to give some headroom.
If you have a large server size or the marketplace has a heavy involvement in your gameplay, then you might find the HTTPService to have the least limitations and most freedom in your design. But that requires some development outside roblox.
It’s almost like murder mystery 2’s economy, but the cross-server part that I need is for the ability to sell and buy items. You can only put up an item for sale 5 times a day, so I doubt 15-17 requests per minute will every be reached, since a server only has a max of 13 people.
Nice, I don’t see the messaging service holding that back then. If you have 5 servers, then you have 110 incoming messages per topic to expend every minute. You could even get that to 220 messages if you have a topic for selling and a topic for buying.
Ah, smart. I’ll definitely use dual-topics then. My last concern is the data cap, 1024 characters.
I’m just going to have to play it by ear and see if that is enough for a table containing data such as UserId, The item, the price, etc. It’ll definitely need some tweaking no doubt but that’s a fairly large limit for only 3-4 strings.
I see many people concerned with DataStore Budget, this is, yes an issue, but datastores have one much bigger issue.
The caching behaviour of Get and SetAsync.
This issue directly affects marketplaces that use datastores, if you want an alternative look into MessagingService or self-host on a VPS or smth
Get/SetAsync will cache it’s return to save computation times. This means if you update the key on another server, it will not update on the current server.
A few other developers and I took a look, and came up with this strategy:
The servers will use DataStores to get the marketplace when they fire up.
The servers will use MessageService to detect any changes to the marketplace while the server is running, and adjust.
The servers will periodically update the Async every minute.