StuntsLegacyEngine

[llm]

For the original engine I can't even imagine how to get that done.
I was thinking about the collision part of CAS his engine. (Updated that post for clarity)

I know, but a greefield projects makes it still not easy in detail
Your description of the case will still result in 2000-3000 lines of code with more or less complex math

[Daniel3D]

I just hope I can help envision the basic structure.

[llm]

I just hope I can help envision the basic structure.

no problem - but your text was on such a high abstract level thats its compareable to "how to bring a man on the moon"
build a rocket, put a man in it, fly to moon, finished

[Daniel3D]

I never said it be much of a help.
Nor did I claim to have the answer.
I'm not Sherlock Holmes, more like Dr Watson.
Blurting stuff out until someone else see's the light...

[Cas]

Alright, so these are more or less the difficulties:

• When in the air, you want to calculate the next position. If that position is also in the air (no collision), it seems easy, but it's not that much. The car is a non-point-like solid object and thus, it has an angular momentum. I have to calculate where each of the vertices that make the block are going to be and maintain the distances between them. Also, at the speed a car can fly in the air like in Stunts, air drag is significant, so the angular momentum will not be fully preserved. This has to be calculated too.
  
  
• When landing, there are several problems. I could say that the car will land if the centre of mass will cross from one side to another of a surface during that cycle, but this surface, while in a plane, does not go to infinity, so even if the centre of mass crosses it, maybe the wheels don't, or some wheels do and some wheels don't. And if the centre of mass does not cross it, maybe one or more wheels does, in which case, the car should rotate so that the wheel that crosses is forced to stay on top of the ground. Again, rotation of a solid. I don't know if I should individually calculate for each wheel and then put everything together or calculate the wheels from the car in general. Both options are complex.
  
  
• It gets even worse when going from a plane to another. In reality, because the car has for wheels, there is no guarantee that there will exist a plane that shares the positions that the four of them should have at any given time when transitioning between two planes. So one or two wheels might be in the air and their "right" position is undefined. I have to choose. Looking at Stunts, it seems it makes an "average". Get to a slow diagonally and you'll see what I mean. Suspension could be a solution, but it will add extra complexity.
  
  
• For an impact, if it happens above a certain speed, it should be a crash, no matter the angle. If it isn't that fast, then we have to see about the dot product between the car's normal and the surface normal first to decide if it'll land straight or upside down, but it shouldn't crash immediately even if upside down. It would just be uncontrollable. In Stunts, this is how it works. It stays like that for a moment and then it crashes alone.
  
  
• There are some configuration when Stunts clearly doesn't do the things the way it should and emulating it would require adding some tweaking or being smart enough to realise why that happens. One such case is when you drive by the side of the bridge part of a cork u/d. You only have the wheels of one side on the surface, yet the car remains straight. It'd be even harder to do if I wanted to create angular momentum from this. The other case is when driving upside down inside a pipe just staying on the ceiling. Almost the same principle.
  
  
• There's a lot more to consider

[CYBERYOGI -CO-Windler]

This is an abstract on racing game physics:

https://www.team-bhp.com/forum/attachments/technical-stuff/814811d1317211860-brian-beckmans-physics-racing-beckman_-_the_physics_of_racing.pdf


Do you have taken a closer look at "Hard Drivin" and "Race Drivin"?

https://www.youtube.com/watch?v=ofUj8rIgG4U
https://www.youtube.com/watch?v=4W3y-ZuCJg4

These arcade machines were visually and by gameplay the direct predecessors of "Stunts" and I think they did some graphics and physics tricks different. I would love to find out more about their inner working, because they were based on serious driving simulators and may have plenty of hidden featured.

I wrote more about them here:
https://forum.stunts.hu/index.php?topic=4156.0
https://forum.stunts.hu/index.php?topic=4155.0

E.g. they seem to load the race tracks into RAM (booting displays "uncompressing graphics") and so may be easily hackable to load custom race tracks. Has anybody looked closer at the data format?

I notice on MAME that the arcade versions had surprisingly high sight distance despite using 16bit CPUs from 1988. Strange glitches suggest that they build up the 3D world gradually object by object in front of the car (apparently using some kind of offscreen rendering buffer) instead moving through it. So the rotation of fast steering often e.g. results in crooked road rendering (with  gaps and kinks in varying places), which I never saw in other early polygon game engines. Because the machine has multiple specialized CPUs, I suspect that when the car physics CPU rotates the car, distant parts of the graphics are still drawn with an only shifted version of the previous rotational position from the rendering buffer, and only the road section close to the car gets redrawn to the current rotation angle (similar like the reprojection trick for head motion in VR glasses) to keep frame rate high enough.

