Forward-scrolling racing game - Storing the track

[Albright]

For examples of what I'm thinking of, think early pre-polygon "3D" racers like Pole Position, Hang-On, and the like, but with the ability to go up and down as well as left and right. My game will actually feature a train but I intend to use the same methods in terms of doing the graphics and such.

I'm not asking about the graphics part, though. What I'm wondering about is how to store the track.

The best idea I've come up with so far is maybe to consider the track as segments and then have each segment attributes which correspond to the degree that it goes left/right or up/down, plus the length in meters. Then store all those as a big list. So a track like:

Code: Select all

{
  {x: 0, y: 0, l: 20},
  {x: 10, y: 0, l: 35},
  {x: 0, y: 0, l: 10},
  {x: 0, y: -10, l:10},
  …
}

…would go straight ahead for 20 meters, turn to the right at 10 degrees for 35 meters, go straight ahead for 10 meters, go down 10 degrees for 10 meters, etc. I think this would be relatively easy to implement but maybe not very flexible.

The other approach I've thought up is having some sort of equation which will draw a line in 3D space. This would allow for more flexibility and not have to break the track into segments which might allow for smoother "transitions" between parts of track, but this sort of math is probably out of my league.

I'm really curious what the games of the era did. However, I haven't been able to find any articles which cover it despite trying several different search phrases. If anyone has any links covering this I'd greatly appreciate it.

Otherwise I'd appreciate any feedback on how you'd implement this sort of thing or what flaws or improvements you might be able to see in my "big list" approach as above.

[Gunroar:Cannon()]

I think you're big list is fine. The best things are (sometimes) things you (know how to do and) implement yourself. That way you understand the code and structure.

[BrotSagtMist]

I dont understand where segments would be helpful here.

Last time i did _Tracks_ i simply did a list with the position as key containing the borderstones.
eg:
M[100]={200,600}
M[200]={100,1000}
Would narrow down my track after 10m and widen it up after 20.
This table had like several thousand entries.
Then in update i had

Code: Select all

if M[math.floor(Position*10)] then Active[math.floor(Position*10)]=M[math.floor(Position*10)] end --throw on active stack that is to be rendered and processed in collision 
if  Active[math.floor((Position-20)*10)] then Active[math.floor((Position-20)*10)] =nil end -- remove after we pass the object

The position is multiplied by 10 to allow finer positioning, but it needs to be coarse enough so that you cant pass more than one digit in a frame.

[UnixRoot]

I dont understand where segments would be helpful here.

3D segments are great for real looking hills. And you don't have to draw and calculate the size and position of every line, but you can use some form of simple 3d projection and love2d's polygons or even textured meshes to finally render the segments. Oh, and you're resolution independent with segments.

http://www.extentofthejam.com/pseudo/
I followed this tutorial and learned a lot from the linked JavaScript racer.

I actually have textured meshes with different textures for every lane. I can control per segment, what textures are being used for each lane and what attributes they have, like booster lane, dirt strips, etc. I optimized the culling and sorting, pushing vertex data with ffi.cast and getting around 400 - 500 fps on a crappy Nvidia GT 710

[darkfrei]

You can store the difference between sectors:
Ii you moves along Y axis, then it can be:

Code: Select all

{x=0, y=10}, -- straight segment
{x=-10, y=10}, -- left "curve", where you are need to press the left key to follow the road

The y vector component can be optional if the length is a "standard" size.
Optional here can be the relative z component of vector, where the negative z means that your road moves down, it looks like a hill, and positive z means that your road goes up.

[BrotSagtMist]

I still dont get it, but the hill is kinda cool tho.

[UnixRoot]

I still dont get it, but the hill is kinda cool tho.

Pros :
Real 3d geometry can be used for the hills
The system is more consistent
You can combine it with real 3D models, because you already have the projection math
You're resolution independet
You can use textures, mipmapping, even antialiasing
You have full control over all of the segments, you can change their apperance and attributes on the fly
You could use real 3D rotation for the camera to follow the hills
It's fast

road.jpg (133.69 KiB) Viewed 5054 times

[darkfrei]

I think that's something like this (here is without perspective):

2021-11-08T16_51_34.png (32.17 KiB) Viewed 5048 times

generated-2d-road-01.love

(1.08 KiB) Downloaded 115 times

[BrotSagtMist]

I gave it a lil try too, but it constantly feels like going uphill
Also the horizon sucks a bit.

r.love

(613 Bytes) Downloaded 134 times

[darkfrei]

I think that the result must be like