Progress Update #25

Alpha Complete!

    This week I have kept to deadlines and have a playable alpha version of the game to show for it. It may be the most bare-bones piece of software ever (with some actions only being available through the in-game console) but it met the expectations and I am proud to have made it this far.

Ring System and Atmosphere Editability

    The last real feature that I wanted to add was the editability of ring systems and atmospheres in game. Honestly though, there isn't much to say here about it, it's really just more of the same from the last two progress updates. I made some setters that when called would update the component in real time. 

Atmosphere Settings:

Ring System Settings:

Celestial Player Movement:

    One thing that began to bug me was the limits on celestial player movement. Because of the way I was doing it (that is by linearly interpolating between the current actor rotation and a desired rotation) the player's pitch would be restricted to between straight down and straight up and the roll axis couldn't be used. Since these limits are not applied to real spacecraft, I decided that it needed upgrading.

     I spent a while on several different methods most of which had one of two problems: rolling the craft would not effect the up vector of the actor thus making pitching and yawing effect the wrong axes, or lerping would throw a fit when rotation values reset from 180 to -180. 

    Eventually though I found a perfect solution through the use of Unreal's built in physics. The essence of this solution was to have the root component of the actor be able to "simulate physics" (e.g. static mesh or collision volume. I used the latter) then apply torque to that component to make it spin about an axis. 

    This solution has the added bonus of already acting like thrusters of a space ship in that the faster you move  your mouse the faster you will rotate but that momentum will also persist after you stop the input. I found out pretty quickly though that it isn't too enjoyable to infinitely spin as soon as you touch the mouse. To remedy this I gave the root component an angular damping of 1 so you will stop rotating within a few seconds of ceasing input. 

    With this implemented you can now rotate about all axes and explore the solar system in a more realistic manner.

Loading...

    The final thing I had on my list before calling the alpha complete was to make a loading transition between the main menu and playing the game. This was meant to be time that the terrestrial planets could take to generate their terrain before the player was allowed to play. 

    I'm going to admit right now that the solution that I have for this is very much a rush job and will need to be thoughtfully reworked when more time is available. Fundamentally, the loading system works by first pausing the game so that the player cannot give inputs and nothing will be simulated. Then, the game mode gets an array of all the terrestrial planets and binds a delegate on the planet to a function in the game mode. This delegate is executed when the planet is finished generating. The function that it is bound to then takes the planet that has just finished generating and generates the terrain of the next planet in the list. Finally when it reaches the end of the array it unpauses the game and removes the loading widget from the screen. 

    In hindsight the idea itself isn't bad, just that for time's sake I jammed all this functionality into the game mode without taking the time to think through ways to better structure the system. Here's what it looks like though:

Day-One Bug Fixes:

    When I had proclaimed the alpha complete, I packaged the project, ran it, and came face to face with about the worst possible dialogue screen:

    A fatal error that immediately crashed the game (I actually had another error that just said "Fatal Error!" but I couldn't find the picture of it). I went into debugging when, by a series of random events, I found that when an Unreal game crashes like this it actually puts the call stack into the clipboard without telling you. This information ended up being very vital to fixing the problem. There ended up being a few places where I forgot to check that a value wasn't nullptr before using it, but fixing those solved the crashes. Here's what happed when I pasted it into a text document if you're interested:

    I also had some visual issues with how the planet settings were being rendered. Some elements were being rendered very dark and blended into the background. The most notable of the effected are the arrows of expandable areas.

Here's how it should look:

And here's what it looked like:

    The same thing happened with check boxes but I was able to fix it by changing the foreground color to not be inherited and setting the color to white. Though I haven't been able to fix the expandable area because it doesn't have a foreground color option. This is apparently an engine bug that has existed since version 4.16 and happens when the effected widget is a child of a button (bug tracker). With the main part of the planet highlight being a button, I can say that this is probably the culprit of the problem. 

Concluding Thoughts:

    I will continue to test for bugs and hopefully have a very stable build within next week. I also plan to setup an itch.io page for the game sometime next week so that anyone (with a windows machine) can play the game without having to build it from source. From here I will also need to plan out the features for the beta release that I'm aiming to have around mid-July.