Close
0%
0%

A game about a certain space exploration company

Where most of 2018 went

Similar projects worth following
This was conceived as a way for lions who weren't smart enough to actually work on a space program to get involved, in some way.

The original idea was to make a racing game out of a full spaceflight simulator with orbital mechanics.  Some development proved it would be a very slow & boring racing game because of the high velocity changes & precision involved in real orbital mechanics.  Most of a real spaceship's life is spent coasting in an oval.  Velocity changes take months.  They have to aim for millionths of arc seconds.  Time would have to be sped up & slowed down at various times.  There would have to be a contrived race track with obstacles.

Because of the time warping required, a racing game based on a real spaceflight simulator would look like a yoyo, with the players quickly zipping around the solar system every few seconds.  Instead of controlling XYZ position, the players would control inclination, major axis, minor axis, & phasing.  Instead of turning a steering wheel to change direction, they turn the vehicle with prograde & retrograde engine burns.  They'd position for gravity assists & aerobraking, multi year operations that would be sped up to only a few seconds for gameplay.

In the goofy world of highly sped up orbital mechanics, the big rocket with all its fins, engines, & windows is just a titillating detail rather than something whose design impacts the game.  It would be more of a strategy game, without the appeal of arcade racing.

It was going to be a racing game no matter what, but to make it interesting, it would be a kind of "rail shooter".  There's a track guiding the player through a 3D space, where player input is restricted to just left & right on the track.  The track has jumps which allow some movement in 3 dimensions.

Modern games do a few other things to retain attention.  They have a fuel gauge system.  Each game consumes from the fuel gauge until players have to wait for it to refill.  Once it's full, it stops filling until they play again.  It's not about keeping them from playing as much as creating opportunity cost for not playing.  

Finally, modern games have multiple rewards: credits, tokens, & cards.  Credits are the easiest to get, determined by player ability, & create the least progress in the campaign.  Cards are the hardest to get, are usually drawn randomly, & create the most progress in the campaign.  You can't normally exchange 1 type of reward for another.  The multiple reward system might be to allow a much wider range of difficulty than multiplying the price in credits by a billion.  The campaign takes longer & keeps you engaged.

  • Unity editor for Linux

    lion mclionhead07/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 mclionhead04/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 mclionhead03/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 mclionhead03/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 mclionhead01/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.

  • Race course design

    lion mclionhead11/21/2019 at 17:31 0 comments

    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.  

  • Godot bugs

    lion mclionhead06/15/2019 at 04:48 0 comments

    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.  

  • UV mapping in blender

    lion mclionhead05/28/2019 at 00:01 0 comments

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

    Read more »

  • Gameplay

    lion mclionhead05/12/2019 at 08:14 0 comments

    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.  





  • Godot is a hard program because

    lion mclionhead04/24/2019 at 17:15 0 comments

    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. 

View all 12 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates