There is a unique challenge in the distances & altitudes of a BFR flight being much larger than a car.  It would be too boring if the player had to wait 8 minutes to reach orbit.  There is the timelapse option, but the player still needs rapid maneuverability far beyond a real rocket.  The track, obstacles, ramps, & players would have to  grow exponentially with altitude to make everything appear just as maneuverable at 300km in timelapse mode as on the ground in realtime mode.  It would look pretty awful & not be very realistic to have rapidly expanding models, either.

These days, animals expect realistic flight simulations like Kerbal, Orbiter, & XPlane, but an arcade experience needs to be more like games from 40 years ago.  They just had a static space environment & a static ground environment.  Players transitioned between the 2 environments at certain times in gameplay.

So the track needs to be scaled way below true orbit insertion dimensions.  Displayed values have to be fake values that correspond to a real flight, while the physics system works in drastically scaled down dimensions.    Asphalt showed players get bored after 1-2 minutes per game.    MECO needs to occur at 45 seconds instead of 2 minutes.   The Karman line needs to be 10km instead of 100km.  Maximum speed needs to be 500km/h instead of 27000km/h.


The other physics problem is creating fake gravity to make the BFR stay in the track.  This is officially done in Godot by creating Area nodes.  Each area node has a different gravity vector.  Doing this for a track takes over 250 area nodes, though. 


The other problem is there's no way to import area nodes from blender like there is for collision nodes by naming them -col. Trying to import a -col shape & change it to an area keeps it as a collision shape in the runtime, regardless of what the editor says.  Trying to import a mesh instance & change it to a collision shape keeps it as a mesh instance in the runtime.  Finally, there's no way to extract the polygon coordinates from a imported object & procedurally make area nodes from that.  The collada exporter exports the polygons out of order, so the polygon sorting would have to be redone in Godot.  

The only way to do it is to export a text file with faces from blender & procedurally create area nodes from the text file, basically inventing a whole new file format for blender & godot.  The area node with artificial gravity needs to be a heirarchy.

var area = Area.new()
add_child(area)
var shape = CollisionShape.new()
area.add_child(shape)
shape.shape = ConvexPolygonShape.new()
var vertex_array = PoolVector3Array()
shape.shape.set_points(vertex_array)

For just creating cubes of gravity, the area node just needs a ConvexPolygonShape with a set of 8 vertices from blender.  No MeshInstance is required except for debugging.

For creating more complicated areas of gravity, the area node needs a ConcavePolygonShape with vertices that form ordered triangles.  The lion kingdom never got ConcavePolygonShape to work.

The next major challenge is making the rocket slide down the track & walls instead of getting stuck or bouncing off the surfaces as Godot does.  The 1st attempt was a disaster.

A simple rigidbody with CollisionShapes just bounces out of control.  1 idea was defining the rocket as a VehicleBody with 4 VehicleWheels, but the famous vehicle demo

 https://github.com/BastiaanOlij/vehicle-demo/tree/Part-5
just slides down the horizontal surface & gets stuck on the walls.  Adding more wheels has erratic effects.

There is a navmesh demo 

https://github.com/godotengine/godot-demo-projects/tree/master/3d/navmesh

where the navmesh correctly makes the player follow the walls of a track, but the player isn't a rigidbody that collides with the walls. 

Because of the need for stunts & the artificialness of Asphalt 9, doing physics from scratch is a leading idea.  The mane problem is simulating the collisions.  It would be easiest to make thousands of area nodes with a precalculated direction of opposing force when the player entered them.  That could keep the player out of the areas, but not accurately define the boundary of player movement.  Some combination of a navmesh & custom physics might work.

Outside of the artwork, this game is manely the same as any other car racing game.  That's why lions thought it would be a simple matter of copying another car racing game.  The lack of any car racing games demonstrating the desired physics is a tough spot.