Solar Lander News

[p]After taking far longer than I had intended, I finally have a good plan for ending Early Access. And it involves having 1 or 2 more updates in Early Access. If there's just one more update left within Early Access, then it's going to be the Modding Update (v0.3.x) followed by the Release (v1.0.x). If there will be two more updates within Early Access, then the first of these updates will be the Modding Update (v0.3.x) followed by the Multiplayer Update (v0.4.x) before finally getting to the Release (v1.0.x).[/p][h2]Modding Update (v0.3.x)[/h2][p]Currently, I'm working on the Modding Update. This update will give an official means for users to add their own content and game modes to the game, without changing the vanilla experience. And I am very close to having a solution for Solar Lander to load mods and make them playable. I will leave the details to future devlogs though. But here's what to expect if the Modding Update is the last update before release, and what to expect if the will be one more update after the Modding Update before release.[/p][p]Either way, here's the bare minimum of what to expect from the Modding Update, with the rest of the features I originally planned for the Modding Update being added eventually before release.[/p]

• [p]Create your own spacecraft and possibly non-spacecraft physics bodies.[/p]
• [p]Write your own game modes.[/p]
• [p]Publish your mod to the Steam Workshop or host it elsewhere.[/p]
• [p]Make mods that reference other mods.[/p]
• [p]Create control profiles that can be shared through the Steam Workshop or hosted elsewhere.[/p]
• [p]Add your own music to the game (I currently have no plans on adding any default music ever).[/p]
• [p]Built-in level timers for stuff like speed-running.[/p]

[h3]Last Update Before Release[/h3][p]If the Modding Update is the last update before release, then it'll have multiplayer built-in. It will also have all of the features related to modding that I want to include before release, including:[/p]

• [p]Write your own flight computer programs.[/p]
• [p]Write your own terrain generators.[/p]
• [p]Make complex scene graphs with animations and state switches.[/p]
• [p]Make multiplayer game modes.[/p]
• [p]Add your own planets.[/p]
• [p]Add atmospheres to your planets.[/p]

[h3]Second-to-Last Update Before Release[/h3][p]If the Modding Update is not the last update before release, then there will be a number of features missing from the modding update that will be included in eventually before the release. These include:[/p]

• [p]No ability to make any type of scene graph.[/p]
• [p]No multiplayer game modes.[/p]
• [p]Probably no planets with atmospheres.[/p]

[h3]Modding Tools[/h3][p]The Modding Update will contain at least one tool from the moment the Modding Update hits the Beta branch: A command line utility to convert MSH files to Solar Lander models. Details on that will be in a future devlog. As the modding update progresses, more tools will be added, mainly along the lines of making model files for the game.[/p][p]A second tool that I intend to include from the moment the Modding Update hits the Beta branch is a tool for packaging your mods. Although this will probably later be included within the game itself, especially for publishing to the Steam Workshop. If the mod packaging tool isn't included from the start, it will be included by the time the Modding Update hits the main branch.[/p][h2]Multiplayer Update (v0.4.x)[/h2][p]If including multiplayer functionality in the Modding Update will make it too big, then multiplayer will get its own update. If this happens, then the Multiplayer Update will also get some of the features that the Modding Update didn't get. How many features it gets in relation to modding depends on a few things that I haven't decided on yet. But here's what the Multiplayer Update will focus on specifically:[/p]

• [p]Multiplayer game modes implemented exclusively through mods.[/p]
• [p]A mod will be added to the game featuring a couple of example game modes.[/p]
• [p]Possibility of using peer-to-peer and server-client architectures.[/p]
• [p]For servers, the ability kick and ban players, whitelist players and/or require passwords.[/p]

[h2]Release (v1.0.x)[/h2][p]The 1.0 release will contain all of the features that may have been left out of the previous updates. In addition, there is a master list of features that the community has requested, and I intend to implement most of those. If the community feature requests don't get into any of the other two Early Access updates, they'll also be included in the 1.0 release. In addition, I want to include the following:[/p]

