Solar Lander Development Progress

It’s been a long time since the last update of Solar Lander and there is a reason for that:  I am overhauling the various systems and making them more modular and less integrated with each other.  This overhaul will hopefully make it easier to implement new features without having to change a dozen scripts at a time just to get it working correctly.  On the user-side of things, nothing will really change in the coming update.  But behind the scenes, there will be significant changes that will allow me to add stuff without having to worry about whether all the scripts are aware of the changes.

That being said, I am going to experiment with the main game loop that I learned I can access.  I’m taking everything out of that loop that Solar Lander will never be using (3D physics and virtual reality, for example).  I don’t know if this will improve the performance, but I’m going to try it anyways.

One of the few changes that will be noticeable by end users is the way the vehicles behave when attached to each other.  Currently, they are connected together via Unity’s joint system that causes them to fight with each other because the joint solver disagrees with where the vessels should be as they rotate around.  That’s going to be changed so that there are “superstructures”, which are “vessels” that have two or more vessels parented to them.  The superstructure will be able to change the center of mass of the assembly and all of the individual vessels within the superstructure will simply have their Rigidbody components and physics scripts disabled.  This should eliminate the position fighting that goes on when two or more vessels are connected to each other that causes unrealistic rotation behavior on large planets.

On a related note, the orbit and engine scripts currently assume that the vessel’s center of mass is the local origin, and calculates the forces and torques from that point.  In early versions of Solar Lander, this would lead to unrealistic changes in the orbit because Unity would assign a center of mass that was different from the local origin.  It would also induce a slight rotation for the main engine and forward and aft translation thrusters.  To fix these issues, I had the orbit script assign the center of mass to the local origin.  This is also the reason why assemblies unrealistically change their orbit as they rotate.  Now that I’m changing how the assemblies function, it is no longer good enough to assume a fixed center of mass.  As you use fuel, the center of mass of the assembly will change.  So the orbit and engine scripts are being modified to take this into account.  The end result should be far more realistic.

The next change that will affect user experience is how pausing the game will be handled.  The change that’s coming is that the pause menu will always be displayed regardless of whether you press escape or the buttons that you assigned to pause the game.

One of the major changes I’m making to the game that won’t affect user experience is how the lunar module is controlled.  Currently, it’s a module of the ascent stage that assumes that the vessel is attached to will be the one being controlled by the player.  This is the number 1 reason why I haven’t been able to implement multiplayer yet.  There is no way that I know of to get the script to distinguish which player it should take input from.  Anyone in the game would be inadvertently controlling all of the lunar modules at once!  So the control module is being moved out of the ascent stage and will be assigned a lunar module by the server.