Print

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

[Draco18s]

small things can matter a lot.

I already agreed to that statement.  Moving on.

Back to my project:
If I attempt any method to get the units to not-focus fire on the 0'th targettable unit (i.e. first unit in the array) the results are not desirable.  The combats will either fall one of two ways:
1) Program enters an infinite loop,* unable to generate a unit that is better than the goal.
2) 1 > 2, 1 > 3, 3 > 2.  I.e.  1 beats everything.  Which makes no sense.  Happens every time it doesn't hit an "infinite" loop.

*Busy Beaver.  How infinite the loop is is unknown, it doesn't matter.  140 consecutive wins is significant enough for me to abort.

[Akhier the Dragon hearted]

   It sounds more like the units are just picking something
out of an array and not really targeting stuff. It should
not matter if that guys number 500 as long as its the
closest guy to a ship. The best way to work it would be
to have it choose the closest target and have the unit
go after it till its dead then chose the closest target again
and repeat. Course this is my own opinion only so take it
with a grain of salt.

[Draco18s]

They're not "picking out of an array with no regards to distance."
First:
There's a list of all enemies.
From that list, all of the enemies that are within range* are pushed into an array.
The targetted unit is then chosen from that array.

From that second array, if I pick "unit 0"** then I get good results.  That is, 2 always beats 1, 1 always beats 3, and 3 always beats 2.

As soon as I try a different rule, the program either grinds to a standstill (i.e. infinite loop) or doesn't produce desired results (1 beats 2 and 3).  That includes picking the nearest enemy.

*If none in range, then all units within 200.
**Array index 0 is the first item in the array.

[Akhier the Dragon hearted]

   That is different from how it seemed. Sorry for
misinterpreting what you said about it.

[Draco18s]

   That is different from how it seemed. Sorry for
misinterpreting what you said about it.

0'th targettable unit

By "targettable" I meant "enemy in range."

[Nivim]

 So the question becomes; what is guaranteed about the first unit in the second targeting array that would account for this?
 What happens when you tell it to do something un-intuitive like going after the farthest unit in its range"*"? Are there specific differences between the farthest and nearest?

(Now that I can correct the strangeness in our previous conversation, I don't see the point: it's better suited to a conversation months from now.)

[Draco18s]