• [p]A built-in tutorial mode, with either a voiceover, popup boxes explaining things, or both.[/p]
• [p]A built-in sandbox mode that has menus for adding and removing objects from the scene, and changing object state.[/p]
• [p]A built-in story mode that's more complex than just landing on barren planets and jumping back into orbit.[/p]
• [p]A system to switch to/from "on-rails" orbits when it time acceleration to improve time acceleration performance.[/p]
• [p]Eliminate all unnecessary elements from the game's player loop, further enhancing performance.[/p]
• [p]A better Command Module AI that will make it much harder to crash the vehicle.[/p]
• [p]More levels in the progression mode.[/p]
• [p]Achievements for the Tutorial and Story game modes.[/p]
• [p]Possibly have achievements for multiplayer.[/p]

[p]To summarize, the Early Access updates will focus mainly on adding functionality to the game. But the release will focus mainly on adding content and whatever features are leftover from the Early Access updates to the game. Some of the items that are listed here for the release may actually be added in the Modding or Multiplayer updates.[/p][h2]Post Release Updates[/h2][p]I currently have no plans for any post-release updates other than bug fixes and security patches. But I am looking at the possibility of releasing Solar Lander on other game stores. Mainly, once the Release comes out, I will consider this game finished and will move on to making other games and projects.[/p]

In light of recent news of a security exploit in Unity, I have rebuilt the latest version of the Physics Update (v0.2.14) with an updated version of the Unity Editor that I'm using for this project. The demo version has also been updated.

Note that I am not able to apply updates to the "physics-update-playerprefs" or "pre-physics-update" branches. If you want to play on those historical branches of Solar Lander, then you should apply the patch that Unity has provided. But "physics-update" (non-playerprefs version), "beta-build", and "default" branches have been updated with a clean build of the game.