This is the arcade hardware description by one of the developers:
http://jmargolin.com/schem/schems.htm

[Cas]

It occurs to me that, if the game uses fixed-point arithmetic and is trying to draw polygons that are far, the precision loss will be significant, so rotation can produce very strange results. Stunts does use fixed point arithmetic... or at least, it seems to do because vectors are stored as integers (sometimes 16 bit, sometimes 32 bit, depending on the case), but even with the "full detail" configuration, it won't draw very far.

In my engine, I am not having much problem with drawing. Some glitches are visible in my engine, but that's just because the models were designed for a different engine and also, I've been a little lazy, trying to first get to display as much as possible. So I'm really not very concerned about drawing. I already know I can do it. It's collision that's killing me.

That PDF about car driving physics is super interesting!  Thanks!  This is more about realistic forces and kinetics, but there's a lot of information there that will surely be useful. Collision, in the meantime, remains difficult. I wonder how Kevin Pickell faced it. It's not very easy to understand the code.

[CYBERYOGI -CO-Windler]

The arcade Hard-/Race Drivin behaves different than any home versions and lookalikes. I don't talk of "missing Z-buffer" artifacts. When driving through sharp curves, it does something like screen tearing, but it happens not in the frame buffer but the polygon rendering itself, i.e. stopping the car keeps the jagged deformed road on screen, and the shape depends on speed and angle of previous steering etc. (So it may even do something advanced like dynamically decoding splines of the road curve into linear segments written to a buffer, while home versions simply store roads as linear segments of fixed length anyway. Possibly the objects in Race Drivin are even transformed into 2D polygon pieces those get shifted and zoomed during small motions like in a sprite based game (Outrun etc.) to save CPU time for permitting the high viewing distance, and the buffer of these is updated much slower than the frame rate.)

I haven't gone through the driving game physics pdf. I only found reference to it in a discussion about driving simulation (possibly mentioning research by Doug Milliken, who unofficially participated in development of Hard Drivin). Modern car simulation games can be tremendously more complex than Stunts - see e.g. "BeamNG", which simulates crash physics as solid body deformation (finite elements or such) to make objects actually crush and crumble apart. (I refuse to have a Steam account and so haven't played this yet. I don't even know if my Ryzen 2400G APU would be fast enough to run it well.)

[Cas]

I am also not a fan of Steam or in general, something that requires me to be logged in to be able to play and tracks what I do.

What you describe still sounds to me like a fixed-point arithmetic problem. Say you have a 3D polygon that must be drawn somewhere in your 3D world, but since you're moving, for the current frame, it has to be rotated from the original design coordinates to your current camera orientation. This would be done by applying a matrix that contains trigonometric functions and these functions, to execute faster, would be pre-calculated and would return numbers between -1 and 1.

To do fixed point math, you add some precision by shifting these values, say, eight bits to the left, so you have eight sub-decimal bits. If your polygon is to be drawn near you, its coordinates will be represented say, half in the lower eight bits and half on top of the decimal point, giving 16 bit precision. But if the same polygon is to be drawn far away, it'll first be scaled down, which will shift the coordinate values towards the lower part. Say it goes down 8 bits, then now you've lost the lower 8 bits and your full precision is only 8 bits. When you multiply by the trigs now, this loss of precision may cause your polygon to twist because the coordinates are rectangular, not polar, so the engine has no way to know which part of the precision to keep.

Stunts uses 16 bit precision and sometimes 32, but polygons are never drawn very far away, so the loss of precision isn't significant, but if a fixed-point 3D engine draws very far, it will need bigger integers and a decimal point more offset to the left. Floating-point engines would not suffer from this problem. I'm not saying this is necessarily what happens with Hard Drivin'. I'm just saying it still makes sense to me that this could be the case.

[CYBERYOGI -CO-Windler]

With Hard-/Race Drivin objects look the more distorted the closer they are to the viewer, but not in the way seen in typical home games (straight lines those should be curved in real lens distortion physics, or omitted polygons too close to the viewpoint). The faster the car was rotating when they first appeared in the viewfield, the more crooked they look.  Not distant but nearby objects (particularly road segments) become jagged when the car is quickly drifting sideways or steering fast. I suspect that the graphics gets stitched together from already rendered parts (similar like reprojection) to increase framerate. Not much is known about the rendering beside this explanation of some video MMU tricks (writing multiple bitplanes simultaneously in hardware to increase pixel fill rate).

http://www.jmargolin.com/schem/schems.htm#p01

