Another example of the limitations of modern game engines, though he didn't attribute any challenges to the limitations of the game engines themselves.  Younger lion really thought making a starship version of an asphalt game would merely require importing artwork into an existing framework.  The framework would automate all the physics.  That doesn't exist. Modern game engines just provide a basic graphics layer, a basic physics engine, a basic camera algorithm but going from that to something useful is a big deal.  3D modeling is also a lot more manual than expected.

All the talk about AI generated javascript games got lions wondering if more of a starship racing game could be automated.  The trend has been abandoning natural language & using novel prompt languages to describe programs. The compiler is the large language model & the prompt language is more optimized for describing a program than natural language while being higher level than a programming language.  The mane problem is standardizing on a prompt language.  There's an example game written in a prompt programming language:

https://x.com/nobody_qwert/status/1893584330095509843

Develop a web-based 3D game demo that features a procedurally generated maze and a soldier character with smooth movement and proper orientation. Follow these specifications:

- **Libraries & Dependencies:**
  - **Three.js (r128):** Use Three.js (version r128) via a CDN, for example, [cdnjs](https://cdnjs.cloudflare.com/ajax/libs/three.js/r128/three.min.js).
  - **GLTFLoader:** Load the 3D soldier model using GLTFLoader from [jsDelivr](https://cdn.jsdelivr.net/npm/three@0.128.0/examples/js/loaders/GLTFLoader.js).
  - **OrbitControls:** Implement camera control with OrbitControls from [jsDelivr](https://cdn.jsdelivr.net/npm/three@0.128.0/examples/js/controls/OrbitControls.js).

- **Scene Setup:**
  - Create a Three.js scene with a perspective camera.
  - Set up a WebGL renderer to cover the entire browser window.
  - Include lighting (e.g., HemisphereLight and DirectionalLight) to properly illuminate the scene.
  - Add a debug overlay (an HTML element) that shows real-time data like the soldier’s position and rotation.

- **Maze Generation:**
  - Build a 16×16 grid maze with each cell sized 4 units.
  - Always mark the outer boundary cells as walls.
  - Reserve a central open area (for example, cells 6–9 on both axes) without walls.
  - Randomly place walls in the remaining cells with a 15% chance.
  - Create procedural textures using canvas:
    - **Floor Texture:** A texture with a brown tone and grid lines.
    - **Wall Texture:** A texture with a base color and randomized patterns.

- **Wall & Collision Setup:**
  - For each wall cell, create a box geometry mesh sized to match the cell dimensions and add it to the scene.
  - Compute bounding boxes for each wall to facilitate collision detection.
  - Implement collision detection by checking if the soldier’s position (using a collision radius) intersects any wall’s bounding box.

- **Soldier Character & Animations:**
  - Load the soldier model from [https://threejs.org/examples/models/gltf/Soldier.glb](https://threejs.org/examples/models/gltf/Soldier.glb) using GLTFLoader.
  - Scale and position the soldier within the open area of the maze.
  - Set up an AnimationMixer for the soldier with at least two actions:
    - **Idle Animation:** Plays when no movement keys are pressed.
    - **Run Animation:** Activates when the soldier is moving.
  - Smoothly transition between animations using fade-in and fade-out techniques.

- **Movement & Controls:**
  - Implement WASD keyboard controls for moving the soldier.
  - Calculate movement direction using the camera’s forward (XZ-plane) and left vectors.
  - **Rotation Fix:** To ensure the soldier faces the direction of movement, compute the angle with:
    ```js
    const angle = Math.atan2(moveDirection.x, moveDirection.z);
    soldier.rotation.y = angle + Math.PI;
    ```
    This adjustment (adding π) is crucial for the correct orientation of the character.
  - Update the OrbitControls target to follow the soldier, keeping the character centered on screen.

- **Responsive Design:**
  - Handle window resize events to update the camera’s aspect ratio and the renderer’s size.

- **Animation Loop:**
  - Create a main animation loop that:
    - Updates the AnimationMixer.
    - Processes soldier movement and collision detection.
    - Updates the debug overlay.
    - Renders the scene continuously.

The result is trash but some of the physics modeling shows promise.

With a simple grok prompt

Develop a web-based 3D game demo that features a rocket that drives like a car down a 2D track in space.  It drifts when turning.

 The result is a turd that doesn't do anything.

What we're seeing on AI twitter is manely the result of preprogrammed libraries that were developed by animals with a very focused investment in prompt development. 

The lion kingdom hated the idea, but the track design had to be simplified just to get it done.  Instead of arbitrary gravity directions, it has to be a constant gravity vector.  Tux racer did that & it was still plenty entertaining.  The best maps in Asphalt had constant gravity vectors.  There are a few space racers with loops.

The sideways & inverted Asphalt tracks were just too hard to play.  All the godot examples have constant gravity vectors.  Most antigravity racers have constant gravity while using clever art to create the illusion of flying inverted.  The track textures tend to rotate around the ship to create the illusion of barrel rolls & the tracks tend to camber.

A bug in BFR created an interesting visual.

Move_and_slide has a problem where the player can't stick to the collision surface.  It has to bounce.  You can call move_and_slide_with_snap to try to get it to not bounce, but this requires specifying a raycast/snap vector to probe for the surface.  If the surface isn't inside the raycast vector, it bounces anyway.  If the raycast is too long, the player doesn't slide anymore.

The process of converting sketches to tracks needed work.  It has to smooth the track & it needs to work without a 3rd direction line.  Helas, more advanced modeling techniques require installing python modules not part of blender.  The mane modules not accessible in blender are scipy & numpy.  The internet has no good solutions.

---

Installing python modules for blender

The best the lion kingdom came up with was:

# run blender's version of python

cd blender-2.92.0-linux64/2.92/python/bin

# install pip

./python3.7m -m ensurepip --upgrade

# install the modules

./python3.7m  -m pip install scipy

Reboot blender

Then repeat every time blender is upgraded.

The source for a track design is now 2 lines.

The result of a long period of procrastination, doubt, & loathing was a long desired script which could create a 3D track from just 2 paths.  The key requirement was smoothing the paths.  That used the scipy.interpolate module.

Godot had a strange bug where the rocket would get stuck to the track instead of slide.  The only solution was limiting the falling velocity.  Then there was a bug where godot reported body.is_on_wall() instead of body.is_on_floor() when the rocket was on the floor.  It interpreted the floor mesh as a wall because the track is vertical.

Constant gravity got the rocket moving & sliding the farthest, but it still got stuck when it had to turn more sharply.  Move_and_slide doesn't turn the rocket.  It gives collision points, but not how far the rocket needs to turn to avoid the wall.  Lions aren't sure how this is formally done.  An algorithm which turns a fixed amount in every frame isn't very realistic.  Repeatedly turning to many orientations & testing for collisions in every frame is very inefficient.  Turning too much makes it appear to bounce off the wall.

A few more ideas came from a couple videos

That provided a way to align the rocket with the floor & make it turn more sharply depending on how much it hit a wall head on.  The cross product grows as the collision is more head on.

In all the Godot examples, the floor is the ZX plane.  Y is vertical.  

The mane problem is the BFR track is on the YX plane while the ground is the ZX plane.  The example equations can't be translated to the YX plane by swapping variables.  All the other games are on the ZX plane.  

Another problem is the up direction is diagonal.

The godot interface doesn't show the signs of the axes.  Trial & error showed up to be X=-1, Y=0, Z=1

The examples zero out the Y axis to zero out the up direction.  When up is diagonal, you have to get a cross product involving the up vector & subtract the cross product to zero out the up direction.  

Hacking out all these details yielded the 1st complete track run purely by sliding & bouncing off the walls.  A big part of the Asphalt games was how most of the tracks could be finished with no user input.  A few maps required user input to finish like the Chinese track.  The lion kingdom figured doing this would prove the physics were manely working.

Part of the magic was designing the track so it could be traversed passively.  In a few points, the rocket only avoided flying off the track by luck.  There is a flaw in how the rocket flies sideways if not acted on by a force.  These car attributes have to be programmed manually.

The next steps would be manually adding some car physics, finally adding user input, jumps.

The genre lions have been attempting to emulate is the anti gravity racer.  Using anti gravity racers as a search term gives better results.  

Sadly, the godot editor looks a lot better after trying Unity.  There were attempts on godot which got a lot farther in a lot less time.

https://www.reddit.com/r/godot/comments/k53914/antigravity_racing_game_im_working_on_in_godot/

There's no source code.  For the physics system, he simply says "a RigidBody that isn't set to collide with anything so that I can use apply_force() and apply_torque() to try to move it more realistically."

https://github.com/Corruptinator/G-Zero

Like BFR, this one similarly focused a lot of attention on creating artificial gravity but doesn't do anything.

There are some other variations of the genre which support 3D navigation inside a tube.  It seems in this mode, they don't have to worry about artificial gravity & debugging move_and_slide.  They can just collide with the walls & stop.

There's a lot of precision flying through pigeon holes.  It still moves & slides when it hits a wall.  There's no jumping because it's flying.  It's been decided that some form of gravity is required to achieve any entertainment.

This one talks about using raycasts to turn the vehicle when it hits the ground.  BFR already uses the normals of the ground, but not a raycast.  The problem with this is it doesn't handle hitting walls, hitting the ground sideways, or hitting a ceiling.  Maybe the solution is raycasts pointing in every direction.  This one reveals the global_transform.interpolate_with function.

Interesting workaround by using a sphere to model a vehicle.  If the vehicle is long & narrow, it's going to stick beyond a wall, but lions are willing to compromise on appearance.  This one reveals the global_transform.orthonormalized function.

BFR doesn't use godot's gravity system, but this shows how it can simulate orbital mechanics.

Overall, the home brew gootube game programmers haven't yielded any satisfying physics system in the last  4 years. The question is always how these partial kludges are going to entertain for hours.

Revisiting it, they haven't changed plans, though the industry trend is starting to require projects to be stored on company servers instead of git.  There seems to be an industry backlash against github, as the repositories are boosting github's valuation instead of individual startups.

The verdict was something is better than nothing & enough time went by without any progress to move away from godot.  The lion kingdom would choose any game engine which just had a built in car racing system, so it might entail trying every game engine.  Unity was 1st because all the other BART riders worked there.  It's a big deal for lions to base their productivity on the whims of corporate profits.  It was a big deal to move PIC development to MPlab after hanging on to assembly language longer than anyone else.  

The user interface was a kludge.

The X11 port was low effort.  The mane problems were the expose events not being handled, zoom functionality not working, package manger not working.  In the package manager were supposedly off the shelf spaceship & car assets with the physics fully implemented while godot only had a single partially implemented vehiclebody.  Unfortunately, debugging the package manager would be quite difficult & besides the few free assets, most of them were expensive.  Watching through a tutorial

the mane benefits from unity were in modeling the map & visuals.  The vehicle body was more complete than godot, supporting jumps, but still nowhere close to asphalt 9.  Gameplay continued to rely on programming the very same transforms as godot, rather than installing an instant game.  It uses very microsoft centric C# & visual studio.  Supposedly visual studio has replaced netbeans, which previously replaced eclipse as the gold standard.  Even though godot's IDE is a turd, lions always used nedit.  Since no-one instantly popped out a space racer in unity, the idea was put on hold.

To reduce the brain power, it could be a transparent race track with environment map angled in such a way that the track appeared to take off vertically when it really was horizontal.  That eliminates the virtual gravity problem.  When the track appeared to reach Mars & the ships reversed direction to slow down, it really  was another horizontal position & the ships were slowing down horizontally.

Tux racer was a beloved game of lions.  The ability of its physics system to slide along, jump, & convey the sensation of speed greatly resembled what lions wanted in a space racer.  It also had surreal looking visuals when racing at night, an open world which only slowed down when off track, non deterministic flat spins.  It's missing manely barrel rolls, knockdowns, opponents, drifting, modern graphics, but the basic gameplay is there.

It was all written in paw coded C in a single semester.  The author became a highly successful indie game developer, still doing exactly the same thing today he did 22 years ago.  The lion kingdom never learned the amount of game engine theory that guy learned in school.  Being written in C allowed a lot of tricks not possible in a modern python game engine.

There's always telling the player to suck it & pilot in 3 dimensions instead of riding the wall & following gravity.

This was originally conceived as a BART project for completion during the lion kingdom's commute, but the commutes never returned so it has manely died.  There are much more practical things a lion can do when not stuck on a train.  

The last efforts were just on the physics system instead of any more art.  There was an attempt to use move_and_slide instead of the proper physics system.

It would pitch & roll to properly line up with the imaginary floor.  When it came time to yaw to line up with the walls FUGGEDABOUDIT.  Godot wasn't doing anything to the orientation.  It purely read the gravity vector to determine the pitch & roll.  Then it used the collision coordinates on the walls to determine which way to yaw.  Just doing this manually made it go crazy, so no amount of godot replacement would make any difference.

Reducing it beyond move_and_slide, to where it just slides on the imaginary floor instead of jumping, would make it quite boring.

Updated some bits to make it less unbearable, but it's all just a mockup for testing a physics system.  It's definitely not going to be 8 widely spaced launch pads.  It would look better if the 8 rockets were on a single pad.   The real goal is a scratch built physics system which allows the BFR to push itself down the track with no user input.

Upgraded to Godot 3.3.2 which changed the behavior of a lot of functions but didn't materially improve anything.  Old bugs were swapped for new bugs.  look_at no longer reset the scale to 1, but itself became erratic.  Particles changed direction.  Various math operations no longer worked.  Operations on the basis of the transform didn't work anymore.

Godot has had several rewrites of its physics system.

https://godotengine.org/article/godot-30-switches-bullet-3-physics

https://godotengine.org/article/camille-mohr-daurat-hired-work-physics

They have implied the existence of bugs in the physics system without actually saying there are.  The lion kingdom is convinced the infinite velocities & angular rates which tended to happen after a collision were bugs in its physics systems.

The lion kingdom is convinced Asphalt 9 doesn't use any real physics system.  It's all baked keyframe animations.  High level parameters like the number of barrel rolls are based simply on player position or player speed.  No matter where godot goes, a scratch built physics system has gained favor.

Finally discovered the KinematicBody3D node.  Its movement is all user defined rather than physics defined, yet movement is restricted by collisions with other objects.  Its key method is move_and_slide which adds a velocity to the current position & slides along any barriers.  Then, to figure out where the kinematicbody contacted a barrier, call get_slide_collision.  It returns a KinematicCollision, which contains the global coordinate of the collision.

move_and_slide finally made it slide down the track instead of bounce erratically, but it no longer turns to point down the track & it still quickly gets stuck.  move_and_slide gets to oscillating between 2 points, then eventually starts going backwards the same way physics did.  The problem is when move_and_slide collides, it doesn't return the velocity after applying the collisions.  The input velocity keeps increasing in all directions until movement becomes erratic.  The true velocity has to be derived by reading back the change in position.

After many years, the Unity editor was apparently ported to Linux.  We'll see if it's another 1 & done like Main Actor, Microsoft Word, Internet Explorer, & Skype were.  It requires a unity account of course & an internet connection for license management.  After discovering how much would have to be programmed from scratch in Godot, the lion kingdom started viewing Unity tutorials.  It has a whole lot more examples than Godot. Unity theoretically has race track frameworks you can drop models in.  It has an automated road builder which can generate 3D paths.

The licensing & ownership of the game engine is less of a factor over time.  The mane showstopper is no-one has really shown a physics system that comes close to Asphalt 9.

Cheap physics

The lion kingdom has considered different options for solving the physics problem.  The stock godot physics system is crap.  Getting useful results from godot would either take too long or require far more engineering than is worth it.  If it was easy, everyone would be modeling the Asphalt 9 physics.

What has risen in showers is just modeling physics the way it was done on 8 bit side scrollers.  They didn't have any physics.  The complete flight path down the track would be hard coded.  There would be static acceleration & rotation in the direction of the flight path.  The user could turn the rocket with left & right input to add offset to the preprogrammed path, but it would always have a static tendency to accelerate & rotate in the preprogrammed direction.  

Speed would use simple acceleration equations & limits.  If the user hits nitro, it accelerates to a certain limit.  Liftoff accelerates to a certain limit.  Hitting a ramp would be a boolean operation rather than a physical simulation of a ramp.  When the player hits the end of the preprogrammed flight path, the game is over.

The game still absolutely would require collision detection.  Godot's collision detection is just a boolean operation.  It can't give the direction of the collision or where in the model the collision happened.  All it knows is if the player hit the side of the track, a player hit another player, or a player hit a ramp.  Collision reactions would have to be about as limited as they were in 8 bit side scrollers.  We can get the vector between 2 players & which side of the track, at least.

If it hits the side of the track, it needs to reverse the velocity perpendicular to the track & constrain the rotation to straight down the track, but the sides aren't parallel to the path.  If it hits another player, it knows the velocity vectors of the 2 players so it can use a simple elastic collision between 2 masses.  The rotation wouldn't change.  The shape of the players would be ignored.  RUD's would have the fragments keep going in the player's last velocity vector while expanding, but bounce off of track walls according to simple collision rules.  It would have a very 80's appearance.

A big problem with rocket simulators is how slow they are compared to car racers.  Elon mentioned in an interview that the starship is going to take off much faster than a normal rocket, so the start could actually be modeled more like a car race while being accurate.