[p]In a previous Devlog, I gave a few details about how mods will work in the upcoming Modding Update (v0.3.x). In this Devlog, I'll go into a bit more detail, since I now have more details worked-out. Specifically, I've been working out details for mods that add spacecraft to the game.[/p][h2]The mod_info.ini File[/h2][p]The mod_info.ini file will contain a list of spacecraft files used by the mod. This will save on processing power by not requiring the game to have to figure out what each file is used for. There will be a "CraftCount" (or similar) field, possibly in a "Content" section of the file (not final yet), followed by a "Craft_X" field (where "X" is a number starting a zero) for each craft file in the mod. Each craft file will be its own .ini file, with Craft_X having the name of the file without the extension.[/p][p]It will probably be the case that one does not have to list every craft in the "Craft_X" field. For example, craft that can't be controlled directly probably shouldn't be listed. Extra crafts may be referenced elsewhere in a mod package (eg: stack assembly instruction files).[/p][h2]The CraftName.ini File[/h2][p]Each craft will have its own INI file, which will contain the display name for the craft, the craft description, craft properties, and references to other files. These references will be to shared configuration files, mesh files, etc.[/p][p]Craft INI files will define engines, RCS thrusters, docking ports, and everything else used by the spacecraft that is exclusive to that spacecraft. It will reference other INI files that are shared between multiple spacecraft. Each component can reference its own mesh file.[/p][p]The craft's INI file (or referenced component INI files) are responsible for defining compatibilities between different types of components. For example, in a staging stack, an engine bay may have a width parameter, and an engine must have a width that is less than that of the engine bay to be considered compatible by the game.[/p][h2]The Mesh File[/h2][p]The Modding Update is doing away with the sprite-based graphics that are currently in the game in favor of vector graphics. So each spacecraft will have a mesh file that represents both the visual graphics of the craft as well as the collision geometry. The mesh files will support levels of detail, animations, possibly state switches, but not textures. Each mesh within the file will instead be a solid color. This means that the gradient on the command module is also going away.[/p][p]There will be one mesh file for the craft body, and one mesh file for each component on the craft separate from the body (eg: the RCS Block). It might possibly also support having all of the components in a single mesh file, with the craft's INI file referencing specific items within the mesh, but I haven't yet figured out how I'm going to do that. Mesh files will also be used to define rocket exhaust. This is probably where animations will be most frequently used.[/p][p]Currently, to make the mesh files, I'm going to be exporting the mesh I create in a 3D modeling program to a text-based mesh file, and write a program to convert it to Solar Lander's mesh format. I'm basically going to modify the program for the specific needs of each mesh file and later build a utility that can create any type of mesh file that will ever be needed.[/p][h2]Audio Files[/h2][p]Craft INI files can reference audio files, which are used for stuff like alerts, engine sounds, and crash sounds. Of course, these won't be the only audio files used in mods.[/p][h2]Stack Assembly Files[/h2][p]A stack assembly file will define how multiple crafts are attached to each other. They'll attach spacecraft together through both stage connectors and docking ports. I haven't worked-out all the details yet. Craft INI files will probably have a "DefaultAssembly" file reference though. I also intend for game mode scripts to be able to reference specific stack assembly files.[/p][h2]Referencing Other Mods[/h2][p]So that one does not have to define absolutely everything, I'm going to implement a system that allows mods to reference other mods. The references will probably be "VendorName/ModName/ItemName", where "VendorName" is the name of the mod's developer, "ModName" is the name of the mod itself, and "ItemName" is an item within the mod, such as a mesh file or a spacecraft.[/p][p]The reference for the vanilla content will probably be "SolarLander/BuiltIn". And I will include an unpackaged "SolarLander/Base" mod as an example of how to implement a mod. It'll be functionally identical to "SolarLander/BuiltIn", but lacking Steam achievements, statistics, and leaderboards. Note that mods dependent on the game's base content should reference "SolarLander/BuiltIn" rather than "SolarLander/Base". Since "SolarLander/Base" is an example mod made to be played-around with by the player, referencing it rather than "SolarLander/BuiltIn" (which is readonly) may result in unintended or undefined behavior.[/p][h2]Using Mods In-Game[/h2][p]The way mods are presented in-game will probably vary quite a bit depending on the mod's content. But there will also be a "Mods" screen that displays general information about a mod as well as a list of content, categorized by content type.[/p][p]If the mod contains game modes, then those game modes will be displayed in "Single Player -> Custom" or "Multiplayer" depending on how the game mode is presented by the mod. Game modes will be able to allow, forbid, or require specific mods or components of mods. The flight computer is getting its own console window, which will allow you to run programs not included in the base game. And there will be some way for game modes to allow you to select which spacecraft to fly among a few other things. I also intend for there to be the option to dynamically add spacecraft in-game. But I haven't figured out any of the details yet.[/p]

