A game about a certain space exploration company

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.

The hangar was bad, but it was here that the downsizing of expectations became extreme.  The mane problem is a 3D flight simulator is just too boring.  All the racing games have evolved towards a 2D track in a 3D world.  The user input for BFR already got degraded to 2D.  Lions are conditioned to want to race in 2D from years of hunting for food on the African plains.

The 1st idea was automating the race course generation from a simple line drawing, the way tuxracer did it.  

https://www.youtube.com/watch?v=UL-KrmlQBZk

It didn't have a formal track, but required the player to catch fish in an open world littered with obstacles.  The limit was it had a constant elevation grade superimposed on a local elevation defined by the greyscale. Tuxracer looked really good for its time, but flying required more 3D flexibility. 

Even an indie game like GRIP looks better than tuxracer.  That led to needing a full sized 3D model. 

A good race course needs:

3D clouds

3D stars

nitro bottles

track arrows

track collision borders

asteroids

obstacles

environment maps for sky & space

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

The current gold standard for clouds is XPlane. No example in Godot
comes close & you would need to be a dedicated mathematician to invent
that from scratch.

The only godot example of 3D clouds was the terrible

https://gitlab.com/arcane_hive/terrain-generator-godot

There was an excellent cloud generator for Unity

https://github.com/SebLague/Clouds

While it may seem like Godot is all paw coding of shaders, Unity also requires a lot of paw coding of shaders.  They depend on very slow 3D textures & ray tracing.

The XPlane clouds might actually be still photos, in which case lions might be better off just photographing clouds & stuffing them in 2D rectangles.

Tuxracer just used a 2D texture for trees & it looked pretty good.

Stars may similarly be good enough as 2D textures

A 1st attempt using arrows to define a 2D track was really boring.  Devising the route has devolved towards just copying other racing games.

The track collision shape can similarly be based on the track line drawing.

There's sadly no tool for making environment maps.  Godot examples all just copy the existing ones from hdrihaven.com.  Making something appear to transition from ground to space requires custom environment maps.

The lion kingdom still goes back & forth between the tuxracer design & full 3D modeling.  The track has ended up just 2D with a constant elevation grade because the arrows are 2D.  Real spaceships don't fly 3D paths either.  They all fly in a 2D plane.  The trick is the 2D plane is vertical & the starting line needs to be vertical.  Any maneuvering in a real rocket is just in altitude.  

The mane mac bug is they tried to implement acceleration based navigation but failed.  The acceleration part either doesn't refresh completely or switches to rotation partway through the animation.  This makes navigation crosstalk between rotation & translation & studder.

The result is navigating is nearly impossible on a mac.  On Linux, the acceleration is implemented properly, so the crosstalk & studdering doesn't happen.  Ideally, there would be no acceleration on any platform.

On the mac, antialiasing & reflections are much faster than Linux.  Godot drops key release events on Linux, making keyboard input during a slow framerate impossible.  

Reflections from other nodes are horrendous on any platform.  It looks worse than Doom 1.  The only way to get remotely acceptable reflections is to make an environment map of the hangar.  Environment map reflections in godot are acceptable.  No-one has ever made an equirectangular projection from a godot scene.  They  only did it in Blender.  The real BFR may not be shiny at all.  

Like polygon editing, there's no textual documentation on the subject & only random bits of information on video.  It wasn't possible at all to get anywhere with Blender before gootube took off in 2010.  Many functions are only accessible by the keyboard.  What you want is a workflow, but no videos were giving that.

The decision was made to just watch videos & write as many notes as possible.

In the UV/Image editor:

Selection of UVs works the same as edit mode.  The selection mode uses different icons which change depending on the "keep UV & edit mode selection in sync" button.

"keep UV & edit mode selection in sync" has to be enabled & face selection has to be enabled to do anything useful.  Selecting edges or vertices causes it to ignore seams & treat the faces as linked.  Only selecting faces allows UV islands to be moved independently.  This is a huge bug.

c circle selection

b box selection

UVs -> mark seam - make the smart UV mapper not keep faces next to each other.  Marked seams are shown as red in edit mode.  The seams create UV islands.

ctrl-l select linked faces in the texture

