1. #1

    Randomly Generating track

    This is more of a question for the people from Ubisoft or maybe even RedLynx or even just someone who knows how to work the game logic behind this. So, suppose I wanted to make a randomly generating track, for the example sake I'll keep it simple. If I was to use an object array with 2 ramps, one up and one down. Is there a consistent way I can make the logic flow to keep say a limit of three up ramps or down ramps in a row from happening? Furthermore, is there a simple, or just a clear way, that I can randomly determine the distance between one ramp and another? Thanks to the community for all your support on my Trials Fusion tracks. Hope to be making Trials Rising tracks with my friend soon. (Possible extreme/ninja tandem tracks could be happening soon from us.)
    Share this post

  2. #2
    Yes this is possible. If you look at my thread from the other day, I am doing something similar (https://forums.ubi.com/showthread.ph...o-aggressively). My approach is to build each track component in a glue group, and position the group's pivot point at the start point of the obstacle, and include a dummy object in the glue group at the end. Then I keep two object arrays. One of them stores the glue groups themselves and the other stores the dummy object end point. Then I select a random obstacle and position it at the position of the end point of the first obstacle.

    Additional logic to constrain the generation could be achieved reasonably easily. You just need a way to discern between types of obstacles, either by storing them in separate object arrays, or putting them in separate ranges of indices in the array. Then you can keep a counter for each obstacle type and increment it when that type is chosen and reset when a different type is chosen.

    Determining distances between objects can be done by attaching a vector object info to the objects in question and using a vector operator to subtract one from the other.
    Share this post

  3. #3
    Suppose then that the logic went like this
    Up ramps -> 1st object array
    Down ramps -> 2nd object array
    Vertical ramps -> 3rd object array
    Horizontal ramps -> 4th object array
    Round objects -> 5th object array
    Would it be reasonable to create a system of filters (such detecting if a random number generator is equal to the number of the array) to first determine the type of obstacle, which would be followed by determining the actual ramp used? Furthermore, is it possible to change the rotation of an obstacle (stored in its appropriate array) then get that same obstacle with the newly changed rotation? Lastly, would it be possible to create a system, with reason of the complexity that the game allows, that attaches each newly generated track piece to a previously generated piece with a perfect connection, meaning no little bumps or dips while going over it? BTW, thanks for the answer mrjorts, I will mention you in my track, if I make it, with your approval of course.
    Share this post

  4. #4
    Yes that is reasonable. Having thought about it some, I think that using separate arrays might complicate it a bit. Since each object is treated the same way regardless of what type of obstacle it is, you'd ideally like to use the same scripting, so by putting them in one array with the different obstacle types stored in contiguous indices (eg up ramps in in indices 0-9, down ramps 10-19, etc) you don't have to duplicate any of the logic that refers to and manipulates those objects, just calculate a different index and the same scripting can be reused. Then you could choose a random obstacle type, and a random obstacle index, and if you had five different obstacle types each with 10 obstacles, you could calculate the desired index as random_obstacle_type * 10 + random_obstacle_number.

    I recorded a video walkthrough of my process for making my track since it's a bit easier to explain than in a forum post.Sorry if I spend too much time explaining basic stuff. I wanted to make sure I didn't gloss over anything, but it wound up being pretty long. Hopefully should clarify some of the scripting ideas.

    Share this post

  5. #5
    Okay, thank mrjorts. I will definitely give you credit for that. Lastly, hopefully not giving too much of my track idea away, using a similar technique, would it be possible to generate (using obstacles) some sort of terrain in the background? Using the same basic principle, or something of that sort?
    Share this post