Afar MV
- Thread starter Ellie
- Start date
Juan J. Sánchez
Sponsor
They look real nice, Amy.
I'm not convinced that GPS is a good idea, especially if a real-time map is never displayed. Pedometer would probably be better, or coarse location via cell towers if you're trying to figure out if a player is near a bunch of trees or the ocean or something.
Are you making it a web-app or will you do a webview wrapped client?
Are you making it a web-app or will you do a webview wrapped client?
So you have an item you want to sell.
You pop it in the auction house. While it's there you can take it back again but you can't use it while it's in there.
You set a minimum price you would accept for it.
----------------------------
You want to buy an item. You choose the item from a list, and see that x number are available.
You set a maximum price you would be happy to pay.
------------------------------
The game matches up the lowest price with the highest offer. If they match, the item buys for the lowest available price.
------------------------------
The game tracks the average price paid for an item and displays this as the recommended price when you go to enter a price. It also uses this for any merchants selling items around the world.
This is a complete copy of the system RuneScape uses, of course. But if I can tweak and tailor it to my own game nobody will notice. :shades:
The differences:
- No limit on how many different items you can attempt to buy or sell
- If you're struggling to sell, the game will offer you to sell to merchants for half its market value, and will lower the average price slightly
- If you're struggling to buy, the game will offer you to buy from a merchant for double its market value and will higher the price slightly
- The game displays to people what items people are currently seeking and provides mini-quests with rewards for anyone who goes out and gathers them to put in the system.
- The game displays what items are available to buy, just doesn't say their price. For ex it will say "there are 20,496 steel swords for sale!".
Might have got them the wrong way around slightly.
It will integrate with the game and with the lore. So merchants will have conversations based on the scarcity of things, that sort of thing.
Player-to-player trading will be semi-integrated. It will tell you roughly what each set of items is worth and suggest upping or lowering your offer.
You pop it in the auction house. While it's there you can take it back again but you can't use it while it's in there.
You set a minimum price you would accept for it.
----------------------------
You want to buy an item. You choose the item from a list, and see that x number are available.
You set a maximum price you would be happy to pay.
------------------------------
The game matches up the lowest price with the highest offer. If they match, the item buys for the lowest available price.
------------------------------
The game tracks the average price paid for an item and displays this as the recommended price when you go to enter a price. It also uses this for any merchants selling items around the world.
This is a complete copy of the system RuneScape uses, of course. But if I can tweak and tailor it to my own game nobody will notice. :shades:
The differences:
- No limit on how many different items you can attempt to buy or sell
- If you're struggling to sell, the game will offer you to sell to merchants for half its market value, and will lower the average price slightly
- If you're struggling to buy, the game will offer you to buy from a merchant for double its market value and will higher the price slightly
- The game displays to people what items people are currently seeking and provides mini-quests with rewards for anyone who goes out and gathers them to put in the system.
- The game displays what items are available to buy, just doesn't say their price. For ex it will say "there are 20,496 steel swords for sale!".
Might have got them the wrong way around slightly.
It will integrate with the game and with the lore. So merchants will have conversations based on the scarcity of things, that sort of thing.
Player-to-player trading will be semi-integrated. It will tell you roughly what each set of items is worth and suggest upping or lowering your offer.
I think that if the game picks up I will eventually do a wholescale interface rehaul with advice from or done by a professional UI artist.
I'm a bit stuck at the moment programming wise.
I have always done my items as individual entries in a database. So:
table_items = id, user_id, item_id
This makes it very easy to use as adding or removing items is as simple as UPDATE and DELETE FROM, while checking the amount can be done with count.
But that means if you have 10,000,000 of an item, which is reasonable to expect in what is basically a RuneScape clone, you end up with both a lot of entries in the database and a lot of processing to do the count.
But I don't know which I should be doing. I could do this:
table_items = id, user_id, item_id, quantity
But then there is still one entry for each individual item_id.
Logically the best way to do it seems to be to store items in the user data table:
user_data = user_id, ..., name, etc, item_1_quantity, item_2_quantity, item_3_quantity
But then each item I add to the game will require me adding a new column, and I'd rather it be dynamic. Not easy to manage items in this way.
So what's the best way to go about this? (Probably just the table_items way above).
I'm trying to think what else I might need to store for each individual item. Perhaps I could store the date it was gained, where it was found, and other data so that the user can look this up, which might be cool? That would mean I'd have to do it the table_items way.
Does mean that I would have to:
TO ADD x OF AN ITEM:
- check if item exists
- - if exists, add one to the quantity
- - else, INSERT with quantity x
TO DELETE AN ITEM
- check if item exists
- - if exists, check the quantity is above 0
- - - if above 0, remove one from the quantity
- - - else return error
- - else return error
- else INSERT with quantity 0 to save processing later
Gah. I have sql sometimes. I wish there was a "DELETE IF EXISTS", "SELECT but INSERT IF NOT EXISTS" etc. Probably is. I should read some stuff.
...and then whichever I go with I am going to have to make a script to replace all the items people have already earned with the new format.
2259 total. Eugh.
I'm a bit stuck at the moment programming wise.
I have always done my items as individual entries in a database. So:
table_items = id, user_id, item_id
This makes it very easy to use as adding or removing items is as simple as UPDATE and DELETE FROM, while checking the amount can be done with count.
But that means if you have 10,000,000 of an item, which is reasonable to expect in what is basically a RuneScape clone, you end up with both a lot of entries in the database and a lot of processing to do the count.
But I don't know which I should be doing. I could do this:
table_items = id, user_id, item_id, quantity
But then there is still one entry for each individual item_id.
Logically the best way to do it seems to be to store items in the user data table:
user_data = user_id, ..., name, etc, item_1_quantity, item_2_quantity, item_3_quantity
But then each item I add to the game will require me adding a new column, and I'd rather it be dynamic. Not easy to manage items in this way.
So what's the best way to go about this? (Probably just the table_items way above).
I'm trying to think what else I might need to store for each individual item. Perhaps I could store the date it was gained, where it was found, and other data so that the user can look this up, which might be cool? That would mean I'd have to do it the table_items way.
Does mean that I would have to:
TO ADD x OF AN ITEM:
- check if item exists
- - if exists, add one to the quantity
- - else, INSERT with quantity x
TO DELETE AN ITEM
- check if item exists
- - if exists, check the quantity is above 0
- - - if above 0, remove one from the quantity
- - - else return error
- - else return error
- else INSERT with quantity 0 to save processing later
Gah. I have sql sometimes. I wish there was a "DELETE IF EXISTS", "SELECT but INSERT IF NOT EXISTS" etc. Probably is. I should read some stuff.
...and then whichever I go with I am going to have to make a script to replace all the items people have already earned with the new format.
2259 total. Eugh.
You definitely do not want to have an entry for each individual instance of an item. Stack them up where you can.
Problem with SQL is that it's too flat. You'd have a table that's pretty much got a column for user_id as a key, so you can grab the entire inventory of a user, and also item_id as a key so you can find an item for a specific user. You'd then have item_quantity to track multiple items.
There's nothing wrong with a single entry for each item_id. You don't need an "id" column as your primary key would be the composite of "user_id" and "item_id" (you can never have a user_id with two entries of the same item_id, the quantity column does that).
Your table would look like this;
This is UNTESTED code, I haven't done SQL in about 5 years so some of this is probably wrong, but you should get the idea.
Here's information for the "ON DUPLICATE KEY UPDATE" http://dev.mysql.com/doc/refman/5.7/en/ ... icate.html
Here's information for the "GREATEST" compare operator https://dev.mysql.com/doc/refman/5.7/en ... n_greatest
EDIT: You'd replace INTEGER for your numeric type. For the GREATEST operator to work, it needs to be a signed integer, as unsigned would underflow into a very large number.
Problem with SQL is that it's too flat. You'd have a table that's pretty much got a column for user_id as a key, so you can grab the entire inventory of a user, and also item_id as a key so you can find an item for a specific user. You'd then have item_quantity to track multiple items.
I don't think this is the logical way to store items. This is probably the most naive way to solve the problem.
There's nothing wrong with a single entry for each item_id. You don't need an "id" column as your primary key would be the composite of "user_id" and "item_id" (you can never have a user_id with two entries of the same item_id, the quantity column does that).
Your table would look like this;
SQL:
<div class="sql" id="{CB}" style="font-family: monospace;"><ol><span style="color: #993333; font-weight: bold;">CREATE <span style="color: #993333; font-weight: bold;">TABLE Inventories (
user_id INTEGER,
item_id INTEGER,
item_quantity INTEGER,
<span style="color: #993333; font-weight: bold;">PRIMARY <span style="color: #993333; font-weight: bold;">KEY ( user_id, item_id )
);
/* Add X to ITEM_ID for USER_ID */
<span style="color: #993333; font-weight: bold;">INSERT <span style="color: #993333; font-weight: bold;">INTO Inventories( user_id, item_id, item_quantity )
<span style="color: #993333; font-weight: bold;">VALUES ( USER_ID, ITEM_ID, X )
<span style="color: #993333; font-weight: bold;">ON DUPLICATE <span style="color: #993333; font-weight: bold;">KEY <span style="color: #993333; font-weight: bold;">UPDATE
item_quantity = item_quantity + X;
/* Remove X at ITEM_ID for USER_ID, clamp to zero */
<span style="color: #993333; font-weight: bold;">UPDATE Inventories
<span style="color: #993333; font-weight: bold;">SET item_quantity = GREATEST( item_quantity - X, <span style="color: #cc66cc;">0 )
<span style="color: #993333; font-weight: bold;">WHERE ( user_id = USER_ID, item_id = ITEM_ID );
This is UNTESTED code, I haven't done SQL in about 5 years so some of this is probably wrong, but you should get the idea.
Here's information for the "ON DUPLICATE KEY UPDATE" http://dev.mysql.com/doc/refman/5.7/en/ ... icate.html
Here's information for the "GREATEST" compare operator https://dev.mysql.com/doc/refman/5.7/en ... n_greatest
EDIT: You'd replace INTEGER for your numeric type. For the GREATEST operator to work, it needs to be a signed integer, as unsigned would underflow into a very large number.
You could probably merge the add and subtract into a single operation too;
-X would either create a new entry with quantity 0 or modify an existing entry, clamping to 0.
+X would either create a new entry with quantity X or modify an existing entry.
EDIT: A brief look online shows that some people are against composite keys. It may not even be supported by your SQL software. In that case, you'd need a unique id for each entry and you'd have to use the WHERE operation a whole bunch. SQL is shit.
SQL:
<div class="sql" id="{CB}" style="font-family: monospace;"><ol><span style="color: #993333; font-weight: bold;">INSERT <span style="color: #993333; font-weight: bold;">INTO Inventories( user_id, item_id, item_quantity )
<span style="color: #993333; font-weight: bold;">VALUES ( USER_ID, ITEM_ID, GREATEST( X, <span style="color: #cc66cc;">0 ) )
<span style="color: #993333; font-weight: bold;">ON DUPLICATE <span style="color: #993333; font-weight: bold;">KEY <span style="color: #993333; font-weight: bold;">UPDATE
item_quantity = GREATEST( item_quantity + X, <span style="color: #cc66cc;">0 );+X would either create a new entry with quantity X or modify an existing entry.
EDIT: A brief look online shows that some people are against composite keys. It may not even be supported by your SQL software. In that case, you'd need a unique id for each entry and you'd have to use the WHERE operation a whole bunch. SQL is shit.
So for the marketplace, I have three columns in the primary key.
ITEMS = user_id, item_id, minimum, quantity
REQUESTS = user_id, item_id, maximum, quantity
You can have requests at multiple prices, for if you quickly want one log for 1,000 gold, but want a long term request for a million logs at 100 gold each. Each individual request is defined by its (user_id, item_id, maximum).
When somebody adds an ITEM, the game searches for any REQUESTS that meet the MAXIMUM price you have offered. If below the maximum, it performs the trade.
When somebody adds a REQUEST the game searches for any ITEMS that meet the MINIMUM price you have offered to sell it for. If above the minimum it performs the trade.
Edit: new mockup.
ITEMS = user_id, item_id, minimum, quantity
REQUESTS = user_id, item_id, maximum, quantity
You can have requests at multiple prices, for if you quickly want one log for 1,000 gold, but want a long term request for a million logs at 100 gold each. Each individual request is defined by its (user_id, item_id, maximum).
When somebody adds an ITEM, the game searches for any REQUESTS that meet the MAXIMUM price you have offered. If below the maximum, it performs the trade.
When somebody adds a REQUEST the game searches for any ITEMS that meet the MINIMUM price you have offered to sell it for. If above the minimum it performs the trade.
Edit: new mockup.
Nathaniel3W
Member
Very interesting. Now I'm just thinking about how I'm going to program my high-frequency trading algorithm to snap up undervalued items and sell when someone sends out an attractive buy-order. Buying from pessimists and selling to optimists and all that.
It'll be good for the economy, I'll provide liquidity, and as a side-effect I'll make a handsome profit. :biggrin:
It'll be good for the economy, I'll provide liquidity, and as a side-effect I'll make a handsome profit. :biggrin:
You'll never see the offer prices for either side, so while you can do that it might take a while. You won't know that someone's selling an undervalued item, you'll just pick it up if you put an offer in and it happens to be there.
It is good for the economy though. Merchanting is important in an MMORPG. Items need to have worth.
There will be other systems at play:
- If you put a high offer (above 200% its average price) and it doesn't buy for a week, you'll automatically buy it (from a central bank)
- If you put in a low sale price (below 50% of its average price) and it doesn't sell for a week, you'll automatically sell it (to a central bank)
I am unsure how that will affect the economy however.
Any items on peoples want lists that are struggling to buy but are around the average price will spur mini quests, called Bounty Seeker, where you will be able to go and find said item and sell it to get points to use in a special store. Or something like that.
If you undervalue an item, you will get a warning message. Similarly if you overvalue a purchase price.
And finally there will be limits on how many of an item you can flip in a day (flipping meaning buying then instantly reselling).
It is good for the economy though. Merchanting is important in an MMORPG. Items need to have worth.
There will be other systems at play:
- If you put a high offer (above 200% its average price) and it doesn't buy for a week, you'll automatically buy it (from a central bank)
- If you put in a low sale price (below 50% of its average price) and it doesn't sell for a week, you'll automatically sell it (to a central bank)
I am unsure how that will affect the economy however.
Any items on peoples want lists that are struggling to buy but are around the average price will spur mini quests, called Bounty Seeker, where you will be able to go and find said item and sell it to get points to use in a special store. Or something like that.
If you undervalue an item, you will get a warning message. Similarly if you overvalue a purchase price.
And finally there will be limits on how many of an item you can flip in a day (flipping meaning buying then instantly reselling).
I'm very interested in how you handle your virtual economy.
The central bank idea sounds like it's designed to allow single-player trading at a disadvantage to multiplayer trading.
The mini quest idea sounds like a really good way to handle the problem of never finding what you're looking for. The current view on real-money transactions for games is that you pay to avoid spending the same value of your time working for the item, so this would be the reverse of that - unable to pay => work on a quest to earn your item (quest itself I would presume costs resources as well as time + a risk factor).
The value of an item in online worlds is usually dictated by the players, so undervaluing and 200% value tests could end up being beneficial to the players in weird way - or detrimental depending on how you look at it. One scenario could be quest for items without breaking budget, sell undervalued, repeat. Another scenario could be the value of an item goes up because it proves to be powerful/cool/rare, so selling at 300% becomes normal.
I've got ideas for my own game with handling the economy (more like, to never have to handle it at all) where the base item sold in the game shops probably shouldn't be sold for more than it costs in the shops, but the item can be powered up by players so the value of it increases, making it more sensible to sell it above shop value. It massively complicates things as items now become unique, so handling it online would be nuts (especially in SQL), this only works nicely for me because trades are handled between clients, with no trade-list server in the middle, that's not an option for Afar.
Are you going to have trade expiry times too? So if an item goes unsold and it's not below 50% it gets taken off the market? I think that would be acceptable if a report is given to the trader of possibly why it didn't sell (maybe store how many players saw the item and compare it against the prices of other items in its category).
The central bank idea sounds like it's designed to allow single-player trading at a disadvantage to multiplayer trading.
The mini quest idea sounds like a really good way to handle the problem of never finding what you're looking for. The current view on real-money transactions for games is that you pay to avoid spending the same value of your time working for the item, so this would be the reverse of that - unable to pay => work on a quest to earn your item (quest itself I would presume costs resources as well as time + a risk factor).
The value of an item in online worlds is usually dictated by the players, so undervaluing and 200% value tests could end up being beneficial to the players in weird way - or detrimental depending on how you look at it. One scenario could be quest for items without breaking budget, sell undervalued, repeat. Another scenario could be the value of an item goes up because it proves to be powerful/cool/rare, so selling at 300% becomes normal.
I've got ideas for my own game with handling the economy (more like, to never have to handle it at all) where the base item sold in the game shops probably shouldn't be sold for more than it costs in the shops, but the item can be powered up by players so the value of it increases, making it more sensible to sell it above shop value. It massively complicates things as items now become unique, so handling it online would be nuts (especially in SQL), this only works nicely for me because trades are handled between clients, with no trade-list server in the middle, that's not an option for Afar.
Are you going to have trade expiry times too? So if an item goes unsold and it's not below 50% it gets taken off the market? I think that would be acceptable if a report is given to the trader of possibly why it didn't sell (maybe store how many players saw the item and compare it against the prices of other items in its category).