Smuggler Archive
Thread: Theory of slicing results and probabilities
zazo
Sat Mar 05, 2005 5:49 pm
#14
well now this would make sense really if we had a bare min slice based on master smuggler for each type of slice
armor effect: min slice 11? max 35
armor encumb min slice 15? max 45
weapon spd min slice 15? max 35
weapon dmg min slice 15? max 35
pretending they are dice for the sake of an easy visual and you were rolling 3 each slice with one really only having 2 options that of the type of slice and the other 2 having a numerical value that of a number between x and y
I would be willing to bet that we could find a definative bell curve within all slicing options if we were able to determin the value of "x" and "y"
I don't know or don't remember the definative answer on the absolute min slices on each type though and we would have to be sure that each roll determining the number was done with two dice and not three.
this of course does not in any way change the fact that the roll is random but it does give a great explaination of the odds of a value of a slice. and would be a good explaination in a fact sheet to customers.
good thinking
SpinningCloud
Sat Mar 05, 2005 8:13 pm
#15
Well since in all this time I've never seen anyone collect enough data to statistically determine the distribution I'd say it is all speculation.
As an ex-software engineer and ex-manager of software engineers (hardware also but that's not relevant here) I'd have to say that I always used a canned RNG as they were both simple to aquire, much easier to maintain and much easier to document the code that used them.
Today...and a few years ago when SWG was being coded sophisticated function libraries are quite common and I'd, as a manager, be pretty ticked with an engineer that insisted on reinventing the wheel.
So, based on the KISS principle alone with no data to sway things in another direction, I'd vote for a canned RNG.
Dragon942
Sat Mar 05, 2005 11:26 pm
#16
SpinningCloud wrote:
Well since in all this time I've never seen anyone collect enough data to statistically determine the distribution I'd say it is all speculation.
As an ex-software engineer and ex-manager of software engineers (hardware also but that's not relevant here) I'd have to say that I always used a canned RNG as they were both simple to aquire, much easier to maintain and much easier to document the code that used them.
Today...and a few years ago when SWG was being coded sophisticated function libraries are quite common and I'd, as a manager, be pretty ticked with an engineer that insisted on reinventing the wheel.
So, based on the KISS principle alone with no data to sway things in another direction, I'd vote for a canned RNG.
I think this is a valid point from the software engineer perspective. But at the same time, we have to remember where SWG comes from. It was developed by SOE and the team contained many people that worked on Everquest. Everquest was a traditional rpg, and when SWG first came out (and we are still struggling with this today) it was just a re-skinned, classic fantasy rpg. This would support the theory of something more along the lines of a 15 + 2d10 roll (or I guess 13 + 2d10 to get the results we get).
I don't think we could ever collect enough sample to points to prove it conclusively either way. And of course since its not open source, the world will never know.
SpinningCloud
Sun Mar 06, 2005 7:56 am
#17
Dragon,
While that might be true that the management came from old school MMROPGs and not professional programmers I really think that Sony probably hired software engineers to do the coding for SWG.
If we were talking about oh...say Artifact and not a division of Sony I might very well agree with you. These days though hackers usually aren't hired by large corporations to write even game software.
You could collect enough points to determine the distribution to a statistically significant degree. How they arrived at it though you're right, you'd need the source.
I still, and always have, subscribed to the KISS principle...it has led me astray far less often than not.
Message Edited by SpinningCloud on 03-06-2005 06:58 AM
ana-mo-cara
Sun Mar 06, 2005 7:02 pm
#18
For all intents and purposes its random, but remember that its a program, and cannot just make random choices its running off an equation even though we cannot decypher the equation its there. Yeah I have heard the entire bell curve thing, but the more I slice the more I realize thats not really true.
The answer is simple there are too many blackhole numbers that rarely role for me. For instance I seem to get more 35s then 34s. Let me put it this way decided to write it down one day. I sliced 230 weapons was refilling a vendor. I got 4 35 percent slices not one 34 so I thought just got lucky. There were three other numbers I did not hit, but I cannot recall what they were. That just stuck in my mind over two more weeks a few more 35s and yet still no 34s. Okay thats just weird. I laughed well not like I am going to lose any sleep. Finally a month later finally I got a 34. At that point I had to have sliced well over a thousand items.
The problem is if it is two equations bounceing off one another then I should be getting more 34s atleast more then 35. That just dosent seem to be the case. I am not sure if this is a good or bad thing. Maybe I am being denied alot of 34s.
Anyone else notice numbers that they never seem to roll that go against the curve?
SpinningCloud
Sun Mar 06, 2005 9:16 pm
#19
"...two equations bouncing off one another..."? *squinty-eyed look*
Ummm...take a statistically SIGNIFICANT sample and you can determine the distribution, and I guarantee there IS one...by definition. I'm sorry but "blackhole numbers" don't make any sense from a programming perspective...sorry, just doesn't fit.
RNGs are not truely random, they are pseudo-random because a 'seed' is used to start the generation process. A few things though make them effectively truely random for any single player in SWG. First you have NO insight or control over the order in which YOU, as an individual, get a number from the RNG function. Since there are many players, all whose clients are requesting them in a really random manner (due to the whims of the players and internet lag), the set of numbers you gethas no order within the raw sequence generated by the RNG...you get a truely random subset of that sequence.
Second the same RNG function (just with different calling parameters)that is seeded, probably on server reset, will be generating numbers for nearly every random process in the game, only a small portion of which will go to players doing slicing.
All in all, while the raw RNG output is only pseudo-random the set of numbers any one of us get from slicing is in fact random...within the upper and lower limits the RNG function was called with AND with the distribution parameters requested of the RNG.
Bermag
Mon Mar 07, 2005 2:35 am
#20
Built in distributed random functions or simulating dice rolls? Not sure which is true to be honest, either one might be possible. The programmers are probably not thinking in terms of 2D10 dice rolls etc but the game designers might. There is much tradition in computer games coming from board games like character stats is 1-18 etc. Not true with SWG though but in many CRPG.
I also is a strong believer in KISS principle. The reason I think that using 2 "dice rolls" instead of a built in non-uniform is that it actually follow the kiss principle 
- Every development tool has a basic random function. Built-in random generators producing non-uniform random result is dependant on the developement tool. To make portability easier developers might want to use somethign that works in all environment (they might develop server software for both Unix and Windows platform or at least want to make it as easy as possible to switch)
- Game designers might be "old-school" thinking in terms of dice rolls
- Might be easier to insturct programmers to use "dice rolls", i.e use mor than one random roll to produce a non-uniform result ratherthan having to use a more advanced random generator where you probably haver to specify mean value and standard deviation
Anyway we are just speculating here (but I love to discuss things like this lol).
And yes, computer generated random numbers are not true random (same seed value will always produce the same result), but in reality it is.
Bermag
Mon Mar 07, 2005 2:42 am
#21
lurdanta wrote:
You know this is all very interesting, but no matter how they go about doing it, there's nothing we can do about it. What does it matter how they generate it? It's a great intellectual question, but that's all it is, knowing how they make it random isn't really going to allow us to use this information.
Personally I agree with SpinningCloud, why would they go to all the extra effort.
I think it has a blue to know what the probabilites are. I am not a smuggler myself but weaponsmith selling sliced weapons (and unsliced as well). Knowing the probabilities for high-end slices help me when pricing those weapons. And for you as smugglers it might be a help to explain for disappointed customers who expected a 30%+ damage slice what their chances are.
Anyway, no matter what random method is used there are some things that we do know:
1) It is random
2) Speed or damage slice (or eff and encumbrance slice) have the same probabilities to happen. 50%
3) The random result are non-uniform and the probabilities for a mid range slice of around 25% (weapon or effectiveness slices) are higher. Seems to follow some kind of bell-shaped distribution.
Phoenix0op
Mon Mar 07, 2005 2:44 am
#22
the bad thing is, even if that was the right formula, and you could find out a way to predict it (you can predict any random number generated by a computer, because a computer cannot generate randomly, it has a routine) you could not do anything about it other than know the slice your gonna get, I think they shold take out the random 50% chance to get encumb or effect (speed or damage) and replace it with a switching number between red and blue and it changes "randomly" each slice, that way it would still be kind of random to the new people to the profession, but to the masters you would be able to predict the "random role" better because you have been sliceing longer
I loved it when I found out the pattern to the blue/red cube, was awsome, I would go into a cantina and group with somone, we would both bet 2500 credits and I would win every time hehe, I thought it was cool
this way it would be awsome to be a smuggler ( at least for me )
I was a smuggler when the game launched
but was dissapointed at master getting pretty much nothing
Message Edited by Phoenix0op on 03-07-2005 01:45 AM
Mcgreag
Mon Mar 07, 2005 3:50 am
#23
SpinningCloud wrote:Normally an RNG routine call takes a range and returns a value within that range with a distribution at the center of the range. If you ask for an integer between 15 and 35 then it will return a pseudo random number in that range.RNGs come in varieties for C++ that will generate floating point and integer numbers with uniform or nonuniform distributions. The nonuniform distributions can be of normal, bernoulli, poisson, binomial, hypergeometric, noncentral hypergeometric, multinomial, ultivariate hypergeometric, noncentral hypergeometric and shuffling.Why would they code something special when a simple standard function call with the variety offered by C++ RNG functions would suffice?Message Edited by SpinningCloud on 03-04-2005 01:54 PM
Well first of all if I have read it correctly the servers (where the random roll is most likely made, I would very much doubt it's made client side) is not written in C/C++ but in Java. I know there are built in functions for Gaussian distributed values in java (and uniformly distributed), but I don't think there are any others.
But from a developers point it seems easier to do 13+2dX (where X depends on your level in the slice tree) than to possibly implement on your own more mathematicly correct nonuniform random distribution. Remember that GreenMarine said that slicing (and mostly smuggler as a whole) was meant to be more complex but he didn't have the time to implement it. Quote: "We had so much stuff to do and so little time to do it!"
They most likely sat up something easy that worked as a placeholder for the more complex system where tool quality mattered etc but ever got to it implement it. Perhaps it was 2dX, perhaps it was gaussian, in any case the method of choice was probably what GreenMarine first thought of without too much deep consideration.
SpinningCloud
Mon Mar 07, 2005 9:36 am
#24
I found a binomial distribution RNG for Java rather quickly though I do admit the standards for Java are gaussian and uniform distribution RNGs without external transformation algorithms.
While he might not have had much time he did need to generate random numbers for way more systems in SWG than just slicing and I can't imagine it was easier to code a simplistic one seperately for slicing, combat, crafting, etc. than use canned RNG calls.
I also don't believe anyone has taken a statistically significant sampling with which to make ANY claims on the distribution.
All I'm pointing out is that the random number requirements for SWG in general, and slicing as a subset, can most simply satisfied by using canned RNGs not through custom coding. Fact is that coding an RNG for well distributed pseudo-random numbers require some thought and lack of time would indicate using canned functions.
Interestingly, not that I believe SOE used it, there is a plug-in card for PCs that uses a pair of noisy zener diodes to generate true random numbers. There is also an online service that serves true random numbers over the web using radioactive decay. If i were doing even a psuedo-random number today I think I'd considerreaquiring the seed through the online service periodically, especially if the RNG was used in any kind of a security sensitive environment.
Pyrewolf
Mon Mar 07, 2005 10:27 pm
#25
SpinningCloud wrote:
...
I also don't believe anyone has taken a statistically significant sampling with which to make ANY claims on the distribution.
...
Does this look statistically significant to you?
SpinningCloud
Mon Mar 07, 2005 11:17 pm
#26
Yeah, I didn't remember that thread and just replied to it as to the distribution.
You do know though that it STILL isn't enough data to nail down the distribuition? It strongly suggests Guassian and notuniform though.
That and the normal choices of Guassian or uniform for Java RNGs and I'd have to guess that the devs found the simplest solution to be using the canned RNG function...not all that surprising.