Clarification on targetting

Clarification on targetting
0

#1

Hello, I’m currently writing my action phase simulator and have a question regarding the following rule:
5. Choose the target closest to an edge
Does “closest” mean the targets needs the least steps towards its edge or does it mean “closest” as in the (euclidean) distance from that position to the edge is minimal?
I’m guessing its the later, but some confirmation would be neat (the former is easier to implement and I wouldnt be surprised if thats how you actually handled it).


#2

Hello and good luck on the simulator!

  1. Choose the target(s) which are the furthest into/towards your side of the arena

  2. Choose the target closest to an edge

So you first check for best Y, and then for best X, not the “path” to edge.

For questions like this , it is best first to TEST them in the Playground, then generate a proper replay and test your Sim on it:


#3

Here is a case which illustrates my problem (imagine the two encryptors are enemy information units):

So you say in this case, the destructor will always attack the unit on the left?
Edit: I managed to replicate exactly the case in this image and its the unit on the left that gets attacked.

And yes, I know I should probably just test this in the playground, but I’m not quite confident in things I see in it, because of the visual bug I posted about a few days ago, so I thought it to be easier to just ask ^^’.


#4

if they are the same type and health, yes.
And again, don’t believe me, but make a proper test, and make sure it works as expected.
Not well tested simulator will get you in a world of pain :slight_smile:

You can check the code in the starter algo GameState.get_target()
https://github.com/correlation-one/C1GamesStarterKit/blob/master/python-algo/gamelib/game_state.py#L531
for all the rules and checks


#5

Maybe this thread can help.


#6

I’d like to second Demorf’s original comment that the only reliable way to make a correct simulator is to be able to run actual replay files through it and have your simulator confirm the same outputs!


#7

I think in the next few days I’ll start gathering a lot of critical gamestates (already started with that) where specific errors in your simulator code can be revealed by resulting in a different gamestate than the one given by the devs.
I was planing to then upload a list of all of these gamestates, so others can test their simulators on them… Would you guys be interested in that?
What would you want the format to look like? Since a lot of people probably wrote their own replay parser, a replay file which leads to these critical gamestates would be sufficient I think, but maybe something simpler would also be nice?


#8

I was doing something similar for my path finding tests:
Use the debug mode (or manually) create a “stage”, with only one possible move:

  • spawn one ping, on a fixed location and see if it scores (and not get killed).

you can then update each turn, for similar situation, and end up with a replay of 5-10 turns, that test most of the path finding at least