I went and pestered Keith who works on AI War and he was more than willing to send over the entire targeting function that AI War uses, which is how they did the strong/weak text in 3.x (which is essentially what I'm doing), which I'll dig through this weekend.

I didn't even ask for it, I was just looking for some insight into how I might do what I am doing better.

So the question becomes; what is guaranteed about the first unit in the second targeting array that would account for this?

I don't understand.  Each unit in the array is the same.  Except that it's going to be the same unit for every ally (very very often).  So you get the same behavior as if you turned on "Non Sniper Focus Fire" in AI War.  Which is very brutal in its killing efficiency and I'd rather not have that.

What happens when you tell it to do something un-intuitive like going after the farthest unit in its range"*"? Are there specific differences between the farthest and nearest?

Farthest unit.  Hm.

Essentially....in a 4v4 fight, numbered top to bottom...

1 and 2 fire on 4, 3 and 4 fire on 1.

Under a certain set of assumptions that may or may not be true for all fights.

(Now that I can correct the strangeness in our previous conversation, I don't see the point: it's better suited to a conversation months from now.)

Why would that be?

[Nivim]

So the question becomes; what is guaranteed about the first unit in the second targeting array that would account for this?

I don't understand.  Each unit in the array is the same.  Except that it's going to be the same unit for every ally (very very often).  So you get the same behavior as if you turned on "Non Sniper Focus Fire" in AI War.  Which is very brutal in its killing efficiency and I'd rather not have that.

You answered the question directly, if that explains the vagueness in it; ~"the first unit in the second targeting array is guaranteed to be the same for all units in range". I should have realized the numbers were not re-initialized for each unit checking for targets.
 I hadn't ever looked up AI War before you mentioned it, but it sounds like that find is exactly what you needed; why don't you start mining it out now?

(Now that I can correct the strangeness in our previous conversation, I don't see the point: it's better suited to a conversation months from now.)

Why would that be?

(Sigh?) My end point (which I had almost totally lost track of) involving the existence of more complicated sets of balance making simpler sets inherently unstable would only be useful after you already knew how to balance unit functions and were working on your alpha for the game.

[Draco18s]

So the question becomes; what is guaranteed about the first unit in the second targeting array that would account for this?

I don't understand.  Each unit in the array is the same.  Except that it's going to be the same unit for every ally (very very often).  So you get the same behavior as if you turned on "Non Sniper Focus Fire" in AI War.  Which is very brutal in its killing efficiency and I'd rather not have that.

You answered the question directly, if that explains the vagueness in it; ~"the first unit in the second targeting array is guaranteed to be the same for all units in range". I should have realized the numbers were not re-initialized for each unit checking for targets.

The arrays are reinitialized, but because the code is the same the odds that each array ends up being identical is extremely likely.
Works like this:
For each enemy unit:
   is it in range?
     push

So if the first time it runs, all four units are in range (or rather not in range, but are within 200 pixels, which is what happens when nothing is in range) then it pushes the same units into the unique arrays in the same order.  So even though they are uniquely declared, they are identical.

I hadn't ever looked up AI War before you mentioned it, but it sounds like that find is exactly what you needed; why don't you start mining it out now?

I've only recently been communicating with Keith directly, and I know he's a busy guy.  I've also been wanting to solve the problem myself, as best I can, first.

(Now that I can correct the strangeness in our previous conversation, I don't see the point: it's better suited to a conversation months from now.)

Why would that be?

(Sigh?) My end point (which I had almost totally lost track of) involving the existence of more complicated sets of balance making simpler sets inherently unstable would only be useful after you already knew how to balance unit functions and were working on your alpha for the game.

I'm not going to be making anything super complex.  A few special abilities here and there won't really effect the overall balance.  They'd have to be balanced, yes, but such abilities would never, and should never, appear on the base triangle structure.  The core triangle is the point from which all other units are compared.  Add in abilities only makes the unit generation algorithm slightly more complicated, but doesn't effect the inherent balancing factors of the unit stats.

I am trying to make something to build from, and while I'll revisit to insure that it's still working as desired, I need a core foundation that's solid first.

[Akhier the Dragon hearted]

   It is always good to try yourself before going to others.
If you become to dependent of others for help then what
would you do if you lost contact with them?

[Draco18s]

   It is always good to try yourself before going to others.
If you become to dependent of others for help then what
would you do if you lost contact with them?

No kidding.  I lost the access to my Flash professor when I graduated.  It kinda hurt.

[Antsan]

I know, you abandoned the genetical approach, but I would like to offer one idea in that direction.

Your main problem is not assigning stats but balancing costs in a way that a tictactoe game emerges. So when applying a genetic algorithm you wouldn't wanna do that to the stats but to the costs.
Just take the algorithm you are using now for ordering the ships and finding a triangle - if I understood right you first find candidates by beating the last winner and then pit these candidates against each other to find out whether they make a triangle.
You can leave that in place (although it might be better to refine it, but I'm not talking about that). Now randomly generate lower and upper bounds for your stats and maybe you could even get your RNG's be randomly generated. I'm not sure how hard this is in the language you are using (I'm only dabbling in Lisp and Qi and it seems easy there). Write some genome object for those and rate them for how close they got to actually generating a triangle and evolve your rule system instead of the actors in that system.

On the other hand that might be a big change, don't know about that and I have been awake for roughly 24 hours, so...

But as you're changing those values either way all the time by hand...

[Draco18s]

Now randomly generate lower and upper bounds for your stats and maybe you could even get your RNG's be randomly generated.

One does not simply randomly generate a random number generator.
Nor would randomly generating the upper and lower bounds of the stats actually help, as they come in ratios.  "Three of this is one of that, but this maxes twice as high as that," etc.

I'm not sure how hard this is in the language you are using (I'm only dabbling in Lisp and Qi and it seems easy there).

Flash AS3.  As exhibited by the compiled executable type.
(And your not the only person to realize this)

Write some genome object for those and rate them for how close they got to actually generating a triangle and evolve your rule system instead of the actors in that system.

"How close to a triangle?"  That requires running 3 tests and determining the direction of outcome for each, as well as the relative win strength for each fight.
And then trying to figure out what that means in terms of altering one or more units.  Not to mention that the genome "code" itself referred to the random numbers, which while robust, didn't work well, as there was not enough mutation happening.

But as you're changing those values either way all the time by hand...

They're not being changed by hand.  I don't know what this means.

[Antsan]

Come on, I didn't want to disrupt your programming or thought process. Just wanted to contribute my train of thought, sorry if I upset you in some way. If this is too disruptive for you, ignore what's following.

One does not simply randomly generate a random number generator.

Yes, you cannot *simply* write a customized random number generator, at least when you are not having function objects, clozures and the like. But well, you can just write a function like (sorry for the Lispy syntax, I guess you will be able to interpret it)
(custom-rng min max list-of-polynome-coefficients)
that rolls a random float between 0 and one and maps it via a polynome (or some other type of function, which might be better suited for example for being monotonously growing) to values between min and max. In Lisp I wouldn't do this with a list but with function objects, which, I guess, you don't have in Flash. If you have them, use them!

Nor would randomly generating the upper and lower bounds of the stats actually help, as they come in ratios.  "Three of this is one of that, but this maxes twice as high as that," etc.

