How I created another infinite road generation method for my drifting game: Drifto. Built with Unity 2019. App Store: apps.apple.com/app/drifto/id1... Play Store: play.google.com/store/apps/de...
if you continue with this tile approach, you should look into wave collapse functions. Additionally, since you're surrounded all sides, you can overlap as long as the player cant see the old pieces from the side
The wave function collapse is a really good idea. Allowing overlap with the old sections when creating new that are not yet in view would give the path a little more freedom but I'm unsure on whether the performance hit and development time is worth the slightly more random road. - Is that what you were thinking?
@@jonathonhowe if you’ve not already multithreading this code even just by using async await not nessesarily even learning the job system would be a massive improvement to performance.
@@jonathonhowe WFC can be really memory and performance intensive and worst of all it can just straight up fail to generate a valid combination which either requires running it multiple times or flat out becomes an impossible task for it (depending on your input pattern - doesn't take much to make it fall over); IMO - WFC is at its best and most powerful when it is used as a tool at creation time / editor time to help you handcraft levels. Disregarding the negatives; given you never see the entire output all at once (such as an image, etc) I doubt there'd too much of a benefit over just using what you have already.
@@scyan897 I doubt async/await will improve performance in this case. They can improve performance if your thread is mainly idling, waiting for blocking operations such as reading a file or networking. You can continue using the thread even thi something is blocking by doing something else in the meantime. They're not useful if your thread is slow because it's working, as is the case in the game, since async/await is still fundamentally single threaded. It just uses the thread better by doing something else until a blocking operation is done. And if you want to introduce blocking operations that can yield control until they're done, you're already working with jobs & threads.
I love your game so much😭thankyou for making it so easy to use and free!!! I already beat the game and have more money than I know what to do with. Please add more stuff that I can buy! I notice you’re always adding little changes and upgrades so THANKYOU!!! Please keep it up it’s one of my favorite arcade-style games
Yes that's a good point, I'm not worried about that right now as the world slowly shrinks to increase difficultly, stopping the player from getting that far.
@@gopro2027 to be fair this floating point issue with things far away from the origin does cause a lot of problems even for professional-made, professionally relied-upon software
I mean I'm sure it is an issue but since minecraft is so popular the farlands have made it seem like a much greater issue than it really is. That bug won't even be encountered during a typical minecraft playthrough, that's why it wasn't fixed.
this is awesome. In the future, it would be awesome to have procedurally generated seamless elevation changes, and variation in environment. Like after driving for a couple minutes through a flatter city you'd end up in a hilly wooded area.
Hi, Just discovered your channel. This devlog is brilliant and I think Drifto is a wonderful game. Infinite drifting with track being generated in real time is really cool and you've implemented it very nicely. Here's a suggestion for the algorithm that checks whether a piece is valid, which is related to cycle detection in graphs. A piece can only be invalid if it creates an enclosed part of the map, i.e a bunch of tiles surrounded by road. So first check if the piece has any other neighboring pieces (Except for the piece it is connected to), otherwise it's guaranteed to be valid. Now to check if the piece you want to put is invalid, look at the position of the next piece you've added and check it it is inside the enclosed space between the previous piece and the piece it is touching using raycasting.
I feel like avoiding self intersection is sort of a missed opportunity for unique and interesting gameplay. Since driving a "self intersecting" track could only be possible in a scenario like this one, where the track is generated in front of the player (and deleted as they leave it behind).
I think it would be quite fun for intersections to be based on the initial tile and simply have a different path built through, over or under it; which could have an "under construction" vibe, seeming like the new road was built while the player looped back to the intersection
If you get rid of the grid, you can still align pieces together with an entry and exit point. Just keep the position and angle of them in each tiles. It will make the collision checks harder as you will want to check if the outer edges of the tiles overlapse. But it's not crazy to do at all. And since you don't need to connect back to previous pieces, it's fine if you loose the alignment to the grid. It will allow for any shape, and you could maybe do a stretching system for your tiles to curve them randomly
You should make it where you gain/lose points depending on if the car properly stayed on the road(meaning never went on sidewalk or grass) They vice versa you gain points by actually staying on the road. Keep in mind I have no clue what your direction for this is but i think this could at least be a fun/challenging gamemode
Funny you suggest that. Just a couple of days ago I started implementing a system so the cars behave differently on different surfaces, including earning different amounts of points for each surface type. I like the idea of extending this to a bonus for never going off the road. Thank you!
i just got this game and i'm addicted to it. I love how it's not only a really really fun mobile game but there also isn't any ads. It makes it feel like someone sat down to make a game that was fun for everyone and easy to play at anytime. ALSO, could we get more maps and cars in the future?? Maybe more rally stuff because that is the most fun especially with the Quattro
I'm so happy to read this! I started making this game as it was exactly the sort of game that I wanted to play - but couldn't find. I'm glad I'm doing it right. New maps? Yeah definitely. I've got a few design decisions I want to think through first but they will come.
a thing you could do to reduce complexity would be to reduce how much forward you are going to check, and making tiles specifically for overlapping, in the city races, could be an underpass, or even a jump between buildings , on the mountain drift course (4:40), it looks like it always going downhill, so the best option could be a tunnel, this could be done without having to change the previously placed track(which in the city would be harder) also, the way you generate levels seems like it could easily divided in different threads on the cpu, youu have the game/physics running on a thread, and another is dedicated only to generate new pieces, could help with performance
Yes and yes! Pieces designed to overlap is a very cool idea, one I'm definitely going to look into. I've tried to run the road generation on different threads but Unity makes that incredibly difficult.
I'd recommend categorizing road pieces into the road path vs the road visual. you can have few road paths while another system chooses which visuals to put the roads as. EG you can have like 25 'sharp right turn' pieces but since they're all basically the same, the path checker only chooses one, before the visual checker picks the road pieces that visually fit. it'll help add tons of visual variety without adding tons of computation. Another thing to do is maybe make a chance for the visual checker to look at many pieces together and go "Hey this multi-piece will fit! let's use that" for instance a few straights in a row could be substituted for some sort of long straight with a nice visual flair. The separation of visuals and absolute path can be quite something. Another idea for visual separation is to have, for instance, in the downhill, the road is rather simple and can use the same road pieces, but the terrain around the road can be generated with a simple particle and mesh deform system. In fact, a random optimization you can do is to make a lot of the objects into world-aligned particles, since that can use just one mesh to stand in for many of the same mesh. Just remember to make sure the culling boxes of the particles are correct.
One way to lower complexity of the depth-first search is to have tiles be categorized (straight, left, right), only needing to check those categories to the power of road sections. Then chose a random tile from that category. Slightly more work to implement, but should allow larger tile variation. Even more complex, but using the snake example, you can ignore intersection with older tiles, as they will be deleted by the time the player gets there. But this adds a ton of complexity and only slightly increases diversity of tracks generated...
in theory, you could have a system that has multiple tiles with the same functionality and size, like a turn. You could have multiple 3x3 tiles that all turn 90 degrees, but you only need to do the calculation once then you can pick a random one of those to place
If you are using a grid I belive you could drastically reduce complexity by only checking 3 types of pieces: a 1x1 straight, 1x1 right, and 1x1 left. Since these pieces are of the smallest possible size, if these pieces can find a way out, then we know a tile is valid, but if they cannot, then there are no larger pieces that could find a better path (unless there are certain special pieces I'm not thinking of, in which case you may need to specifically add those).
The main issue with this one is that if you have a route out of a hole with a 1x1 straight piece, but don't actually have any 1x1 tiles to use, you might end up boxing yourself in anyway by virtue of the path being too wide to escape.
Both good ideas/points. Drifto doesn't have any 1x1 sections. Most tracks don't have any 1x1 pieces. Only considering the most simple pieces is definitely a good idea though. Would be a powerful optimisation once there are more sections to choose from.
@@jonathonhowe you may also think about only using larger pieces to check first? Because if larger pieces can get you out then all smaller pieces will as well. That way you won't find yourself in a situation in which you will only ever get the smallest pieces since the algorithm only every checks that they fit.
Boy, do I have some good news for you. iOS: apps.apple.com/app/drifto/id1643464834 Android: play.google.com/store/apps/details?id=com.UnluckyDuck.Drifto (Also linked in description)
My solution to cheaply implementing the valid placement algorithm would be to avoid choosing a piece that would place its exit in any "threatened" space or its exit too near to any occupied cell in front of it. I would consider an exit as "threatened" if there exists an occupied cell in each of the three columns forward and to both sides. The column width depends on the size of your smallest right angle turn and your smallest straight line piece. The distance you have to check is large enough to check the whole map. What this does is prevent the head of the snake from entering into any areas that it would need to turn multiple times to escape from.
well done video, I really like the style and the different environments you already have implemented :) Just a quick tip related to your recursive algorithm: Spreading your computations over multiple frames doesn't remove the problem but just delays it. The complexity still remains exponential, and adding just a few more tiles or raising the search depth to a few more iterations quickly removes the performance gain you get from adding this feature. I don't really have a perfect solution, but what if you don't care about the different types of tiles while checking for possible paths, but rather only check for directions: So e.g. you want to place a tile facing forward, then you dont need to check recursively for each tile variation that exists, but only if you could place any tile in front of the new tile. Then try placing tiles infront of this new one in every possible direction (forward, right, left) and repeat this recursively X times. if you can find a possible path, then the tile you placed is legit. Otherwise try another one turning right/left/..., you get the idea. I don't think the shape or style of different tiles matters for this, as you should first check for the tile you want to place at the current position if it fits there at all, before starting the recursive search. This reduces the growing number of tile variations to a constant of only 1 or maybe 3 (for each direction), so the only variable you'd still have left is the path length you want to check. (This of course only really works if your game is based on a fixed grid so you can use the "smallest" tile dimensions for searching) I hope this helps ^^ any additions are appreciated.
That would definitely be easier to run. My only concern is it would remove some of the variation, the road would not be able to go back towards itself, even if it's still a valid choice. Noted it down in the list of possible optimisations though. It's an interesting thought. Thank you!
Someone said something about wave collapse functions, that reminded me of the “bezier curve” could be useful. You could also use the classic perlin noise
It would be interesting to have some pieces have multiple levels of track (like an underpass/overpass), if you could adjust the algorithm to be able to aim the track back to that piece
In games like temple run it always bothered me that you could go in a circle pretty much and the old path is gone but doesnt really matter to the gameplay. Though I think your game can still run into itself but only after x tiles. Maybe if you had enough turns it could be disorienting enough to forget about the old path
As someone that once made a prototype of a tile-based procedural track-racer (closed course loops) on Roblox, here's my suggestion: abstractify the pathing algorithm. If you have five unique "one road tile straight forward, with one scenery tile on each side" prefab models, the path-ahead checker does NOT need to check each of them as unique cases! Have an abstract "straight ahead one, 1x1 scenery each side" instance, along with abstract instances of every other _type_ of track piece. Then once you have a valid path of track piece types, replace the abstractions with a randomly-chosen unique model from the pool for that type, perhaps using Wave Function Collapse to have some consistency in scenery if you want. Either way, pathfinding complexity should never increase just because you added additional scenery models of the same movement direction...
Something that occurred to me watching this was adding a z=component to the procedural tiles - especially on the city or rally zones, where you could build 10+ tiles ahead then allow for instaces where the road self-intersects with a bridge or tunnel tile - thereby solving the snake problem. OR go the whole hog and have 3d bitwise tiles like ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-G2M45AlxdtU.html
something else that might be interesting to implement is a sort of cache of possibly valid moves by keeping in memory some of the valid segments of the ultimately chosen next piece. This would give your algorithm a possible head start on checking down some new routes.
If the actual placement uses the same logic as the "IsValidChoiceRecurse" then this is needlessly inefficient. Each time a piece is added you recurse to see where a choice of x pieces will get you, then on next piece, the you repeat the x-1 recursion steps and only the last one will actually determine anything. Isn't this exactly the same as maintaining a list of x-1 sections ahead and only checking/placing a single piece without recursion? (and if the placement uses a different logic then the validity recursion, then the check is useless, because we proceed knowing that there is some existing selection of pieces that doesn't overlap, but if we don't then choose those exact pieces then we loose the guarantee of not overlapping) But algorithm's aside that looks like a neat concept for a casual game, good luck!
Hi, just following up on the comment i made a while ago. Downloaded the game and have been loving it!!!! I cant think of any major flaws to be honest. It doesnt run super smoothly, but that's probably just my phone. Great controls. A suggestion for the future, being able to choose between roads to follow would be cool. Edit: also handling at higher speeds should probably be improved
Thank you! I'm glad you're enjoying it! Yeah there are some performance and balancing issues that need some love. They're on the todo list. Cheers for the feedback!
To simplify checking if a piece is valid you can just check if it would create a loop and ensure you aren't going to be on the inside of that loop. Given that your pieces cannot overlap and that roads only have 4 directions that they can travel in, this is trivial, just check if the piece you are placing is adjacent to an existing piece, if so you must turn to travel in the opposite direction to the existing piece, that way you can never end up trapped. Though you do have to check ANY adjacent tiles including the 2 diagonals in the forward direction to ensure that if a corner is diagonal from the tile you want to place that you turn to go in the opposite direction to the entry of that corner piece, it also assumes you always have access to single tile pieces to turn 90 degrees or go straight. Also because the system for selecting the tiles is unlikely to write to data that is used by the main thread during selection, and the data it uses to make a selection isn't going to change during selection it should be relatively simple to run it in a separate thread too.
I think this would be very chill with a nice sound track, where when a song changes the level would also change, but in a seamless way. I.e. you'd have a special tunnel begin and tunnel end piece, and then you could go from the city to the tunnel just by placing the tunnel entrance, and then switching out the set of available pieces to come next to be from the tunnel set.
Oh and props for choosing a simple and fun looking main gameplay mechanic. Another "game mode" idea could be to save the generated route, then make it possible to drive it again, racing your "ghost", similar to many driving games, trying to drift smoother and faster than the last time.
Another solution is coming to my mind to simplify the dead end issue : you could assign a direction vector to each bouding edges of a tile, with a vector pointing outside for blocking edges and inward for roads extremities. With these vectors you could generate a kind of flow map that would naturally point in the general "good" direction to follow, and so directly pruning most of the wrong tiles in each case. Not tested, just a guess😁
My worry for stages like the city would be that it encourages the road to be less dynamic. I can imagine this working really well for a stage that should travel in roughly the same direction - like the touge.
@@jonathonhowe Not sure : this technique should help to ensure that the path do not loop in a dead end, but you'll still be free to randomly chose tiles that complies to the flow field, and get a sinuous road.
Hello, can you have a camera option like art of rally? This game feels like it but the camera position on the gameplay shown isn't for me, its a bit "zoomed out" fish eye effect. Also maybe an elevation change in terrain as the game duration gets longer.
You could also multithread the generation. Check 8 things at once for example. Or 80. Or 800. I did this for my extremely similar, but dumber system (I just pretty much kept generating more grid and checking for overlaps on the cells IIRC) for a minigolf track generator, with the staggering you mentioned and the generation was just instant (even for a 100 pieces long track). If you keep the amount of data passed around low, it's going to be fast on a single thread and inside a single frame as well. Just calculate with the pure data required, nothing else and it should be plenty fast. Cool game!
Looking at gameplay - there might be a simple way to make it much more visually interesting! Basically, creating a few "landmark" tiles for different stages that would be randomly placed at the creation of the level and persist until the level is done. They would have no road connections and be higher than basic tiles (like tall trees, a taller building, a crane and so on) so the player would just occasionally see them in the background, behind actually driveable tiles.
I expected a wave function collapse algorithm -- that way, you can pre-determine valid pieces for every tile and guarantee legal exits always existing (with a powerful collapser). This algorithm is also cool, but the time complexity is pretty spooky!
Yes! Since making this I've learned about wave function collapse. Once the speed of this algorithm comes back to haunt me I'll take a more serious look into it.
I've just watched this as my first video so I'm not knowledgeable at all in your plans, but I would highly suggest a fixed track mode as well, you will get many more players, and many more long-time if you have time leaderboards on fixed tracks. This infinite track mode also seems cool as well.
You should use a link to listen to the bit list for the road tiles, not sure how much it would speed up performance and help memory, but every bit helps. Also, you should do your depth first search backwards. it is more likely to find something farther away than it is closer to the road, so doing it backwards should improve performance a bit
If you start to get bit by the combinatorial explosion when adding more section types, a possible way out is to introduce a degree of separation between road segments and their surroundings. You can run the depth-first search solely on (what seems to be) the much more limited possible ways the road fills in the next n grid tiles, and then backfill the space around the entire new stretch of road added with your visual content. This should allow for a more flexible combination of sizes and volumes for said content and/or broadening the possible shape of the road - if that's ever an interest for you. I'll admit that this idea came to me mostly because I thought, "if I were making this game I would add the possibility for the road to jump over itself instead of always avoiding collisions".
Just a quick recommendation: If the game is already playable then say it at the beginning of every video (or after a short intro). This will increase the number of people playing your game.
I think there might be a few ways to optimize the comparisons of the panels. one is that you could merge straight sections to count as 1, two is by using a different sorting algorithm, instead of just brute forcing the checks one by one. A thing to do differently would be to ID panels, and when the number of panels is reached based on an adaptive number to take into account the straight sections, it would remove the oldest ID's, therefore you don't have to do all of those comparisons to find out where the oldest panels are and if they need to be removed. this could double as a way to score, when you (eventually) crash or whatever is your death trigger, it just reads the id of the panel of what you are on or something. I hope you see this and let me know your opinion on my suggestions.
You might be able to make something much more efficient just by using a slightly modified A* pathfinding class. The trick is to assign each position a random weight that ranges between a positive and negative value. This will change the way the path is generated so instead of finding the shortest route it will instead meander around taking detours and even doubling back. Once you have your path you simple need to insert the correct tile pieces.
would it be viable to instead make road models that could bend, then figure out the path, and then place scenery and crossroads as needed? that could make it possible for the road to just generate as it goes. if too many crossroads, add a bridge or tunnel that levels itself after the intersections are over, and if there's only one or two, you can make the path replace some scenery with construction or demolished buildings to clear out the way for a cool continuity concept
It's definitely possible, and a very cool idea. In fact, originally a similar system was in mind for this. The reasoning for the system I have chosen with preset road sections is simplicity and development time.
Maybe it's a dumb idea but, is it possible to make a tunnel or bridge "piece" when the path collides with the old generated road? (Sorry I'm not a programmer so idk if this gonna work)
Possible yes, but then the road could change from under the player, ruining the illusion. It would work if only the pieces the player cannot see could change though
You should try mapping 1D perlin noise to an angle, and then make repeated steps from the previous position based on that angle. Voila, non-uniform bendy road with fine co control over maximum twistiness and frequency!
WFC is a fair suggestion, but alternatively you could multithread this pretty easily using the Unity task system. This is a perfect candidate for parallel solving, since you're just check projecting into the future to get data, not actually causing anything to happen at this step, allowing it to be entirely independent. Assign X tasks, splitting the top level of the recursive checks into X subsets and handing them out. Then, await Task.WhenAny(t1,t2,t3,t4,t5...); and then cancel the other tasks via cancellationtokens. The moment one thread finds one valid combination, it will return that, you can terminate all others and continue as you were. Additionally, that would spare you the difficulty of spreading it over many frames via coroutines, since it's happening asynchronously.
For some reason I can't search and find the game on ios. I need a direct link. US by the way. Also you can play any level without paying if you click a certain spot on the level selection.
I feel like a depth first search is really over engineered and will massively increase in compute time when you add more types of pieces. instead you can just count up the number of pieces and turn left and the number that turn right. If for example you already have 2 pieces that turn left and you want to add another left piece, you are bound to run back into yourself, so either generate a straight piece or a right piece. This will also make nicer drift maps since changing turn directions lets you weight transfer and maintain the drift
Wow this actually looks quite nice. I saw a comment saying this is a mobile game. Shame it's not available for computers. You should try to make it multi-platform (macOS, Windows, Android and iOS although it might be a little hard for iOS lol)
Thank you! I definitely want my next project to be a PC game. I don’t think a port of Drifto would be very good for PC, perhaps a similar concept designed for PC from the get-go.
neat - are you reseting the player to zero at a certen time or does the high numbers not cuase issue ? Was watching a tutorial once about it - but did not try it my self.
@@jonathonhowe 'Endless Runner: Procedural Track Generation (Unity Tutorial)' floating point errors - in the intro he talks about it. I have not done this yet.
I haven’t been watching this series at all so forgive me if I’m wrong but if the players just turns around would they not just see the void behind them?
Yes good point. I didn't mention it in the video, but the game actually has a wall that aligns itself with the oldest track piece. It's not the best of solutions but avoids players seeing/driving into the void.
You should add some rudimentary clouds to the game. I think that since the only real gameplay is driving and drifting, having some more things to look at within the game will make it more enjoyable to just cruise around and chill.
A way to diminish the number of comparisons made, could be to restrict the use of tiles, or only allow the use of certain tiles after a specific one has been placed before, like "don't use a roundabout if the previous tile was a roundabout", or "don't put a left turn if the previous two were left turns too"
