UDK - Player detect change of direction on land (Endless Runner)
I am trying to make an endless runner with a system which keeps adding one of the 4 types of earth on the front of the level making it randomly generated, however I have parts where the player will go up and down. How Will I make the player go up when the land is going up and left when it's going left for example? Thanks in advance 
Replies
If they need to jump, build in a jump control to your player input.
Same for turning.
Your individual bits of level should be blueprints, not just static meshes. So you can have collision objects that trigger a crash/damage whatever, as well as the normal collision that keeps the player from falling through things.
You mean InterpActors? Cause I am using UDK, not UE4.
Thank you very much for the help
So no not InterpActors, but a custom actor class for "level block" or something would be best since each block will probably want to have more data associated with it than just direction and static mesh. You might be able to set this up with Kismet, but you're probably going to have to get into Unreal Script.
In most endless runners the track places turns on its own and the player has to adapt to that. So your track building algorithm needs to occasionally put down a turn block, then just continue in that direction. This should be pretty simple if you lock your turns to 90 degrees.
Your track builder will at some point place a turn, then when that block happens, the builder needs to know the new track direction and build off of that till the next turn. Also you may want to have some heuristic built in so that no more than 2 turns of the same direction can be placed in a row to mitigate the possibility of the track running into itself. Also you'll want to generate sections well ahead of the current player's position. Now, if you decide to include a T junction you'll want to generate some amount of track to both sides, then continue placing after the player turns.
Now, depending on your design for this, if you don't need to look behind, ever, or fly through the level generated later, you can simplify a bit by turning the world rather than the player, and deleting blocks after they're no longer relevant to the player.
I suppose a good question to ask at this point is: How far along are you on this project, and what kind of experience do you have in actually building data structures and game systems?
If you're really new, you may want to start more simply than a procedural endless runner.
Once again thanks a lot for the help.
I am making a final project for university. I have no experience prior to this other than making a flash game! :P. I know, I am feeling to hopefull,
but at the same time I am trying to get as much help as I can from all possible forums.
If you can give me some advice on more stuff regarding it, I would be very thankful.
Which is best then, move the player in the world or the world in the player? Also do you have any suggestion on how do I add things like the monster positions and other stuff to each of the terrain bits?
Just remember that you'll need to learn how the engine works, how to express what you want in it, then actually build the thing and test it. That's a lot of effort on its own.
That said you can still make something cool, break your game way down. Down to its absolute basics, and build that.
Sometimes the basics are hard to see, and you really want some features, but really, they're almost all set dressing.
So for a temple run style endless runner you need moving pieces of track, 3 "lanes" a player can be in, and the ability to jump over gaps. That's the core of the game. Build that, then add complexity.
Look at "subway surfer", the track never actually turns.
[ame]
So for now, forget about making a turning player, forget about monsters and multiple levels of track, just make a player controlled object that can move into one of 3 lanes and jump. (just start with a sphere or some other primitive)
You'll probably want a custom playerController and a custom gametype that implements that controller, but you'd need that no matter how simple or complex your game was unless you were building an FPS, since that's what UDK Ships with.
That's part one. Get your game to the point where a level loads, the camera points at a primitive that the player has control over, that can move into any one of 3 positions sideways and can jump.
For your eventual levels I'm going to suggest sending blocks to the player while keeping the player near the zero point of the world(essentially world around the player), because it keeps things simpler in the long run.
You'll need to figure out how to spawn something at regular intervals with a velocity headed toward the player. That something should just be big slabs with simple box collision for now.
They'll also need to be deleted after they're no longer relevant, like after they're fully behind the camera. How you wish to do that is up to you.
This will be the basis of your level generator.
You may also wish to add in a collision plane below the player that will cause a game restart or other loss condition.
Anyhow, good luck, and keep it small. Hopefully a tighter focus and some web tutorials will get you through this semester, then you can improve it from there.
Also, I HIGHLY recommend that you switch up to Unreal Engine 4 if your computer will handle it, and your program will allow it. There's a free pack for students here https://education.github.com/pack and its a lot more user friendly than UDK IMO.
Once again thank you very, very much. I will do my best.
Unfortunelly I am not allowed to use UE4, so I have to use UDK. Let's see how it goes!