Regarding fixed point rounding errors, I expect that the position glitches when colliding too slowly with objects may have to do with it. E.g. when very slowly driving against a building, it does not make your car explode or simply bounce off to where it came from, but instead magically tunnels it to the other side of the building. Most blatant is this when slowly touching the train on the "Original Track", which can beam your car many meters away. The behaviour depends on the rotation angle of the car relative to the collided object. It should be easy to define a rectangular bounding square/box and test whether the car overleaps with it and simply makes it explode when inside or put it back to where it came from. I guess that with very slow motion, the numerical difference between stored previous positions may be considered zero and so fails to track where the car came from and simply beams it anywhere outside the bounding box. Also "Stunts" behaves a bit odd when touching buildings very slow.

The similar PC game "Car and Driver" does even much worse glitches, those make the car randomly explode/crash or bump between polygons like a pinball among 3 bumpers when driving over road irregularities (also at normal speed), which makes some spots sort of unplayable by totally unpredictable behaviour.

https://www.youtube.com/watch?v=jDy9sOLjryE

It may be that for error tolerance to avoid such very annoying results, Hard-/Race Drivin simply beams the car outside the bounding box when it fails to detect what happened. But it still has some spots where you can fall through 2 facets of the road when driving very slowly at certain angles. E.g. entering the corkscrew occasionally makes you simply drive through it and so makes the car crash as penalty for leaving the intended path. Also on the left edge at the start of the Original Track of Hard Drivin is a glitch spot where you can fall through the world and spin like mad, adding many 10k points for airtime until it finally explodes. (You have to make a u-turn and touch the now right edge of the road when seeing the orange bridge.) Another strange spot in Race Drivin is before the start of the Original Track. When driving wrongways (in reverse gear?) watching the rearview mirror, you can see the drone cars suddenly switch their orientation from facing forward to facing backward (changing between front or tail end). Their position and speed generally is computed in direct relation to your own (particularly noticeable at the start of Original Track), so they often move jerky when approaching them and changing speed. Likely this was done for adaptive skill and preventing random collisions from behind. (E.g. those in Lynx version keep crashing into my car when driving slow.) The Phantom Photon (blue car at "Championship" when you have beaten the qualifying time) is the recorded motion of an actual player and so does not respond to your car. Also some opponent cars in "Cars and Driver" seem to do this.

In "Stunts" the opponent car is driven by a too stupid AI. Even the best of its drivers fails to finish certain tracks at all and generally tends to crash randomly (I do not need this kind of mischievousness), which is annoying because an always finishing opponent (possibly at slightly reduced speed to stay fair) would be more useful to learn how to drive each track by trying to follow him at a certain distance. I expect that the algorithm anyway internally knows the correct speeds for each jump distance to avoid crashing, so there should be an option to select a "perfect" driver.

[Cas]

At some point, I heard or read somewhere that Stunts' AI doesn't actually generate the same control inputs as the user's, but instead, it "cheats" and follows a path and speed curve. This makes sense if we think how difficult it is to predict what a car will do based on the keys you will press in the following frames, especially with several different cars. If this is so, however, it's surprising that AI opponents are so stupid.

But then I saw this project by this guy who managed to plug the keyboard input from one instance of Stunts into the opponent's input of another to produce an effective dual-player mode and this can only mean that the above isn't true unless there's another layer and this layer has been skipped... I don't know. I'd like to know. Anyway, if this second theory is true, it'd explain why AI's are so dumb, but it'd mean that the DSI guys spent quite some time analysing a way to produce working replays from key presses and what they got would be very impressive.

[CYBERYOGI -CO-Windler]

I wonder why the opponent keeps crashing into obstacles after a jump in certain tracks even with proper car with that I can drive without crash. For an AI opponent it technically should not be hard to be unbeatable (so far the combination of car and obstacles is solvable at all) by rapidly testing thousands of trajectories (possibly even before the game starts) to find out how to jump correctly, or compute them reverse (like raytracing) to save CPU time. Then make him on noncritical places a bit slower or add some random to become beatable again.

But lousy programmed AI opponents seem to be very common. E.g. in the shuffleboard arcade game "Shuffleshot" by Strata (kind of indoor curling on a table), the opponent shoots his pucks to always exactly the same spots with a certain percentage of shots not earning points, but they never land outside the playfield or in the minus 10 points area. And when I land a puck on 10, he *always* shoots it away the next turn. So it only switches between predefined perfect trajectories with a percentage of 0 points shots instead of adding some random to his motion to feel reasonable human, which makes that game no fun to play.

https://www.gamesdatabase.org/game/arcade/shuffleshot

