ISAWHIM
03-10-2008, 04:53
This is reposted from a PM I sent to Petr.
I was just shooting some ideas in an unrelated message... (I was instructed to make the ideas available for suggestion and viewing.)
I think that, if we do decide to use a "Pure hovercraft", as opposed to a mag-rail concept... A code for POOL would be the better physics. Since hovercrafts act like marbles. But, marbles with propulsion.
If they use the "Plugin" or "Lego" style track builder... Each segment should possibly have a designated center point on the entrance and exit side associated with it, which can be used as a generic track-center-line to follow. If the AI advancement XYZ on the time-line is not matching the next desired point, they can adjust accordingly. (As opposed to creating an actual path to follow, as a separate track-line.) You just assume, if you are in area 7, that your destination is point 2, 3, 4 on area 7... or 1, 2, 3, 4 on area 8... which-ever is within your range limit. (You want to look ahead as a destination, but not too far, or you can end-up going the wrong way on a loop. Plus, if hit off track, you want to return to the last position you were closest to, since your last destination point is now possibly too far away. But ONLY if it is too far away... if you got knocked forward, so now your destination point is closer... you advance towards the next farthest point in range.)
You could just orient the ships horizon, based on the intersect of three points/feelers... (Nose, and two on the tail)
On a jump, the last angle felt is your horizon... The longer you don't feel a ground, the more you level to the horizon. (As opposed to true calculation of mass, force, inertia, rotation, yadda...yadda... yadda...)
Once you come to land, a little tolerance should be allowed before orienting the ships landing horizon/orientation, to simulate a compression or soft bounce landing... (Since the hover device is bouncy.)
Any part that is too far from the intersect distance, slowly alters the ships angle, as opposed to quickly, which would give an unnatural "Steel wheels, no shocks", orientation which would seem rough on the flat angle track transitions of hills and banks.
I know it would be a bit much, but each ship should... 1) have a limited shape design that is semi-standard. 2) Use a series of two or three spheres as the collision body. (Overlapped to simulate good solid coverage and the fastest collision detection.)
We could work into the game... that each ship has a force-field shield, which would explain a single pure round shield collision, but not having that round shield count as a ground contact point. (You could just draw sparks at the point of intersect of the shields, as opposed to drawing a full translucent round shield around us... If they had extra frame-time... you could. That could be a LOD item.)
LOL, a "Tractor beam" could be the "Race-craft flipper", which restores flipped cars back on the track, in the event of a full flip... if we do use a flip-over code... (Though, for the safety of the crowd, I say that they install a similar "Track force-shield" to keep us inside the track.)
Hehe... Just throwing out some possible design ideas... ones that could possibly help reduce your programming a little...
Some of the above, is being addressed in the AI section of code. But there were elements here that I too, wanted to keep open for thought, as they might allow for better play, add visualization, could be used in the story-line, or may have a better alternative.
Thus the generic topic, but related to the content.
I was just shooting some ideas in an unrelated message... (I was instructed to make the ideas available for suggestion and viewing.)
I think that, if we do decide to use a "Pure hovercraft", as opposed to a mag-rail concept... A code for POOL would be the better physics. Since hovercrafts act like marbles. But, marbles with propulsion.
If they use the "Plugin" or "Lego" style track builder... Each segment should possibly have a designated center point on the entrance and exit side associated with it, which can be used as a generic track-center-line to follow. If the AI advancement XYZ on the time-line is not matching the next desired point, they can adjust accordingly. (As opposed to creating an actual path to follow, as a separate track-line.) You just assume, if you are in area 7, that your destination is point 2, 3, 4 on area 7... or 1, 2, 3, 4 on area 8... which-ever is within your range limit. (You want to look ahead as a destination, but not too far, or you can end-up going the wrong way on a loop. Plus, if hit off track, you want to return to the last position you were closest to, since your last destination point is now possibly too far away. But ONLY if it is too far away... if you got knocked forward, so now your destination point is closer... you advance towards the next farthest point in range.)
You could just orient the ships horizon, based on the intersect of three points/feelers... (Nose, and two on the tail)
On a jump, the last angle felt is your horizon... The longer you don't feel a ground, the more you level to the horizon. (As opposed to true calculation of mass, force, inertia, rotation, yadda...yadda... yadda...)
Once you come to land, a little tolerance should be allowed before orienting the ships landing horizon/orientation, to simulate a compression or soft bounce landing... (Since the hover device is bouncy.)
Any part that is too far from the intersect distance, slowly alters the ships angle, as opposed to quickly, which would give an unnatural "Steel wheels, no shocks", orientation which would seem rough on the flat angle track transitions of hills and banks.
I know it would be a bit much, but each ship should... 1) have a limited shape design that is semi-standard. 2) Use a series of two or three spheres as the collision body. (Overlapped to simulate good solid coverage and the fastest collision detection.)
We could work into the game... that each ship has a force-field shield, which would explain a single pure round shield collision, but not having that round shield count as a ground contact point. (You could just draw sparks at the point of intersect of the shields, as opposed to drawing a full translucent round shield around us... If they had extra frame-time... you could. That could be a LOD item.)
LOL, a "Tractor beam" could be the "Race-craft flipper", which restores flipped cars back on the track, in the event of a full flip... if we do use a flip-over code... (Though, for the safety of the crowd, I say that they install a similar "Track force-shield" to keep us inside the track.)
Hehe... Just throwing out some possible design ideas... ones that could possibly help reduce your programming a little...
Some of the above, is being addressed in the AI section of code. But there were elements here that I too, wanted to keep open for thought, as they might allow for better play, add visualization, could be used in the story-line, or may have a better alternative.
Thus the generic topic, but related to the content.