Ratios are also just values. You can choose them by hand, generate them randomly or evolve them. I don't see the problem, given that the computation I propose would be a one time thing as long as you don't change game mechanics (including AI, for that matter).

"How close to a triangle?"  That requires running 3 tests and determining the direction of outcome for each, as well as the relative win strength for each fight.
And then trying to figure out what that means in terms of altering one or more units.  Not to mention that the genome "code" itself referred to the random numbers, which while robust, didn't work well, as there was not enough mutation happening.

No, you misunderstood me, the rng should be constructed in a way that smoothly influences standard distribution and expected value. Those are the importand parameters, besides the maximum and minimum values, as described above. And crossing polynomials should give a fluent transition - that's all that counts!
"How close to a triangle?" is indeed a tough question, but when you answered it once you run the algorithm once for a while and then you have your parameters for ever and ever and ever, until you change some other rules. How much mutation is happening is just up to you. When you answered the question how to measure tictactoeness it's only the question of choosing the right population size and mutation and crossover rates. (Heck, you could even evolve those based on average improvement between generations, but I guess this is far out of the scope of your project.)

They're not being changed by hand.  I don't know what this means.

As I understood a good chunk of this thread (sorry if I misunderstood, I am really awake for too long) you have problems finding boundaries and distributions for reasonable stats - you adjusted the rng for range iirc a few times and spend quite a while adjusting mapping between primary and derived attributes further. Either you do this by hand or you let a algorithm do this. You did (as I understand) the first, I propose the second.

[Draco18s]

One does not simply randomly generate a random number generator.

Yes, you cannot *simply* write a customized random number generator, at least when you are not having function objects, clozures and the like. But well, you can just write a function like (sorry for the Lispy syntax, I guess you will be able to interpret it)
(custom-rng min max list-of-polynome-coefficients)
that rolls a random float between 0 and one and maps it via a polynome (or some other type of function, which might be better suited for example for being monotonously growing) to values between min and max.

But why?  What would be the point?

Nor would randomly generating the upper and lower bounds of the stats actually help, as they come in ratios.  "Three of this is one of that, but this maxes twice as high as that," etc.

Ratios are also just values. You can choose them by hand, generate them randomly or evolve them. I don't see the problem, given that the computation I propose would be a one time thing as long as you don't change game mechanics (including AI, for that matter).

I cannot simply let the program decide that 10 hitpoints is worth the same as 5 damage or 30 hit points is 3 damage or (god forbid!) that 5 hitpoints is worth 15 damage!  It doesn't work that way.

"How close to a triangle?"  That requires running 3 tests and determining the direction of outcome for each, as well as the relative win strength for each fight.
And then trying to figure out what that means in terms of altering one or more units.  Not to mention that the genome "code" itself referred to the random numbers, which while robust, didn't work well, as there was not enough mutation happening.

No, you misunderstood me, the rng should be constructed in a way that smoothly influences standard distribution and expected value.

There is no "expected value." :|

"How close to a triangle?" is indeed a tough question, but when you answered it once you run the algorithm once for a while and then you have your parameters for ever and ever and ever, until you change some other rules.

This.  Is.  Gibberish.  Please make more sense after you sleep.

How much mutation is happening is just up to you. When you answered the question how to measure tictactoeness it's only the question of choosing the right population size and mutation and crossover rates. (Heck, you could even evolve those based on average improvement between generations, but I guess this is far out of the scope of your project.)

TOO far out of scope.  I'm not dealing with populations in the dozens, I'm dealing with 10-12 individuals whos "lives" make up more than 90% of the operational cycles of the program.  I need fewer cycles not more.

They're not being changed by hand.  I don't know what this means.

As I understood a good chunk of this thread (sorry if I misunderstood, I am really awake for too long) you have problems finding boundaries and distributions for reasonable stats - you adjusted the rng for range iirc a few times and spend quite a while adjusting mapping between primary and derived attributes further. Either you do this by hand or you let a algorithm do this. You did (as I understand) the first, I propose the second.

I've been fixing the ratios/min/max etc. of the algorithm, because it is trivially easy to let some value exceed a threshold where upon the unit is unbeatable.  This is why a random RNG is not a good idea.  I am not even going to explain why two levels of random is a god-awful idea (mainly because it makes it Fcking Impossible with a capital F and I to debug).

Edit:

I just realized that you want me to write a RANDOMly generated RANDOM number generator that generates the ratios that are then used by another application of the RRNG.

That is:

1) RANDOMly generate a RNG
2) use the RRNG to generate stat ratios
3) use the RRNG to generate stats based on those ratios.

In other words:
A triple buffer of randomness between me, the programmer, and the output.

Not just one, like I have, but three.