g,r,s - translate, rotate, scale

e - extrude

x,y,z - typed after the g,r,s,e to restrict movement of g,r,s,e to X, Y, Z axis

numerical entry: typed last after g,r,s,e.  depends on whether it's in translate, rotate, or scale mode

0 - for translating, make UV's equal on the axis movement is restricted to

 - for scaling, scale it to the value entered

 - for rotation, set rotation to the angle

There's no numerical entry textbox for UV's like there is for mesh editing.  The textbox which appears when transforming UV's just affects the mesh.

UVs -> pack islands - line up the UVs with the edges of the texture to maximize the space usage.  Only aligns 2 edges since it doesn't alter the aspect ratio.

UVs -> show/hide faces -> shift-h hide unselected

UVs -> export UV layout - generates a PNG with the UV coordinates outlined

There's no way to dial in any coordinates.  Your only option for precise alignment is snapping to a grid.

There's no magic way to tile textures.  Just extend the face beyond the edges of the texture.  It's a nightmare for every large faces.

Eventually a workflow emerged, which involved defining seams to create UV islands, unwrapping each island separately onto its own area of a texture, exporting the UV layout, & drawing in Gimp.  The drawing ended up relying on the path tool, what Disney hottie called the "pen tool", the gradient tool, & the selection tools.  

The mane drawing workflow is to create a line using the path tool & stroke it in a certain brush or make a selection with the path tool to restrict the gradient & fill operations to a certain area.  


The path tool & gradient tool are the mane differences from the lion kingdom's last involvement in 2D drawing, 30 years ago.  30 years ago, computers had no greyscale so there was no gradient tool.  PC paint had only a 3 point curve tool, which lions used extensively.  The modern path tool is the evolution of that curve tool.

Early paint programs were all designed to be pixel accurate.  A mane problem with Gimp is it's not designed to be pixel accurate.  The xored marching ants & brush outlines from vintage programs are now 3D outlines & no brush indication.  There's no longer a grid showing the location of every pixel when zoomed in.  Having a hardware cursor seems to have made programmers not want to provide a software cursor of any kind.

Between PC Paint & modern tools, there was an object oriented drawing craze involving Adobe Illustrator.  The beauty of object oriented drawing was being able to adjust any operation later without redrawing everything.  When 24 bit color & pressure sensitive tablets came along, it might have been too computationally intensive even today to make all those nuanced operations non destructive.

After 2 months, that was the best a lion could do.  There's always room for more details, like tracks in the floor for the rocket stands, tool boxes.  Navigation is not as easy as the smaller models in Asphalt.  Translating around the walls of the hangar works.  The camera needs a smarter algorithm than always pointing towards the center.  The stainless steel reflects the environment map instead of the hangar.

Reflecting the polygons in godot requires adding a worldenvironment, enabling ss reflections.  It's extremely slow & looks terrible.  Asphalt 8 manages to do it fast.

It occurred to the lion kingdom that the race course should be a 2D route through the upper level winds.  The winds would have to be rendered like land masses or clouds.  The space section would have to be a route through a dense sea of stars.  The only way anything can be playable is if it's very artistic instead of accurate.  It definitely has to be 2D to work on a tablet.

It occurred to the lion kingdom that with Musk now caught up in John Green books, the name BFR is free & clear, so the thing should be called BFR.

Working on the game makes lions want to play Asphalt 9 & reminds them of commuting, since most of the work is done on a train & the game is based on Asphalt 9.  This results in wasted days playing Asphalt 9 to avoid being reminded of commuting.

The godot editor is so bad, a key requirement is a way to freeze the game & view from arbitrary cameras.  The camera previewer in the editor is non functional & most of the models are synthesized in the game.  

Introducing textures

The garage scene in Asphalt XTreme uses textures heavily to simulate polygons.  The shadows aren't even drawn very accurately, but it still works.  

Thus, when it came time for the hangar scene in BFR, lions were woefully unprepared to make the custom textures.  It's ironic that animals who did much paper drawing & struggled transitioning to 3D models now have a hard time with the 2D drawing required to make textures.

