What would be interesting is to make it capable of rendering massive highways: 5 lanes on each side, median center, on/off ramps (maybe not as you could then take them), lane width changes (rural to urban to rural and back), with tons of highway traffic on both sides.
I could steal ideas from the Out Run arcade hardware for this. It had two hardware boards to render and merge the two 3-lane (prerendered) roads -- once you realize this, you can see it in the design everywhere from the split road at the start, to the merger, to 3,4,5,6 lane highways, to the split 3-lanes each, and to the merger again for the next stage. A similar thing could be done here, with more control since it's all software (though currently it's using a pre-rendered road texture, so it's a little like the Out Run hardware as is).
I think the part that stands out the most is the infinite vegetation -- it really calls out that this is a driving game, and not a racing game. It just spells out a different expectation, and makes for different magic. Going for a fast country drive or through curvy and hilly mountain roads is far different than a race track.
I would love to talk during these videos. Perhaps I should just give it a shot, and I'd likely get better at it over a year or so, and not be too unbearable to watch after some time. For now, I at least want to get some of my content out. I have an entire series on an RPG text mode engine that I haven't uploaded since I ran into issues recording the Windows Console. But thank for your understanding, and for watching.
Thank you. I like this video more than the future ones, since it has the element of random placement, without look so perfect. I removed that since I was making things more mathematical to test various perspectives, but for aesthetics, I need to bring this design back.
this is so cool, im trying to make a game like this, i followed the pseudo 3d race tutorial in portuguese but I want to add objects and obstacles and im struggling with that. still cant figure it out
Take this one step at a time. Forget about adding objects, and just add dots on the road. The dots will be the location of the later added 2D sprites -- the centers of their bottom row. But for now, figure out where the dots are. The dots will be your objects for now. So you will have a list of positions for these dots -- in X (horizontal) and Z (distance into the road). As you move through the road, the camera position moves, and you know how far into the road (Z) you are going, so you know the Z of each scan line. Each dot will have a Z, and be between two scan lines. At first, just round off to a scan line (later you can interpolate between two of them). When you drew the scanline, you know it's X and Y position on screen, and its relative size to the camera -- this data should be useful for you to find the dot's position. Plot that dot pixel! When you get this working, we can move onto phase 2. :)
So for the infinite/continuous hilltop effect, is there sort of a camera rotation (aim downwards towards your feet to upwards towards the sky) type rotation happening? I am guessing not. But, I am curious that this type of camera rotation could be part of the level design. Consider being stopped on a perfectly straight road, in your engine, and then adjusting this rotation. It would adjust the on-screen height of the horizon in the final render.
The original Full Tilt engine set an "attack angle" for the hills from -10..+10. Once you're going uphill at +10, the road cannot curve upward more. In this version, the "attack angle" is still from -10..+10, but it means delta. So once in a road section at +10, which is curve upwards, the road can continue to have +10, and continue to curve upward. Likewise for -10 to make the infinite hilltop.
The lighting is just assuming the road data for "attack angle" is -10..+10. It works since -10..+10 makes the road curve down..up if it means relative, or if it means absolute. Both give the same curve, since +10 means curve up for relative, and +10 also means curve up for absolute (in all cases where the road isn't already pointing at +10).
I think original Out Run code is more of an array of "road segments" that dictate a bunch of settings, like road curve, hills, camera angle, lanes, etc. Some original games didn't even introduce turns in the road from the distance; the road in its entirety just becomes curved everywhere at once. Out Run does this for camera angles (sometimes it just changes even when the road stays straight and flat), and for lanes (splitting happens everywhere at once), and the hills morph at a different rate than the road lines / road objects. It's an interesting idea, since the road designer just says "this is what I want at this section (i.e. camera high above looking down)", and the engine does it, vs. what I am doing which is designing the road flow and letting the engine draw it however 3D happens to looks.
@@JDoucette Right, that makes sense. And your idea of the infinite hilltop is cool, and ironic that it's removing your boundary conditions that were meant to make it realistic.
@@Xonatron One issue with the hills acting like infinite curving is that there is no true horizon. Just like the curving left/right on the roads can curve infinite (it never turns back on itself, so you can never get 180 degrees back at you), if the hills do the same, you can angle the hill upward, and then the rest of the road just continues at that angle. The solution is simply ignoring this, just as the lighting ignores it. I'll test it out soon with a background image.
I don't have a tutorial, but you can start by considering each horizontal strip is a single scan line, and try to get something like this drawn first. Make them small as they are closer to the center of the screen. Relative size is inverse of the distance away from the eye. Once you have that, you can start sliding them left/right for turns. Then you can try sliding them up/down for hills (taking care to fill in any gaps, and account for z-ordering).
@@random_precision_software Think about it this way, row by row -- scan line by scan line: Assume a straight road, no hills: Step 1. Horizon is at distance infinity, ignore it. Then start counting scan lines downward: Line 1's distance = maxZ / 1. Line 2's distance = maxZ / 2. Line 3's distance = maxZ / 3. Etc. Line 1's relative size = maxZ * 1. Line 2's relative size = maxZ * 2. Line 3's relative size = maxZ * 3. Etc. The relative size = the width of pixels the road will be drawn on-screen for that scanline. If you make a single strip (scanline) of a road texture/image, stretch it to that size, for each scan line and you have a road. Step 2. Instead of just having a single line for the road texture, make a full 2D image. Now use the scan line's distances to understand the delta between line to line. That how far in the road (in your image) you have travelled. Now you have a textured road.
@@random_precision_software for anyone that wants that doesn't have an idea of how these works and want to have a start, search here on youtube for "javidx9 retro arcade racing game". Its far from the quality of this example here, but its a start.
What would be interesting is to make it capable of rendering massive highways: 5 lanes on each side, median center, on/off ramps (maybe not as you could then take them), lane width changes (rural to urban to rural and back), with tons of highway traffic on both sides.
I could steal ideas from the Out Run arcade hardware for this. It had two hardware boards to render and merge the two 3-lane (prerendered) roads -- once you realize this, you can see it in the design everywhere from the split road at the start, to the merger, to 3,4,5,6 lane highways, to the split 3-lanes each, and to the merger again for the next stage. A similar thing could be done here, with more control since it's all software (though currently it's using a pre-rendered road texture, so it's a little like the Out Run hardware as is).
I think the part that stands out the most is the infinite vegetation -- it really calls out that this is a driving game, and not a racing game. It just spells out a different expectation, and makes for different magic. Going for a fast country drive or through curvy and hilly mountain roads is far different than a race track.
@@JDoucette I agree. It's about exploration.
@@JDoucette That's true. They used it everywhere.
This is already looking SO good!
I agree. I am loving it.
Dope. Would love some voice-over for those less "game development literate," but I understand that's probably a bit of an undertaking :)
I would love to talk during these videos. Perhaps I should just give it a shot, and I'd likely get better at it over a year or so, and not be too unbearable to watch after some time. For now, I at least want to get some of my content out. I have an entire series on an RPG text mode engine that I haven't uploaded since I ran into issues recording the Windows Console. But thank for your understanding, and for watching.
Beautiful ❤
Thank you. I like this video more than the future ones, since it has the element of random placement, without look so perfect. I removed that since I was making things more mathematical to test various perspectives, but for aesthetics, I need to bring this design back.
this is so cool, im trying to make a game like this, i followed the pseudo 3d race tutorial in portuguese but I want to add objects and obstacles and im struggling with that. still cant figure it out
Take this one step at a time. Forget about adding objects, and just add dots on the road. The dots will be the location of the later added 2D sprites -- the centers of their bottom row. But for now, figure out where the dots are. The dots will be your objects for now. So you will have a list of positions for these dots -- in X (horizontal) and Z (distance into the road). As you move through the road, the camera position moves, and you know how far into the road (Z) you are going, so you know the Z of each scan line. Each dot will have a Z, and be between two scan lines. At first, just round off to a scan line (later you can interpolate between two of them). When you drew the scanline, you know it's X and Y position on screen, and its relative size to the camera -- this data should be useful for you to find the dot's position. Plot that dot pixel! When you get this working, we can move onto phase 2. :)
@@JDoucette thank you for your explanation! I will follow your advice and instructions. i´ll let you know how it goes, thank you very much again!
@@elcanaverals.r.l.2816 Best of luck! Can't wait to hear about your progress!
So for the infinite/continuous hilltop effect, is there sort of a camera rotation (aim downwards towards your feet to upwards towards the sky) type rotation happening? I am guessing not. But, I am curious that this type of camera rotation could be part of the level design. Consider being stopped on a perfectly straight road, in your engine, and then adjusting this rotation. It would adjust the on-screen height of the horizon in the final render.
The original Full Tilt engine set an "attack angle" for the hills from -10..+10. Once you're going uphill at +10, the road cannot curve upward more. In this version, the "attack angle" is still from -10..+10, but it means delta. So once in a road section at +10, which is curve upwards, the road can continue to have +10, and continue to curve upward. Likewise for -10 to make the infinite hilltop.
The lighting is just assuming the road data for "attack angle" is -10..+10. It works since -10..+10 makes the road curve down..up if it means relative, or if it means absolute. Both give the same curve, since +10 means curve up for relative, and +10 also means curve up for absolute (in all cases where the road isn't already pointing at +10).
I think original Out Run code is more of an array of "road segments" that dictate a bunch of settings, like road curve, hills, camera angle, lanes, etc. Some original games didn't even introduce turns in the road from the distance; the road in its entirety just becomes curved everywhere at once. Out Run does this for camera angles (sometimes it just changes even when the road stays straight and flat), and for lanes (splitting happens everywhere at once), and the hills morph at a different rate than the road lines / road objects.
It's an interesting idea, since the road designer just says "this is what I want at this section (i.e. camera high above looking down)", and the engine does it, vs. what I am doing which is designing the road flow and letting the engine draw it however 3D happens to looks.
@@JDoucette Right, that makes sense. And your idea of the infinite hilltop is cool, and ironic that it's removing your boundary conditions that were meant to make it realistic.
@@Xonatron One issue with the hills acting like infinite curving is that there is no true horizon. Just like the curving left/right on the roads can curve infinite (it never turns back on itself, so you can never get 180 degrees back at you), if the hills do the same, you can angle the hill upward, and then the rest of the road just continues at that angle. The solution is simply ignoring this, just as the lighting ignores it. I'll test it out soon with a background image.
Is there a tutorial on this? I want to create a pseudo 3d race game in unity.
I don't have a tutorial, but you can start by considering each horizontal strip is a single scan line, and try to get something like this drawn first. Make them small as they are closer to the center of the screen. Relative size is inverse of the distance away from the eye. Once you have that, you can start sliding them left/right for turns. Then you can try sliding them up/down for hills (taking care to fill in any gaps, and account for z-ordering).
@@JDoucette ok, I'll have a go at it soon.
@@random_precision_software Think about it this way, row by row -- scan line by scan line: Assume a straight road, no hills:
Step 1.
Horizon is at distance infinity, ignore it. Then start counting scan lines downward: Line 1's distance = maxZ / 1. Line 2's distance = maxZ / 2. Line 3's distance = maxZ / 3. Etc. Line 1's relative size = maxZ * 1. Line 2's relative size = maxZ * 2. Line 3's relative size = maxZ * 3. Etc. The relative size = the width of pixels the road will be drawn on-screen for that scanline. If you make a single strip (scanline) of a road texture/image, stretch it to that size, for each scan line and you have a road.
Step 2.
Instead of just having a single line for the road texture, make a full 2D image. Now use the scan line's distances to understand the delta between line to line. That how far in the road (in your image) you have travelled. Now you have a textured road.
@@random_precision_software for anyone that wants that doesn't have an idea of how these works and want to have a start, search here on youtube for "javidx9 retro arcade racing game". Its far from the quality of this example here, but its a start.