Project Logs

Collapse

• Constant gravity

  lion mclionhead • 03/23/2022 at 08:04 • 0 comments

  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...

  Read more »

• Anti gravity racers

  lion mclionhead • 03/16/2022 at 06:45 • 0 comments

  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.

  This one looks real good, but seems rather boring.

  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.

• Unity update

  lion mclionhead • 03/01/2022 at 07:13 • 0 comments

  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.

• Moving & sliding

  lion mclionhead • 08/09/2021 at 05:04 • 0 comments

  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.

• Godot 3.3.2

  lion mclionhead • 05/14/2021 at 21:32 • 0 comments

  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.
  

• Unity editor for Linux

  lion mclionhead • 07/17/2020 at 18:52 • 0 comments

  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.  
  

• Godot physics secrets

  lion mclionhead • 04/09/2020 at 06:33 • 0 comments

  The general idea is the top level physics object is a rigidbody or a staticbody.  The rigidbodies move & the staticbodies are stationary.  The rigidbody itself doesn't interact with anything but gravity.  It has a bunch of collisionshape children which define the shape which interacts with other objects.  The collisionshapes are just meshes.  The collisionshapes are held in the same relative positions by the rigidbody, like a real solid.  The collisionshape geometry determines if the rigidbody rolls over, stands upright, behaves like a ski, a wheel, a leg, or gets stuck.
  

  The rigidbody contains physics parameters which apply to all the collisionshapes, so all the collisionshapes need to have the same mass.  Each collisionshape has a shape variable which points to its mesh.  The shape member can be created by the shape menu, importing a -col object from blender, or assigning the shape variable in gdscript.

  
  The rigidbody has a center of gravity defined by its pivot point.  The CG determines if it's self righting or constantly rolls over.  There is no way to set the pivot point like there is in blender.  All the collisionshapes & meshes in the rigidbody need to be individually repositioned to change the CG.  To simplify matters, a model should have spatial as its top node, a rigidbody directly under that, & a single child node under the rigidbody containing all the visual meshes & collisionshapes.  This allows the model to have an arbitrary pivot point for placement in the scene, its CG can be a different pivot point, & its meshes can be another pivot point.

  Helas, only spatials can be grouped inside another node.  The collisionshapes have to be directly inside the rigidbody & all moved individually.  At least you can shift select all the rigidbodies & move them at once.

  Godot menus confused the hell out of lions.  When a godot menu item says "new...", "new BoxShape" or "new SpatialMaterial", it doesn't create multiple objects or leak memory like new in C++.  It just replaces whatever object was already there.  The menu title causes the options for the current object to be displayed.  The down arrow allows different objects to be created.
  

  Your biggest ally in the war on Godot is the "expand all properties" menu item.

  Getting back to rigidbody,

  rigidbody.sleeping

  rigidbody.can_sleep

  These have to be off until liftoff, to keep players from falling uncontrollably to the launchpads & falling over.

  rigidbody.physics_material_override

  Create one of these to set more properties.

  PhysicsMaterial.bounce

  How much the object bounces.

  PhysicsMaterial.absorbent
  

  Seems to turn off all bouncing.  Now, it just gets stuck when it hits the wall.  

  A big problem is the global_transform is required for calculating look_at angles & gravity vectors, but it's only available in the _process function.  Procedurally generated models have to be created in the _ready function, but anything requiring global_transform has to be done in _process.  The distributive property doesn't apply when multiplying transforms by vectors, either.
  
  
  
  

• Physics simulation

  lion mclionhead • 03/12/2020 at 06:43 • 1 comment

  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 &...

  Read more »

• Overlays

  lion mclionhead • 03/04/2020 at 07:02 • 0 comments

  The overlays would go on the bottom for a PC game & the top for a mobile game. The lion kingdom discovered despite the boom in mobile gaming 5 years ago, most gaming is still done on a PC.
  
  
  This exercise revealed how Godot renders the glyphs in a fixed point size & then scales the output instead of scaling the point size.  It looks so awful, all text really needs to be in a separate layer from the graphics, with a manually scaled point size to look good. 

  An interesting video surfaced of convincing graphics in Kerbal space program.  The only environment map is the stars.  Godot uses the environment map to draw reflective surfaces, so that wouldn't work on the ground.  They use a 2D plane for clouds.  The planet is a very large mesh with levels of detail.  The atmosphere could be a 2D texture behind the planet.  They use particles for some clouds.  They use a fog effect, but only on the planet.  Godot can't apply fog to just a planet.  Lions don't want to port the entire scatterer library.

  The lion kingdom has realized without seriously cutting down the graphics, nothing is ever going to happen & the growing amount of investment will be wasted.   So it sometimes feels like a toy project with an indefinite finish date, decades in the future & sometimes feels like a disaster.

• More track design

  lion mclionhead • 01/19/2020 at 08:17 • 0 comments

  The journey began with 2 paths for the 2 sides of the track.

  An automated script converted the paths into K barriers for the track.

  The mane idea is Asphalt 9 had resorted to K barriers to define more detailed tracks inside its existing maps.  

  So we would define the entire track with K barriers.  A procedurally generated collision plane would span between the K barriers.  An invisible boundary beyond the barriers would cause the player to go out of bounds while still letting them jump beyond the barriers a certain amount.

  Player control would be limited to just sideways & require ramps to jump.  The horizontal collision plane, K barriers, & jumps would dictate vertical movement.
  

  The trick was automatically generating the collision planes with the least amount of information.  After staring at the model & trying many algorithms, finally figured out the track needs a 3rd line, a direction line to tell the computer what direction the track is pointing. The 2 sides aren't always parallel to the track's direction. With the direction line, it can properly create the right plane between the 2 sides. Without the direction line, there are many possible planes. The direction line also allows the track to do barrel rolls & loops in 3 dimensions.

  This was the minimum amount of information required to automatically generate a 3D track with barriers & out of bounds areas.  A few sputtering development sessions while commuting yielded

  some decent results, at least in model form.

  Lions sadly don't like programming games, even though they like the outcome. They're just throwaway content like movies, they don't enhance productivity, but they do make the world a better place. People play through the campaign & throw them away. Making a game stay useful requires constantly expanding the campaign, just like constantly making new movies.

  Making the world a better place foremost requires enhancing productivity. It's surprising that peasants in medieval times only occupied 90% of the population, while 99% of today's population would be considered equivalent to peasants since all of our income is eventually consumed by those above us, whether it's through the healthcare system, housing, taxes, inflation, alimony, or our funerals.

  We have less leverage than 800 years ago because we're less productive relative to the top 1%. It's much harder to be a google or a facebook than it was to grow food. Creating economically competitive software is ironically not as attainable as we thought it would be.

View all 17 project logs