The same company made the nice 3D racing game "Driver's Edge" (featuring long hill jumps in Formula 1 cars) which unrealistic physics is quite fun but feels too easy.

https://www.arcade-museum.com/game_detail.php?game_id=7656

In a driving game at least the higher ranked opponents should be difficult to beat, and if well made, they should also react on my car and not try to steer into it from behind (unless it is meant as a crash race game) and so die too.

These are some patents related to Hard Drivin (websearch them), including some details about AI opponents and level design. I am not sure if they ever had been valid, because the German Reiner Foerst made many related inventions long before Atari. Never the less, they reveal interesting things about the backgrounds of Hard-/Race Drivin.

WO1992002917A1 HardDrivin driver training
US5474453 HardDrivin level editor,opponents algorithm
US5354202 HardDrivin multiple driver training
US5269687 HardDrivin recursive driver training

[CYBERYOGI -CO-Windler]

The Hard Drivin patents are all related to various kinds of recording/replay variants for driver training.

Patent WO1992002917A1 is most general and describes the "Phantom Photon" feature (transparent uncollidable ghost car) of Hard Drivin. Patent US5269687 (recursive driver training) goes more into details of the "Autocross Track" in Race Drivin, which shows on the road a wireframe ghost car replaying the recorded fastest lap, so the player can drive multiple rounds to improve his driving skills by overtaking it, which the next round will replace the ghost car recording when he was faster. The text mentions that the game apparently was cross-compiled on a Digital Equipment Company VAX computer with Green Hills Software, Inc. "C" compiler available from Oasys, a division of Xel, Inc. of Waltham, Mass.

Patent US5354202 describes a 2 player mode in that the 2nd player drives against the recorded ghost car of the 1st player to permit competition driving on a single headed arcade machine.

Patent US5474453 is most interesting. It describes the simulated traffic and scenario editor of the AMOS Police Trainer, which was a serious driving simulator for police chase training, which had multiple cars with real dashboards connected to networked Race Drivin PCBs (one per monitor) and an additional central desktop computer for control.

https://www.youtube.com/watch?v=__bvDrQQqT4

The text explains many technical details of the apparatus, those certainly also affect the inner working of how Hard Drivin implements its "drone cars" on the track. These follow prerecorded trajectories those can be replayed at different speeds and have start and end points to meet the driver's car at certain spots and synchronize in various ways (e.g. to simulate a car crash situation). The scenario editor was controlled by rocker switches on the physical car dashboard and an onscreen menu for the instructor to record the paths for each drone car by driving (teach-in method) and edit what they shall do. Particularly there could be a "rabbit vehicle" intended to be pursued by the police cars for training. The text explains data structures for the trajectories of drone cars. Unfortunately it tells nothing about a map editor or 3D object editor for making own levels. Interesting is that the archived paper original in the Patent and Trademark Office included a microfice sheet of the copyrighted source code. Because this bulky apparatus likely since long time has been destroyed and scrapped, it may be the only documentation of its original software. Obviously due to relation to AMOS, the arcade game "Street Drivin" (a Race Drivin prototype) did include also a police car.

The focus on replaying stored trajectories explains why opponent "drone cars" in Hard-/Race Drivin do odd glitches and don't care about car physics. While they appear in spots and velocity relative to the player car, after unexpected driving maneuvers (too far offroad etc.) sometime it draws 2 cars overleaping each other or hanging over banked road edges. Likely each of them starts by crossing an invisible checkpoint, which produces nonsense when checkpoints are crossed in wrong order or too different speed. Drone cars also don't respond to bumping into them (this algorithm can not simulate bumpercars). Possibly it was implemented this way because the car physics CPU could only handle a single car and so the rest had to be preprogrammed. So this is barely proper AI, although they at least attempts not to crash into the player from behind. Never the less, I prefer even a somewhat flawed opponent car algorithm over having no option for traffic populated areas at all.

[Daniel3D]

Following the Line of stunts (DSI and EA Canada) and the feasible idea that Stunts was heavily inspired on Hard Driving.
The following games the studio made included NFS one and two. The second included  traffic. I don't know if it was the first full 3D race game with traffic, but certainly up there.

[CYBERYOGI -CO-Windler]

I made a technical analysis of the "Hard Drivin" series, particularly explaining the editor of "Hard Drivin II" and the game engine physics and behaviour differences of home and arcade versions. It also includes a hires map of the Original Track and a little batch script to handle custom tracks with meaningful names.

Analysis of Hard Drivin and its variants
https://forum.stunts.hu/index.php?topic=4155.msg91042#msg91042