Fortitude – Prototype 0.5.5 – Patch Notes

If you’re wondering what happened to Prototype 0.5, please see the Weekly Walkthrough for Week Twenty Two.

The “One Small Step For Man” Update

This update adds an important new mechanic into Fortitude; planetary landings! The player can now approach Elcalowda (the current testing planet for the landing mechanic), get into orbit and then manouevre downwards into its atmosphere to trigger the “landing” mechanic. Additionally, gravity and planetary orbits have been overhauled and majorly edited, and the game Map has received some small updates.

0.5.5

Additions –

  • Added GameObjects –
    • Added placeholder “ElcalowdaSurface” GameObject (Polygon Collider 2D) –
      This placeholder GameObject acts as the “surface” of the “Elcalowda” planetary body. The player can now land on and takeoff from this GameObject as a result of the “OrbitTransfer” script.Three empty GameObjects have also been parented to “ElcalowdaSurface”, surrounding the GameObject in a square shape. Each empty has an On Trigger Circle Collider 2D attached to it. The roles of these are explained in the “OrbitTransfer” script section below.
    • Edited “Fortitude” GameObject (Rigidbody2D, Box Colliders 2D) –
      This edit upped the “Mass” of the ship’s Rigidbody2D from 1 to 2. This change increases the amount by which the ship is affected by the “OrbitSystem” script’s gravity system as well as generally slowing down the forward and rotational movement systems of the “Fortitude” ship.
    • Edited “Elcalowda” GameObject (Rigidbody2D, Circle Collider 2D, Line Renderer, Trail Renderer) –
      This edit increased the size of the “Elcalowda” GameObject by a factor of 10 and added an On Trigger Circle Collider 2D. The size change was made in order to test how making the planets bigger would impact gameplay (hence only increasing the size of one world). The result was that it made orbiting and subsequent landing slower and more interesting, so in the next update it is likely that all planetary bodies in the game will receive this treatment.
    • Edited all “Planetary Body” and “Moon” GameObjects (Rigidbody2D, Circle Collider 2D, Line Renderer, Trail Renderer) –
      This edit removed the “OrbitSystem” script from each of the game’s planetary bodies and their moons (including Diadem, Elcalowda and Moon, Rika and Moon and Estabahn) and replaced it with the previously created “Asteroids” script. This change essentially removed the unreliable gravity-based orbits from the planets, and placed them on “rails” instead, using transform.position and transform.RotateAround functions to rotate them around the “STAR” GameObject instead. This change made making the “Planetary Bodies” orbit properly a far easier task, as well as the edit-ability of their subsequent orbital pathways.

 

  • Added Scripts –
    • Added “OrbitTransfer” script –
      This script is the coding backbone of Prototype 0.5.5, and is attached to the “Fortitude” GameObject. Now, upon entering the On Trigger Circle Collider 2D of the “Elcalowda” GameObject, the player will be transported (via transform.position) to just above the location of the “ElcalowdaSurface” GameObject. As this occurs, the gravityScale of the “Fortitude” is increased to 0.25, and a “Distance” variable appears, a number that represents the distance between the player’s current location and the surface of “Elcalowda”. The player can then “land” on the surface, providing they touch down with a velocity that is less than 10. Upon taking off from said surface, after a time and distance the player will collide with another On Trigger Circle Collider 2D (attached to the three empty GameObjects), and will then be transported back to just above the “Elcalowda” planetary body. This script is currently only applied to the “Elcalowda” GameObject, but can and will be applied to the other planetary bodies in a future update.
    • Edited “SpeedGUI” script –
      This edit adds the new “Distance” variable to the game’s HUD, however it only appears when the “inPlanet” boolean is enabled, which is only true when the player is initiating a landing on a planetary body.

 

Bugfixes/Improvements –

  • Conducted an improvement to the game’s planetary landing and takeoff mechanics. In Prototype 0.5, this mechanic was achieved by (upon colliding with the On Trigger Circle Collider 2D of the “Elcalowda” GameObject) loading a brand new scene with the “ElcalowdaSurface” GameObject and altered “Fortitude” gravityScale already in place. Prior to scene loading, a script entitled “PlanetaryLanding” took the last known variables of the “Fortitude” GameObject (including velocity, angular velocity, rotation and position) and applied them to the new “Fortitude” in the new scene, to give the false impression that no transition had taken place.
    The problem with this coding method however arose when attempting to cross the player back over into the original “Universe” scene. While Unity could find the “Fortitude’s” original variables and apply them once more (so to place the ship in its last position prior to “landing”), it could only do so because the “Fortitude” was present in both scenes. It could not unfortunately take and apply the various planets’ variables, as they are not present in the second “landing” scene. Therefore, upon reloading the original “Universe” scene the “Fortitude” would be in the right place, but the planets would not be.
    It was for this reason and various others (including overly complex code, multiple scenes becoming complicated and general lack of expertise) that Prototype 0.5 was abandoned, and subsequent update 0.5.5 used the “teleporting the player away for landing” method for the “landing/takeoff” mechanic instead.
  • Fixed an issue where the “Tether” script would display a visible “tether” between the “Fortitude” and “OnFoot” GameObjects while the game was playing in the Unity Editor, but would not display said “tether” when the game had been fully rendered out into an .exe file. This was caused by the “Tether” script using a Gizmos.DrawLine function to physically draw the “tether”, which as I came to discover serves as a bugfixing function, and therefore is not displayed in the full rendered game. This was fixed by replacing said Gizmos.DrawLine function with a LineRenderer function, which thankfully now does draw the “tether” between the ship and astronaut in the full rendered game.
  • Fixed a bug where the “Fortitude” GameObject was not destroyed upon colliding with the “ElcalowdaSurface” GameObject at a greater velocity than 10. This was caused by an oversight on my part where I did not change the “ElcalowdaSurface’s” tag from “untagged” to “space”. This was fixed by applying said tag to the GameObject, so that the “shipDeath” script could then apply the “Destruction” function upon colliding with something at a greater velocity than 10.
  • Fixed a bug where the “Fortitude” GameObject would begin to and continue to visually “glitch out” upon colliding with the On Trigger Circle Collider 2D of the “Elcalowda” GameObject and being transported via the transform.position function. The exact cause of this bug is unknown, although it is suspected to be something to do with the (at the time) vast distances between the “Elcalowda” and “ElcalowdaSurface” GameObjects, which was a good 50,000 units. This was fixed by bringing the “ElcalowdaSurface” GameObject much closer to the game’s Solar System, and adding a function that disabled it (so that it is not visible just hanging in space) until the player is transported there for the “landing/takeoff” mechanic.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s