Moving between rooms
-
First post. Long time player with a huge pause in playtime... I figure I'd post a tiny bit of my own solution for one of the toughest problems newbies face... moving between rooms. A cursory check of the boards did not seem to cover this stumbling block.
pseudocode -
if (!NEXTROOM || x/y === 49 || x/y === 0){ return moveTo(new RoomPosition(25,25,NEXTROOM, {range: 10}); }
I use this before (most) other AI code is run to help move blindly into a room and to avoid that weird door switching thing.
It removes the bot from the exit, where the room scanning and movement gets messed up, or where saved paths no longer line up correctly.
The arbitrary range of 10 accounts for moving into any configuration of walls within a room. There is always an plain or swamp at range 10 (for now).
Once you get to the next room and are clear of the doorway... use your normal movement tricks.
-
thanks for the code! I've noticed that weird ping pong teleporting between rooms. Is that just a display bug or is the creep literally flicking through rooms ? I've noticed it messes with builders and fixers when walls and roads are close to the edge. Does this interrupt creeps actions. i.e. do they just get stuck?
-
@maddokmike It does actually ping-pong the creep. It depends on code logic, but it sees one room and makes a decision, then it acts on the decision next tick, but it is in the wrong room... probably many procedural variants to it. The exits auto-teleport, so if you don't step off of it, you get nowhere.
The bots getting sucked out of a room may be due to using moveTo. I typically use PathFinder directly and put a little effort into building a CostMatrix for the room, which I store in memory and update whenever a structure goes up or comes down. I've noticed it stops my bots from wandering next door for no good reason and really improves the pathfinding.
Also, I'm not perfect and my rapid development creep AI option uses moveTo until I circle back for optimizations.
-
by a costMatrix, do you mean defined paths/roads that the creeps should follow instead of recalculating every 5 ticks with moveTo ?
-
costMatrix is all 2500 'spaces' having a numeric value representing movement cost. The API docs have sample code that will even visualize an overlay to help tweak it. It is an array of arrays (a matrice) with the movement cost as the value. The API example only looks at terrain.
It is expensive to calculate, so consider storing it in memory and updating when the map changes (count structures every tick, also stored in memory - as an example of saving overhead when nothing changes).
You can 'lie' about values such as future paths, construction plans, mark exits with a higher than natural value to keep creeps out, mark with a +1 if not inside your base, etc. It's your matrix.
Once CM is stored in the rooms properties, other funcs could make temp overlays of where bots are, zones around enemies, etc. Don't save temp overlays.
-
ooh ok. just looked it up. So the idea being, you would mark your roads low and areas you don't want creeps going into, really high, so they try to avoid them ?
-
@maddokmike The rule of thumb is to keep your values low... I've heard 1 for plains and 5 for swamps, but if you add roads.... you can only use integers... I do roads =1 , plains=2, swamps=10, blockages(walls, non-walkable structures)=255
255 is 'magical' and skipped by the PathFinder class.
I tweak other stuff as my 'special sauce', but you get the idea.
-
The advice for beginners is to keep your cost values low.
For advanced pathing anything "works". For efficiency you should set your heuristicWeight to at least the minimum tile weight. The default heruristic of 1.2 is assuming roads 1, plains 2. But heuristic 6, road 5, plain 10, swamp 50, is just as efficient and returns the same path. The low values problem is because PathFinder caps the heuristic at 9 so heuristic 24, road 20, plain 40, swamp 200, should be just as efficient but it costs more.
