I’m currently creating an infinite runner game. At the moment I’m creating it as a campaign, where each level is hand built and the player moves from level to level / level select screen etc.
However, I aim to create an endless mode for replayability.
I know the usual method of infinite runner games the world moves and the character does not, but for this game, I need the character to actually move, since they are being chased - and can be slowed down and caught.
I am using a straight line track, so there is no worry of twists and turns. the game is being made for children, so I’m keeping it as simple as possible.
How can I create a procedurally generated track with the collectibles and obstacles also being procedurally generated on to the track?
The fastest way to do it would be to pre-create hundreds of various track sections as a blueprint and use a class to spawn these random sections into the world.
The Proper Fix:
Other wise unfortunately what you are asking for is not a straight forward answer, but it can be done. The good news is your parameters for this make things easy (easier):
What I would do:
You are going in a straight line, which means you really only have to worry about your progression along one axis, we’ll say Y as the “forward” axis. X is left and right, while Z is jumping. which means once you move along the Y axis by a certain amount you can spawn the next section. Then you can build a blueprint for a track with exposed variables for tweaking the rewards and difficulty. It would utilize a spawning volume or volumes that randomly generates random coordinates within the volumn and on the track to spawn the obstacles and collectibles randomly. You’ll have to track what is spawned when generating the new track so things don’t overlap improperly. Probably need to spawn obstacles first then collectibles and check if an obstacle is present.
The creation of the spawning volumn(s) would be similar to what is done in the UE4 C++ tutorials.
It may be efficient to “spawn” using another thread if possible (haven’t looked much into UE4 multi-threading but I’m pretty sure it exists). Also garbage collection; if you are building an infinite level eventually you will have 100 miles of stuff behind you. If your game does not go backwards make sure you remove anything behind you, other wise you’ll have to use some occlusion volumes (think that’s what they are called) to stop the engine from working on things that are not visible… UE4 may handle this automatically be be mindful of it if you find your game slowing down.
One very important thing to remember, I believe UE4 does infact have a maximum world size… so if you keep running forever in the Y direction you may find your self hitting the end of the virtual space… not sure how big it is but it is pretty big.
I know the usual method of infinite runner games the world moves and the character does not, but for this game, I need the character to actually move, since they are being chased - and can be slowed down and caught.
Actually… the magic of vectors can be used to solve this problem too… and will probably benefit you more in the long run to use the traditional method especially if you are making an infinite level.
Lets say you have a player and a monster who is chasing the player. Basically your player has a vector position which would always be p = <0,0,0> your “monster” chasing you would have it’s position OFFSET from you m = <0, -100, 0>. Both you and the monster have a “forward” velocity, but it’s really just virtual. Both the player and the monster have a default forward velocity of vp = vm = <0, 5, 0>. Each tick you recalculate the offset between you and the monster by subtracting vm - vp and adding the difference to the offset of the monster. If the player slows down the monster gains on them. If the monster slows down the player gains on him.
Thank you for the reply - I’ll admit it has gone over my head a little, since I’m not a coder and blueprints are my first real foray in to visual scripting.
I understand the logic and theory, just not the steps to implement.
Regarding the movement of the player vs movement of the world, I have a system similar to Sonic, in which the player hitting an obstacle launches them backwards and losing their pickups - and being able to re-attempt the jump.
I’d rather not switch to the world movement system, if possible, since it would be a complete redo of most of my work (which has been several months)
I imagine the issues with world size could be handled with World Browser/Compositor - allowing the world to loop ?
Ah for some reason I thought you said you prefer C++… but can’t find that reference now. You can build the entire thing using the blueprint system, but I suggest watching the C++ tutorials just to get an idea about how spawning volumes would work and also looking at the Blueprint tutorials (if you have not done so already). It should only take your about a day or two going over each.
Hopefully I answered a bit of the question of how to procedural do it. You’ll most likely be working in combination with a level blueprint and a Track section blueprint. The Track section blueprint will take care of what to spawn while the level blueprint will take care of where to spawn the track section blueprint. You can even create a Track Manager blueprint to manage the entire length of the track, removing sections and adding new sections as the player runs.
Thanks for the reply - I think I’ve decided on my method. Since I’ve built 90% of the core gameplay, I don’t want to recreate everything to suit an infinite mode.
I’m fairly advanced with blueprints, though this is my first project - the game is almost complete except for a few animations missing and more levels required.
I’ve decided to have a set track length and purely just generate the obstacles and pick-ups instead - and still have the player be moving instead of the environment.