Help wanted: Source Keepers overhaul
-
SKs could move on a straight line towards the source, through any terrain, with no path finding, but still subject to collision with other creeps, which would be targeted. Optionally, they could try to go around creeps by picking an adjacent direction, if that is not blocked. Lairs that would cause SKs to move through walls that are not adjacent to walkable tiles could be moved to satisfy the criterion of exposing them to melee attacks at all times.
-
Just wanted to add a reminder about that this concerns minerals too. And that those minerals have an extractor which may or may not effect things.
-
@eduter "Straight line" could be generated differently depending on the algo, there's no guarantee that every step will be exposed. And we'd like to move as less lairs as possible.
-
@kasami Exactly, minerals are treated as sources in this case.
-
A simple getDirectionTo() could eliminate the need of path finding.
SK's currently are blocked by player creeps anyway, they will hammer on the thing that's in the way.
-
@dissi Simple
getDirectionTowouldn't meet this requirement:Every wall tile should have at least one adjacent plain tile (in order for the creep to be exposed to player melee attackers at any given moment).
SK's currently are blocked by player creeps anyway, they will hammer on the thing that's in the way.
What do you mean blocked? Currently they can redo pathfinding if they are blocked, i.e. it's dynamic (with
reusePath:50), isn't it?
-
@artch said in Help wanted: Source Keepers overhaul:
What do you mean blocked? Currently they can redo pathfinding if they are blocked, i.e. it's dynamic (with reusePath:50), isn't it?
Yes, basically it means they'll probably be stuck for 50 ticks, and recalculate the path.
@artch said in Help wanted: Source Keepers overhaul:
Every wall tile should have at least one adjacent plain tile (in order for the creep to be exposed to player melee attackers at any given moment).
If we want to keep it as simple as possible it might be better to only do a getDirectionTo and move that way. And yes, if we want to have the move over the wall requirement it wil require additional logic and getDirectionTo will not suffice.
-
@dissi So we have to decide do we want to always keep them exposed, or some periods of inaccessibility (and thus invulnerability to melee attacks and no valid path with
range:1) is fine. We also should consider that these periods may be very long in case if someMOVEparts are dead.
-
@artch It seems to me like you will have to pick 2 out of these 3:
- keep SKs exposed to melee attacks at all times
- make SKs' movement as simple as possible
- keep lairs where they are
-
@eduter Exactly. Very interested in community opinion on what's more important.
-
@artch Mind sharing what exactly you think the issue with moving the Pathfinding to the processor is? I'm still fiddling with the server code to understand how exactly NPCs are integrated into the flow of the game, but calling the pathfinder differently seems like a fairly small issue to me, so maybe I'm missing something here.
Also what exactly is the overhead here? Is it the creation of the
vmfor each SourceKeeper or the setup of the API wrapper usercode has? Is it an option to just remove thevmlayer for NPCs?
-
@postcrafter Runtime overhead is created not only by
vmmodule itself, but by many other factors: working with inter-cluster user execution queues, fetching database queries, managing separate runtime processes with their own timers, etc.Adding full path finding (i.e. feeding full room grid to real A*) to processors is inappropriate since processors are meant to be very fast, and a single heavy path finding call could be longer than an entire room processing cycle. Also,
@screeps/pathfindinglibrary has some overhead like initializing heaps, and doing that in processors is no good. Better to make something simple instead.
-
I think it should be possible to keep the SK movement very simple (local greedy search). That means an SK might get stuck in a loop and never make it to the Source or Mineral, but it should be rare so it won't ruin the fun. It might even enhance the fun with crazy techniques to send SKs on wild paths.
This would keep the SK vulnerable to attack (same movement restrictions as any other creep they can't move onto walls, etc). The movement code is dead simple
move in dir of src, if blocked by wall, move diagonally to src, if diagonal blocked by wall then move random. The same brain dead code can be used to pursue player creeps if we want to allow that. SK lairs don't need to change and could be consolidated in the future with no changes.All this assumes that the processor does some intent validation. E.g. I believe it is the processor that decides which creep win when two creeps try to move onto the same square during a tick.
I think targeting creeps might be a harder problem. I believe the LOOK and FIND indexes won't be available in the processor. How will the creep discover which creeps are in the room with it? Without the LOOK indexes it might be very expensive to loop over all creeps in the room checking for range.
-
@deft-code Making LOOK and FIND indexes requires looping through objects as well, so there's no difference, either NPC processor or runner should do that anyway.
We're now debating whether it's viable to leave their movement by plain land as usual, but without dynamic path finding. I.e. the path is calculated once and then reused, and if the keeper is blocked, it will stuck until it kills the blocking creep or die.
-
@eduter said in Help wanted: Source Keepers overhaul:
@artch It seems to me like you will have to pick 2 out of these 3:
- keep SKs exposed to melee attacks at all times
- make SKs' movement as simple as possible
- keep lairs where they are
I would take the first two options and move some lairs:
- keep SKs exposed to melee attacks at all times
- make SKs' movement as simple as possible
A vast majority of players will not even notice if some lairs are relocated.
-
OK, the task specification has been changed. Let's settle on this:
leave their movement by plain land as usual, but without dynamic path finding. I.e. the path is calculated once and then reused, and if the keeper is blocked, it will stuck until it kills the blocking creep or die.
The first post is updated.
-
@artch said in Help wanted: Source Keepers overhaul:
leave their movement by plain land as usual, but without dynamic path finding. I.e. the path is calculated once and then reused, and if the keeper is blocked, it will stuck until it kills the blocking creep or die
This makes the logic a lot easier to implement. I also thinks this looks a lot like the current implementation.
-
@artch said in Help wanted: Source Keepers overhaul:
OK, the task specification has been changed. Let's settle on this:
leave their movement by plain land as usual, but without dynamic path finding. I.e. the path is calculated once and then reused, and if the keeper is blocked, it will stuck until it kills the blocking creep or die.
The first post is updated.
Is there any test data provided for this task or do we have to generate our own?
Or is there any information about how sources and source keeper lairs are generated in SK rooms?
-
I've started working on this, progress can be viewed in the pull request on the engine and driver. I plan on cleaning up some of the code and cache the paths properly before marking it as ready to merge in.
The source keepers should already act like they would normally do, but I can't confirm as I lack source keeper harvesting code, therefore I appreciate any feedback on this.
If anyone wants to test the changes, feel free to check out the
source-keeper-to-processorbranch on my screeps-server-dev repo which will help with setting up a server quickly.
-
Dang, I didn't realize that your PRs had been out for a month, @PostCrafter. @artch any idea of when this will be tested/merged?
