New Devlog Series?

I figure I may try something new: A devlog on the first of every month (assuming I remember to do it) to keep players informed about the development progress I'm making for this game. Now, if the first falls on a Saturday, then the devlog will be posted on the second or the third of that month. Again, if I remember to do so. No promises. Also, I simply can't do once a week. Also, assuming that I continue this series, what should I name it?

General Progress Report

So, you may have noticed in a previous announcement that I intend to dump the Unity Engine for the v0.3.x Modding Update. So here's what I have done since making that announcement:

• Create a graphics library for use in my own game engine.
• Create a GUI library for use in my own game engine.
• Update my input library for use in my own game engine.
• Create the game engine core.
• Create a "simple" test app to make sure that the engine works properly.
• Create some splash screen logic.

Here's the video showing off the splash screen that I made: [previewyoutube=HyoJrYrHNSw;full][/previewyoutube]

Physics Update Plans

I've recently been considering making some small (or big depending on how you count it) updates to the v0.2.x Physics Update. These updates would include an updated base resolution (from 800 x 600 to 1024 x 768), and incrementally changing the settings control assignment system to be more in line with how the Modding Update's settings and control assignment system will behave. This of course will still be on the Unity Engine since I don't plan to remove the Physics Update from the Unity Engine. Here's what the new main menu screen will look like.
And for the settings screen, you will get something along the lines of this. Although you will probably find some options outright disabled.
For the control schemes, I originally took inspiration from the gMotor games (such as rFactor 1). And while I am still taking inspiration from such games, the current implementation is simply not good enough for what I want to do for the modding update. So, here's the new controls page:
I've taken inspiration from FSX for this new control assignment layout. The response tab is largely unchanged. But now I can more easily implement new axis assignments, like so:
Every axis will now tell you exactly how it's interpreting your inputs. Note that this is the raw value that the game is getting from the input device. The feedback area tells you how the spacecraft will respond to your inputs. These updates will also move the location where your settings are stored from out of Unity's PlayerPrefs and into "Users\\AppData\LocalLow\TChapman500\Solar Lander". Don't worry, every version of Solar Lander past v0.2.10 (the current version) will be able to convert your settings from Unity's PlayerPrefs. One more thing, these final incremental updates to the Physics Update will help bridge the gap between the Physics Update and the Modding Update, making it easier for the transition to actually happen.

Modding Update Plans

Although I intend for the v0.3.x Modding Update to use my own game engine, none of my libraries are yet made for any platform other than Windows. So I will have to maintain a Unity and non-Unity editions of my game until I can get my libraries working on macOS (currently not supported) and Linux. That's already proven to be "fun". Each edition will be updated individually as I am able to get my libraries working on other platforms. The modding update will include control profiles. So you can load whatever profile you want based on what controllers you have plugged into the system. Profiles will be saved separately from the rest of the settings. Keyboard assignments will be saved as part of the game settings. Button and axis assignments, along with the sensitivity and null zone adjustments, will be saved with the profile along with the joysticks used in the profile.
Another thing that the modding update will bring are stuff like replays and changing the auto save and auto delete behavior. What you see checked in the image below is what the game currently does (except for auto save).
By the way, the Unity Engine uses single precision physics, but my game engine is going to use double precision physics. So until I can get my game engine working on all platforms that my game is available for, you may notice a few things related to the limitations of single precision in the Unity edition of my game that shouldn't be there in the non-Unity edition.

Game Engine Development

In order to take the game off of the Unity Engine, I either have to move to a different game engine (eg: Godot, Unreal) or make my own. I chose the route of making my own. This way, I don't have to worry about any of the bloat from the other game engines (eg: Solar Lander currently runs the 3D physics engine every tick even though it never uses any 3D physics objects) or suspicious firmware that'll bankrupt me. And Solar Lander isn't the only game that I will make with this new game engine. One thing that I started doing is, for each game that I'm working on that'll use my game engine, I've been duplicating a lot of the logic. Bad move. So over the past couple of weeks, I've been moving the logic that I've been needlessly duplicating into the engine core. And I've been refining the logic along the way. Though I still haven't decided if I'm going to implement Lua into the engine core yet.