[p]One of the goals I've always had for the Modding Update was for players to be able to load a controller profile without affecting their other settings. And I'm finally working on making that goal a reality. Before the Physics Update, you had to assign axis controls in a dialog box that popped-up before the game started. This was before I discovered a way to do this from scripts. For the Physics Update, I decided to just get rid of the dialog box and find some way to integrate axis assignments into the in-game settings screen. Originally, I was going to continue using Unity's legacy Input Manager for this. But I didn't like the way I would have to implement that with the legacy Input Manager. So I went with the new Input System instead. Later, I decided I wanted to implement a control profile system, like what rFactor 1 has. But I also decided not to try implementing it in the Physics Update, since that would take a lot of time to get working, and the game would probably not be in a state where I could patch bugs in the meantime.[/p][p][/p][p]Now that I'm focusing almost exclusively on the Modding Update (as far as Solar Lander development goes), I can implement most of my goals without destroying the updateability of the Physics Update. Plus, I kind of need the Physics Update to work because I'm using that as a reference for the Modding Update, to make sure I don't accidentally miss any features or gameplay mechanics. Also, the move to developing the Modding Update is the first time I've made an update its own project, separate from the project files of the current game version. I probably could have done this in a better way, but it is what it is. And the fact that I did this from the beginning is the whole reason I am able to continue making updates for v0.2.x while also working on v0.3.x.[/p][p][/p][p]Now I almost did something that would have caused a massive delay: I almost replaced the control system I had (which works perfectly) with a new one that would have made the control profile system similar to Zeepkist. Fortunately, I realized that I would not be able to quickly replace the system I had with a new system and scrapped the idea completely. Nonetheless, the attempt to implement this profile system did result in a delay by a few days.[/p][p][/p][p]So here's how the system is going to work: If there is no Settings.ini inside "Users//AppData/LocalLow/TChapman500/Solar Lander", then the game will load all of the settings from the legacy PlayerPrefs settings, saving axis and button assignments in "Profiles/PlayerPrefs.ini". If it finds a Settings.ini file from the Physics Update, it'll load from that instead and save the axis and button assignments to "Profiles/Legacy Settings.ini" instead. And when you click "Reset Defaults" in the lower-left corner of the screen, it'll create a practically empty "Profiles/Default.ini" file (overriding it if it already exists). If you modify the controls, but do not explicitly save the profile settings, then it'll create a "Profiles/Untitled.ini" file, which essentially behaves the same as the current system.[/p][p][/p][p]When you want to load a profile, this dialog box will pop-up with a list of profiles that are in your local Profiles folder. All you need to do is click on the profile you want to load, then click "Load".[/p][p]If you click "Save Profile", then no dialog box will appear unless the current profile name is "Default" or "Untitled". If you click "Save Profile As..." or the current profile name is "Default" or "Untitled", you'll get this dialog box. Entire the profile name (without an extension) and then click "Save". If you click on an existing profile, then the profile name field will be auto-filled with the name of the existing profile that you clicked. You will get a confirmation prompt if you try to override an existing profile.[/p][p]Now there is one thing you must keep in mind if you decide to create a bunch of profiles. You must have only the devices you intend to use for the profile plugged in before you start the game. Extra joysticks plugged in will be recorded in the profile's ini file even if they are not used by any controls.[/p][p][/p][p]There are two more things to note before I end this post:[/p]

1. [p]I intend to provide some default profiles for various types of controllers, but only for controllers that I have access to. These profiles will be included in the game's installation files (Probably in "/Profiles"). The game will copy these profiles into your local Profiles folder if they aren't already there. And if you're not happy with the defaults provided, you can modify them without fear of them being overridden.[/p]
2. [p]I plan to make control profiles sharable through the Workshop. I haven't worked-out the details for that yet. It is likely that this specific feature won't be available when the Modding Update hits the beta branch. But it is one of the goals for the Modding Update.[/p]

I wasn't able to get a devlog out for May, but at least the gap between the previous devlog (#003) and this one is smaller than the gap between Devlog #002 and Devlog #003. And we got another unexpected patch to the Physics Update. Plus, a little something extra which I'll save for last. Let's quickly address the most recent patch first.

What happened is while I was using the Physics Update as a reference for the Modding Update, I happened to trigger a null reference exception while testing something out. Judging by the log, it looks like it didn't affect anything. And I only caught it because the test was done in the editor, which I have set to stop execution upon encountering an error. When checking how it affects the game, I noticed that (a) the error only happens once instead of say, every frame, and (b) nothing happens within the game that would give any indication that there even was a bug in the first place.

Now that we've got that out of the way, let's address what's going on for the Modding Update.

[h2]The Systems Overhaul[/h2]
For starters, part of the Modding Update involves overhauling most (if not all) of the game's systems, which is quite the chore. The good news is that a lot of code is simply a matter of copy-pasting into different locations in an effort to make the code easier to maintain. The bad news is that moving so much code around breaks a lot of stuff.