To someone who was alive over 40 years ago, modern paint programs are better for editing photos & terrible for drawing 2D.  Compare this to millenials who can't imagine drawing anything on paper & make big bucks drawing 2D on computers.  There is a millenial trophy wife showing that professional art is drawn electronically, but not showing any tutorials.

https://www.youtube.com/channel/UCS3ZMbzTOXdDuJlhAZuXgaw/videos


The computer interface definitely limits it to a certain style.  Surprising how much TV art is 2D & computer art has evolved from 3D to 2D as they've learned how to make better interfaces.  

It doesn't remember the inspector state or undo history when navigating between windows.  The inspector resets to the top level node & you have to navigate back down to where you were, after every window change.  Navigating in the inspector is otherwise hellish.  

Down arrows sometimes give you a menu, sometimes expand an area.  A text box or image may or may not expand another level or replace the inspector with another window, with no indication of what is a child of what.  Left & right arrows try to ascend & descend history, but the history is usually lost from a window change.

Textboxes randomly stop accepting input & the program has to be restarted to continue typing,  navigating all the way back to where you were from the top.

There's no way to copy nodes from 1 scene to another, but there is a way to copy nodes in a single scene.  Unfortunately, multiple particle generators in the same scene overwrite each other in random parameters.  Wrapping particles in different scenes still experience crosstalk, so they have some global variables & widgets which aren't being updated when you change windows.  Editing a textbox in 1 particle node will usually overwrite a parameter in another particle node.

The bugs led to a gdscript particle system for engine flame.  

Settings are randomly split between flags & parameters.  View settings are split between a view & a perspective menu

Hiding the indicators for window resizing to comply with the modern convention is a pain.  The modern convention is endless mousing over to reveal hidden widgets instead of just drawing the widgets, making a lifestyle out of everything instead of just making it work, as millenials call it.

The active textbox in the inspector gets stuck in the same place, on top of everything else, when scrolling.  Dragging from a listbox makes the source listbox scroll instead of the destination, so if you drag the same item multiple times, you have to rescroll the source listbox every time.

Despite all the options, there was no way to have a starting velocity for radial movement.  There is an accel curve which can replicate engine exhaust.  Naturally, the accel curve is an artistic bezier curve editor with no printout of numerical values.

Got somewhat of a liftoff, with much crosstalk between particle generators.  Didn't bother tracking down all the sound credits.

1 thing that worked was making the particle nodes always face the camera, to create fake volume.  It's done by 1st looking at, then resetting the 2 fixed eulers.

var defaultSmokeTransform = smoke.transform

    smoke.transform = defaultSmokeTransform
    var euler = smoke.transform.basis.get_euler()
    smoke.look_at(camera.global_transform.origin, Vector3(0, 1, 0))
    var euler2 = smoke.transform.basis.get_euler()
    smoke.set_rotation(Vector3(euler.x, euler2.y, euler.z))

   var scale = defaultSmokeTransform.basis.get_scale()
    smoke.transform.basis = smoke.transform.basis.scaled(scale)

They did a good job recreating the animated look & simulating what a character in the show would see, but it's extremely boring. Notice the use of crosses & dynamically generated models to draw the smoke trails. The explosions could easily be quads with animation inside textures. 

Been away, but now it's back with an emphasis on low fidelity.  The amount of work involved in making it photo realistic is immense enough to be satisfied with 1984 quality graphics.  

Countdown by reversing & tracing the spacex logo.

Somewhat of a 2D exhaust plume from a particle effect.  No lighting.

The flame in Asphalt wants to be another particle effect with stretched particles.  There's no smoke from methane engines.

Every time lions play Asphalt 9, it's inspiration to revisit this.  The mane problem is creating the same entertaining gameplay & map in a flight simulator that is possible in a road racer.  The other problem is making it something lions are going to use every day.  Lions can play Asphalt 9 every day, even though there's no point.  There's no way to advance & there isn't any challenge, but it provides engagement with a physics system & sensation of speed.

Most often, a solution randomly happens to be found, like the so called "better collada exporter" on the godot page.  There's no indication of what it is or that it's a .zip file, but it actually is a plugin someone randomly put on the godot page & it does slightly better with some of the normals.  Exporting the most basic 3D data like normals is hit or miss.