|
|
Post by mvp on May 3, 2014 20:57:41 GMT
My questions are leaning more towards the programming aspect of the game regarding the amount of in-game currency that will be able to be stored per character on an account. My first question is about the layout we will be seeing in the money. There are games (most notably, World of Warcraft) that use the copper, silver, and gold system:  (the money in this patch was based on copper (the lowest form of money) and this would equal 2,147,483,646 copper) There are other games who do not attempt to sort your money and just leave it as a plain-as-day integer (in this example, Runescape):  Has a format been settled upon yet? My second question: how much money will a character be able to have at a single time? If I had to guess, 2,147,483,647 then 9,223,372,036,854,775,807 would be certainly be my first picks in predicting what you will be using. |
|
|
|
Post by minche on May 3, 2014 21:06:37 GMT
don't forget unsigned  = 18,446,744,073,709,551,615 but the exact value will depend on db and some other stuff. also, there's some other interesting ways to store integers rather than just plain integer field  |
|
|
|
Post by mvp on May 3, 2014 21:31:18 GMT
I believe unsigned would cause bugs when buying and trading so we should leave those out  and I really want to learn these "interesting ways". I've seen people going up to octodecillion and beyond with their numbers. Lets just disregard server memory and set the cap somewhere around centillion. Problem solved Who needs player models anyways when you have virtual money? |
|
|
|
Post by minche on May 3, 2014 22:03:29 GMT
why would it cause bugs with trading and buying? you're storing player's money as unsigned, there's no way someone can have negative coins. well you cant just set it up to centillion, INT filed would be measured in megabytes, and since that's a field that's associated with every char, and often changed it's bad. okay, some interesting ways. these are just ways to deal with big numbers, which will only come later in the game. to decide on the best way of storing the number you need to know a couple of stuff (this is just randomly what I can think of now lol): -rough min and max of number. for coins we know that minimum is zero, and maximum can depend on number of players, number of ways to get coins, roughly how many coins a player could get per transaction and so on.
- most common operations. again for coins, you only need addition and subtraction (I can't think of a scenario where you'd need to multiply player's coinage, let alone divide it)
- how often is it accessed. is is scheduled read/change or is it random? if it's random is it pretty often or maybe like daily or weekly. coinage is accessed and changed often.
- nature of change. triggered, random, event, does it affect other values? is there maybe some rule to the update (like if you know that the change is gonna be in multiples of 10 or something..)? for coinage - no such thing, it's triggered by events such as sale, loot, buy...so, the first and most obvious way is to store it as a string. since you only need addition and subtraction it's really easy to implement math for it, but since it is often updated and takes significant amount of space it's not recommended. it would be perfect if not every player had to store the huge string. some other methods I can think of now include representing it as a list (array, hash...). not as a list of digits, but a list with some (mathematical) rules/background. for instance, you can store a big number as a list of factors or something, but it fails with prime numbers and is very bad for constant updating (you'd need to update the list every time). other way, that doesn't fail with primes, is to store a list of modulus. for example, number 283782293 could be stored as [93, 22, 78, 83, 2]. I like this method the most, because it is easy to get back the original number (just print elements of array one after another) and it's easy to do basic operations - you just represent the number you need to add or subtract as array of modulus and add corresponding numbers to the original array (don't forget to carry the extras). so you could just enter the big number in string format, and then splice it to array and store it (or do basic operations with it) these are just simple methods that are fast to implement for addition and subtraction. if you need something to work with other operations too (and then some) I'm pretty sure there's books written on the subject (and there's also some libraries available). |
|
|
|
Post by mvp on May 3, 2014 22:39:00 GMT
The array method was always how I thought of doing it. I'd love play around with that in the near future when I have some free time.
The need for such a large quantity of money would not be needed towards the beginning life of the game nor in the middle due to the fact each account has numerous characters which can act as mules.
I believe Greg "GhostCrawler Street (previous lead game designer for Blizzard and current lead game designer for for Riot) released a dev blog a few years back indirectly stating unsigned ints and money caused issues. I'm not 100% sure of the logic behind his statements (as it wasn't a programming blog). I believe it had to do with the subtraction of money when purchasing items from shops.
|
|
|
|
Post by minche on May 3, 2014 22:50:02 GMT
it's not that hard to implement, like half an hour, tops (well, depending on your knowledge of programming and programming language(s)) and yeah ik, it most likely won't ever be an issue though BIGINT is usually enough, I just thought it's an interesting topic and only statements i can find deal with damage and levels and stuff, nothing about currency. a lot of people don't use unsigned though, because it's 'just' *2, but when you're dealing with big numbers *2 is a lot, especially if you're adding stuff up. if you have some multipliers (like for instance, crit damage) then it's obviously not enough. also, there can be some issues (with comparing, and some advanced operations) but it's all avoidable if you use it from the start |
|
|
|
Post by mvp on May 3, 2014 23:11:07 GMT
Well that's interesting. My whole assumption of in game currencies which has been based on a statement I read about a few years back has just been shattered.
You should pick up Llama's tech writeup section which seemed to die the day after it first appeared. You're very knowledgeable about this kind of stuff and I would love the read every sunday. I'm not sure how many people would enjoy a conversation like this but I had a blast learning a few new things.
|
|
|
|
Post by minche on May 3, 2014 23:23:22 GMT
well this is not really gamedev related heh, pretty low level stuff. also, programming is a field where you need to read read read. a lot of stuff can change in a matter of weeks, especially years... also, llama is preparing something awesome to show |
|
|
|
Post by iamallama on May 3, 2014 23:36:53 GMT
Just checked db table. Unsigned bigint meaning a cap of 18,446,744,073,709,551,615. And I prefer to keep the currency simple with just a single number. I can expand it later on the backside and store 2 fields to make it exponential if necessary. Either that or just change the number base. Convert the number on store into base36. You can still do math on the different base and when a bigint maxes out at 20 digits, a 20 digit base36 can store something like 32 digits of base 10.
And the tech writeup section died only because I don't have anything else that I can think of to write about. Only thing I have been working on is programming in Java for SmartFox or C# for Unity (which there are tons of tutorials already). Or server management/security which I'm probably doing something wrong as it is and would rather not highlight it. We haven't gotten far enough to go into the actual game making process (it is currently all stuff like behind the scenes programming). This is also why there are like 3-4 different sections so each person can give you a little update about what they are focusing on.
If you can think of something that you want written about, if/when we get there I have no problem writing something.
|
|
fredonia
Rock Crab
Posts: 76 
FO Level Status: Ascended
|
Post by fredonia on May 4, 2014 1:37:37 GMT
other way, that doesn't fail with primes, is to store a list of modulus. for example, number 283782293 could be stored as [93, 22, 78, 83, 2]. I like this method the most, because it is easy to get back the original number (just print elements of array one after another) and it's easy to do basic operations - you just represent the number you need to add or subtract as array of modulus and add corresponding numbers to the original array (don't forget to carry the extras). so you could just enter the big number in string format, and then splice it to array and store it (or do basic operations with it) Whoa, never thought of doing it that way. That really is ingenious. I usually store ints in just number bases like what llama was talking about, but this makes it way easier (at least for me) to manipulate numbers stored into an array.  This is pretty obvious to you, but I really am mindblown. I wish I was as cool as minche |
|
|
|
Post by minche on May 4, 2014 7:00:58 GMT
well it's not easy to manipulate, that's the catch. it's simple to store, read and do addition and subtraction. so it depends on how you want/need to use the number.
|
|
Akababa
Soft-Shelled Crab
Posts: 19
FO Level Status: Rebirth
|
Post by Akababa on May 5, 2014 3:50:38 GMT
Well that's interesting. My whole assumption of in game currencies which has been based upon based on a statement I read about a few years back has just been shattered. You should pick up Llama's tech writeup section which seemed to die the day after it first appeared. You're very knowledgeable about this kind of stuff and I would love the read every sunday. I'm not sure how many people would enjoy a conversation like this but I had a blast learning a few new things. Seconded, I miss the tech talk too!  Edit: sorry, didn't read llama's post. By the way, i thought unity was primarily used for 3d games. Does this mean lq might be in 3d? |
|
fredonia
Rock Crab
Posts: 76
FO Level Status: Ascended
|
Post by fredonia on May 5, 2014 4:12:12 GMT
Well that's interesting. My whole assumption of in game currencies which has been based upon based on a statement I read about a few years back has just been shattered. You should pick up Llama's tech writeup section which seemed to die the day after it first appeared. You're very knowledgeable about this kind of stuff and I would love the read every sunday. I'm not sure how many people would enjoy a conversation like this but I had a blast learning a few new things. Seconded, I miss the tech talk too! Edit: sorry, didn't read llama's post. By the way, i thought unity was primarily used for 3d games. Does this mean lq might be in 3d? 2 videos got posted in today's Development thread showing llama and some mods run around in a test map. It's as 2d as 2d gets. |
|
|
|
Post by iamallama on May 5, 2014 5:39:10 GMT
As of Unity version 4.3 (released sometime November/December) they have quite a lot of support for 2d. Many things I'm having to make myself, such as the maps, since 2d is so new. Also, everything still exists in 3d space (x, y and z) but z is ignored except for determining which layer to draw. Closer to the camera is drawn on top.
|
|
= 18,446,744,073,709,551,615
and I really want to learn these "interesting ways". I've seen people going up to octodecillion and beyond with their numbers. Lets just disregard server memory and set the cap somewhere around centillion. Problem solved 
This is pretty obvious to you, but I really am mindblown. I wish I was as cool as minche