I also have more bad news: My game engine is taking way too long to develop for it to make it viable to port Solar Lander to it. Not only have I discovered several major problems with the current implementation of the engine's systems, but having to create nearly every system from scratch or nearly from scratch is quite time-consuming. This is especially true when I'm stuck for extended periods of time trying to figure out how I'm going to resolve the various issues that I've come across. This is time I believe is better spent developing the Modding Update. So that's exactly what I've been doing.

[h2]What Is Finished[/h2]
One of the goals for the Modding Update is to have a nice way to package mods for distribution, whether it be through the Steam Workshop or other means. It would also be nice if the game could use these mods without having to unpack them. So let me introduce you to the ".mod" extension. It's a simple archive format that the game will be able to read that'll contain all of the files that will make the mod usable in-game.

Of course, it wouldn't be any fun if you had to repackage a mod that you were developing every time you made a change somewhere. So the game will also be able to use mods which are not packaged into a .mod file. The code for reading and writing a .mod file already exists. The details of how a mod should be made however, do not. Not yet, anyways. But I have decided that mods will not have any sub-folders.

I have however, decided that every mod will contain a mod_info.ini file, which will contain some basic information about the mod, like who the author of the mod is, what the mod contains (eg: space craft, game modes, flight computer programs, etc.), the display name for the mod, and any dependencies on other mods. The exact specifications of this file are not yet finished, but at least now you have some ideas of what to expect.

Solar Lander mods can optionally have a credits.txt and readme.txt which will be readable in-game. As for playable content, there will be a number of files including Lua scripts (eg: for flight computer programs and custom game modes), custom spacecraft and other objects, custom planets, and possibly a few other things that I haven't decided on yet.

Some of the other things that I've completed in terms of porting over from the Physics Update are the Main Menu, Single Player Menu, High Scores Screen, and Credits Screen.

[h2]What Needs Work[/h2]
Currently, the Modding Update is not in a state where it is playable. The whole program is just the game's menu. And even the settings screen isn't fully functional. Right now, I'm focusing on the settings screen. By the way, here's what that currently looks like:

The Help screen is probably going to be saved for last, as I want to make sure that everything else is finished first. It'll give a basic overview of all of the systems in the game, but I'm wanting to implement other features to give more in-depth help. For example, I'm also hoping to implement tooltips to various items along with a Tutorial game mode, which probably won't be out until just before the Modding Update is officially published.

Also, I'm going to be shifting the game's graphics from a mixture of sprite and vector graphics to be purely vector graphics (with the exception of the UI and background image), including some sort of animation system. Another goal is to make it so that objects can break-up upon crashing, creating debris that you have to watch out for.

Also, the API hasn't even been started, though I do have Lua 5.4 working. I am considering dropping down to Lua 5.2 so that I can integrate LuaJIT into the project, which will speed-up script execution by about 5-7 times what we would get without using LuaJIT, which would be just slightly shy of native performance.

Speaking of which, I'm going to make a game mode as a mod published on the Workshop, as well as implement an unpacked "Vanilla" mod distributed with the game that you can play around with.

Much of what I plan to add to the game will come after I put the Modding Update on the beta branch, but will be available by the time it goes onto the main branch. I will post an announcement when I put the Modding Update on the beta branch. And I also have not forgotten about the goal for implementing multiplayer.

[h2]Historic Branches[/h2]
I just added 2 new branches to the game which can be accessed through the beta participation: "pre-physics-update" and "physics-update".

The "pre-physics-update" branch contains the last build before the game got its first version number. I did discover that, at least for Windows, this build crashes due to steam_api64.dll being in the wrong folder. Though I don't recall it ever crashing before the Physics Update. Just go to where the game is installed and navigate to "SolarLander_Data/Plugins" and move "steam_api64.dll" into the "x86_64" folder and it'll be fine.

The "physics-update" branch contains the latest build of the Physics Update. And once the Modding Update officially hits the "beta-builds" branch, the "physics-update" branch will contain the final Physics Update build. And once I have verified that all systems are working properly for the Modding Update, I'm going to simply delete the Physics Update's project files.