Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Draco18s]

When I get home I'll post a new compile, as RNG distribution aside, I think I've found a solution.

[Armok]

If you're going to follow his advice, you don't want to filter out the stupidly high stats ab initio, but instead test them against a base reference and cull anything that overshoots your bounds, which means the large positives don't matter that much because they get culled anyway (the large negatives on the other hand could mean your distribution is skewed).


As for the stats of the fighters, you could indeed put them at 3 standard deviations (which would be 0.683³ = 0.997 for an untransformed and untranslated Gaussian distribution. Post-multiplying these values ought to keep the distribution Gaussian, but I'm not too sure about that. Adding a constant does keep the distribution Gaussian for sure, as long as you stay away from analysing it at infinity), but that means over 99% of the individual stats of your runs are going to be worse then the reference. I'd at least start with more then 100 test units against 100 fighters to make the guys at the low end of the scale viable as well.

This. Please listen to this.

Also, don't look at crazy numbers and say "of that's ridiculous" without testing it. Instead, make so that just having a stupidly huge value in a single stat is never an universal win.

[Draco18s]

Except that it would be.  When I'm trying to design stats somewhere based around a median of 10* I can't have "4000" come back and be hitpoints.  It doesn't even matter of the remainder of its stats are 1, it would still win combat against any unit that has "rational" stats (i.e. between 0 and 30).  Same thing for a damage value of 4000.

The stats system isn't set up to accept huge values and counter them by units with rational stats being able to beat them.

I don't mind the occasional stat coming back being "super huge" but I want it super huge on a relativistic scale.  In this case, a 10 coming back for HitPoints (which gets multiplied by 25) or a 12 for damage (getting multiplied by 3).

There's also the problem of a Gaussian Distribution being heavily weighted towards the center.  I don't want heavily weighted towards the center as it (in the long run) makes all the units look exactly the same with very few outliers.

*Except Range, which is based in pixels, Number of Shots, which should be 1-3 for 90% of units peaking out at around 8 on very rare occasions,** and Armor Piercing, which is 0 for 90% of units.

**It actually requires a unit have extremely low damage for this to happen.  Even so, I haven't seen anything above 7.

[Draco18s]

Anyway, here's the current compile.

I'm looking into genetic algorithms, but I haven't figured out how to break my problem down into a problem that is solvable with genetic algorithms.

[qwertyuiopas]

A little bit of math can convert one value into another.

This one makes low values unlikely, and values close to 1 more likely.
2-(2/(x+1))


This one makes the middle values more likely and the extreme values less likely.
2x³-3x²+2x

[Draco18s]

Yes, I realize that.  But both of those take uniform distributions as their input, not Gaussian.

So all you did was make my point for me: I want a uniform distribution in my RNG.  I might not want my stats to be distributed evenly, but for right now, I do.*  If I don't want them evenly distributed, I need to perform math on that uniform distribution, not find a new RNG.

*Except number of shots and Range, which I've already taken care of.

[Virex]

Except that it would be.  When I'm trying to design stats somewhere based around a median of 10* I can't have "4000" come back and be hitpoints.  It doesn't even matter of the remainder of its stats are 1, it would still win combat against any unit that has "rational" stats (i.e. between 0 and 30).  Same thing for a damage value of 4000.

So you either need to use a function that is bounded, or you need to add a filter that filters out any units that are overpowered. Or you need a filter that set the build cost of units with stupid stats to equally stupid values.

[Shades]

Thing is without some kind of total limit then higher will always be better. x life, y range and z attack is good, but x+1 life, y range and z attack is better. While this is the case your winning designs will tend towards the upper bound on each stat.

Unless some of those stats such as speed are already derived from others, it didn't look like it but I could be wrong.

[Silverware]

These are nice little tests for this sort of concept.
I've always liked procedural generation for games, it makes more sense than massive sections of data that need to be stored with the installer.

However the problem with them is balance.
What you could do is work out a point system, where each stat can have a point added to it giving it like +1 speed or +1 damage, if you get those done cleanly then allocate say 30 points for a new ship and randomly distribute those to the stats you will get the same sort of thing with a semblance of balance added to it.
There will always be combinations that are better than others, but at least you can plan for these mathematically.

The other big problem is that you will never be able to predict it, unless you set the generation seed, and that just makes thing boring, so you have to be able to build a game that's either a real AI to work in a story line, or a game that doesn't rely on its story at all.

[Draco18s]

However the problem with them is balance.
What you could do is work out a point system, where each stat can have a point added to it giving it like +1 speed or +1 damage, if you get those done cleanly then allocate say 30 points for a new ship and randomly distribute those to the stats you will get the same sort of thing with a semblance of balance added to it.
There will always be combinations that are better than others, but at least you can plan for these mathematically.

That's exactly what I'm doing.

Thing is without some kind of total limit then higher will always be better. x life, y range and z attack is good, but x+1 life, y range and z attack is better. While this is the case your winning designs will tend towards the upper bound on each stat.

Precisely the problem with unbounded stats (as Armok keeps suggesting I do, despite evidence that it is a Very Bad Idea).

Unless some of those stats such as speed are already derived from others, it didn't look like it but I could be wrong.

Some are.  There are 5 RNG calls which directly effect 4 stats (two of the RNGs are multiplied together for the 4th stat), each of which deduct some points from a total.  3 of the remaining 4 stats are computed based on the values for those stats (no points deducted from the point buy, as these stats are entirely based on the previous four), the last stat is based off the remaining points of the Point Buy System.

The algorithm is on pastebin.  I think I've made some changes though.

[Armok]

Except that it would be.  When I'm trying to design stats somewhere based around a median of 10* I can't have "4000" come back and be hitpoints.  It doesn't even matter of the remainder of its stats are 1, it would still win combat against any unit that has "rational" stats (i.e. between 0 and 30).  Same thing for a damage value of 4000.

So you either need to use a function that is bounded, or you need to add a filter that filters out any units that are overpowered. Or you need a filter that set the build cost of units with stupid stats to equally stupid values.

This. Of COARSE you're not letting the designs that are ACTUALLY crazy into the game itself. But the way to do that is by testing them, not stopping them from coming up in the first way. That way you can have things that LOOK crazy, but turn out not to be.

Also, taking the square root of the distribution I gave before might give you numbers closer to the range you're asking for.

Ugh, if I had the time I'd just make my own game and leave you to commit your mistakes, but I don't.

[Draco18s]

Also, taking the square root of the distribution I gave before might give you numbers closer to the range you're asking for.

More like a log()...

[winner]

If I had the time I'd just make my own game.

please do

[Armok]

log'd work to, but that might give TO low numbers in many cases.

[Draco18s]

Just a small update here, nothing to show for it yet.  But I've started the process of trying to get each successive unit type to be determined through a genetic algorithm, rather than based on pure randomness.

I'm doing this by spawning 10* units per side--one side being all identical and the other being 10 random counters--and having them fight 1 vs. 1 and counting the winners and "breeding" the best units (from the non-uniform side) together.  When the offspring units are sufficiently fit (determined by how well they counter the uniform side units) they become the uniform side units.

The issue right now is two fold:
1) Determining how to define a chromosome.  Initially I used all the base RNGs into a bytearray, but this isn't sufficient, as only the 4 most significant bits of each 4 byte floating point number even matter.  I am considering converting each 0-1 four byte float to a 0-255 one byte int.
2) Working with individual bits in a chromosome.  Bytearrays only allow manipulation on the byte level and are tricky to work with even then (it's very easy to cause runtime errors).

*Probably will change.  10 doesn't allow a uniform number of offspring pairs.