your biggest hurdle will actually be “how do I get the destinations” everything else is just plugging values.
there are 2 major methods to get destinations for a teleport of not either: know of them ahead of time, or resolve them right as you are about to use them. for each of these there is a big variety of methods to accomplish them. it is up to you to figure out what is easiest to implement, and fits your needs (these might not always be the same)
I will be considering your world as a 2D grid of GridSpace like a chessboard (if you are doing something more complex then the difference will mostly be the math) The following is not exhaustive, and some of them might be overkill for your plans.
you can pepper your level with actors that define a gridSpace, and then at beginPlay all of these gridSpaces check for the adjacency with like a Multi-SphereTrace by using a tiny bit more then the size of a gridSpace to determine what is adjacent (it is up to you on what to do with diagonals, multiply the linier size of a GridSpace by Sqrt(2) will give you diagonals), and then the GridSpace holds whether there is already an Entity in it, for when they are quarried for which to go to.
- the gridSpace could be a SceneComponent, then you can set up the adjacency in advance, but this falls down when you need to go from one containing actor to another, and you might end up just moving the BeginPlay() logic into the ConstructionScript()
you can use Navigations System (NavMesh) to Quarry for the path, but you would need to setup the distances for PathTargets, and you would take the NextPathNode (I think in you do enough fiddling the NextPathNode will 99% of the time be your teleport target),
- Otherwise you can get the Vector from the Entities current location to the Point->Normalize it, and then do a DotProduct with either X-Vector, or Y-Vector to determine Diagonal (multiples on 90 degrees, or Pi/2 ~ 1.57) with
modulus division != 0 meaning not 90%
- if you use the NavigationSystem you are married at the very least to AAIController without some C++ hackery.
you can have the Entity determine the direction to the player, and shoot out 4 (8 if you want diagonals) LineTraces (a capsule Trace Single will be the most telling presuming you have flat ground) by taking the Entities Location, and manipulating the coordinates to find the EndPoints, around them and if the lines hit something then the direction is blocked otherwise figure out which one you want them to move to, and use the EndPoint of one of the Traces as your destination.
- this might end up be a struct with a Vector, and a bool rather then just the Vector that way you can cache the Destination point, and whether or not it is blocked.
- this approach might be the best suited for multiple moves in a straight line, where you can continue incrementing the trace until it hits something or some arbitrary max checks, and then use the last value for the “successful”
- the hardest part here is figuring out which point to use and gets into a big circular logic question of “am I just recreating Pathfinding
A*”
if you use timers/Delays liberally then you might be able to cut BehaviorTree, and maybe ever Controller’s out of your entities.
- If you go full turn based then you would just end up having a ManagerActor (or subsystem if you are willing to use C++) that gets told somehow when the Entities’ “turn” is happened, and just go through all the Entities for them to figure out their turn action.
Game dev is hard not because any given thing is “hard”, but that for every sometimes inconsequential decision there are 20-30 downstream decisions that fall right in your lap; you can look up “game development door problem” for a demonstration (sometimes it goes by “stairs problem”, or “ladder problem”) it sounds easy, and the individual thing is not super complex, but it is all the moving pieces; we end up Building the train tracks, the train, and the destination all at once and we call it a “game”. Just don’t get distracted by this cool thing you saw in some other game, or someone asked you to add, finish what you have planned then figure out if you even should add it, otherwise you might end up like Duke Nukem Forever (14 years later, and not even finished when it was released)
every project has its complexities, just break it down into smaller chunks, yes that 1 thing is now 20-30, but they are 30 smaller things that should be a lot more manageable.
