Introduction

In ‘Miscellaneous & Bugfixes’ I outlined some topics, and the goals associated, that I would independently develop before the next devlog. These topics were: ‘Improved star systems’, ‘Replayability’, ‘More content’ and ‘Miscellaneous improvements’. 

I added most goals within all topics. I added all goals within ‘Improved star systems’, besides system hazards/modifiers, which I created the base architecture for but didn’t quite get around to implementing. I added an achievements system and a better game scoring system, constituting half of the goals within ‘Replayability’. I made huge (and hopefully final!) changes to the dialogue system, and added some content, working towards the aim of the ‘More content’ topic. I believe the ‘Miscellaneous improvements’ topic was a success, as I made a few enhancements in that regard.

This devlog will cover the more technical and/or interesting subjects that I worked on, including some subjects that weren’t quite present in any of last devlogs topics, being:

1. Changes to Survival.
2. Mutiny Mechanics.
   
3. Rendezvous Points.

Achievements

I decided to add achievements due to their potential to increase replayability. Implementation consists of a banner popup in-game, and an achievements list in the main menu (both shown below). The achievement calculation is performed every time a dialogue query is spoken. It compares each achievements criteria to the query data using existing dialogue methods, and unlocks any achievements whose entire criteria is met. This makes the syntax quite simple:

The only downside to this approach is that gaining an achievement will be delayed until, of course, a dialogue query is spoken. In the above example, the player could have fifty percent hull deterioration or more, but would only gain the achievement when interacting with a wormhole, station, anomaly, etc. 

I am very happy with the achievement system, and I don't foresee it requiring future improvements. Right now, the achievement list is barren, but new achievements will be added to recognise rare events and challenges in the future.

Better Generation

New Planet Types

What always infuriated me about the generation in Stellar Cartographer was the prevalence of Terrestrial and Silicate planets. They were 'basic' (weren't temperature specific) and were therefore appended to every planet type choosing operation. Worse, they were heavily weighted. Entire star systems were filled with them.

I decided to remove these two planet types, and replace them with four new ones: Iron, Nickel, Sulfur and Coreless. They function nearly exactly the same, however are weighted slightly less overall. Their names are derived from their supposed core type, as there is a surprising lack of naming convention for barren rocky worlds. With these new types, I can no longer notice any repetition.

While researching planet types, I wrote down some descriptions which I plan to eventually add to the system list 'INFO' tab. Below are the descriptions for Sulfur and Ice worlds, respectively.

A solid planet composed of silicate, water, carbon and trace rare elements accompanied by a sulfur or iron-sulfur core.

A solid planet composed of silicate, water and carbon, with huge reservoirs of water, methane, ammonia and nitrogen at it's surface. Metallic core.

Naming Schemes

A long-standing suggestion for Stellar Cartographer was to make the naming scheme more 'scientific' - more akin to the seemingly random jumble of characters used to describe phenomena in real astronomy. Having put effort into the existing naming scheme, I decided to simply add two more and have the game randomly select between them:

• STANDARD: Use of handwritten names and flairs.
• TREK: Use of roman numerals. Occasionally falls back to STANDARD names.
• SCIENTIFIC: Use of digits and gibberish identifiers.

Adding these new name schemes was an enjoyable task. Below are some extreme examples of the SCIENTIFIC name scheme.

bodyAPI and starSystemAPI Overhaul

Before this overhaul, any method involved in rendering bodies was filled with the 'or' keyword to differentiate between the 6~ body types, in spite of most bodies being rendered as a coloured sphere, or as small glint texture meant to communicate that the body is too small to be seen. It took a lot of refactoring, but I made every body inherit from one of two new classes: circularBodyAPI or glintBodyAPI, which are displayed relevantly. This will make working with the renderer a lot easier in the future.

Below is the before and after of this change. 

This overhaul also included:

• customBodyAPIs. Save rendering information locally, have customisable dialogue IDs, and track whether they have been interacted with. Used for special anomalies.
• bodyAPI methods for executing code locally when created and for every frame.
• Simplification of starSystemAPI 'addBody' calls.
• Support for starSystemAPI generation injection. Used for special star systems.
• Special star systems and anomalies.

The aim is to use special star systems and special anomalies to make more interesting discoveries for the player in the future. 

Dialogue

Dialogue updates stole a majority of development time. Below are three features which can be held partially accountable for this, but aren't important enough to cover in detail. 

1. Tree deferring. At one point I ran into an issue where different dialogue trees would override each other. I spent a lot of time attempting to find a way to defer dialogue trees until the current tree was concluded, before realising that the best solution was simply to not have dialogue trees start while dialogue was already open. I reverted all of my progress on the feature as it was unnecessary.
2. Implementation of dynamic morale increase cost for Rendezvous Points (see Rendezvous Points section). This task was lengthy as it required the ability for facts to be referenced in multiple components of the dialogue system. In order to increase the reliability of reference substitution, I learned and implemented RegEx pattern matching, which took a lot of tinkering.
3. BBCode support for dialogue options. 

The primary update to the dialogue system regards the algorithm for rule picking. Previously, the 'BEST' query type compared rule criteria against query facts, and picked rules who had the highest number of matched criteria compared to all other rules. I had long suspected that instead of picking the rule with the most criteria matched, it would be more effective to pick the rule with the most criteria matched, from a list of rules of whom have ALL of their criteria matched. How this improves the 'effectiveness' of dialogue is displayed below.

Using the 'BEST' query type, there cannot simply be two rules for whether the 'wormholeAVFlair' is called, e.g:

This is because one of the criteria keys other than the concept will most likely always be true. For example, if the player unlocks the Audio Visualizer module, the rule picked will always be 'wormholeTryAVFlairPass', even if the players star system isn't civilised, and the player does not have any pending audio profiles. By only allowing rules to be picked if ALL of their criteria is matched, this problem would disappear. Additionally, the large tally of rules in the above image required to check each criteria key individually to work around this issue, would thankfully no longer be necessary.

The new query type required to bring this idea to reality was to be called 'JUST_BEST'. Despite all of the logic and planning needed for the feat, the 'JUST_BEST' query type differs from the 'BEST' query type by merely two lines of code. After discovering that it performed perfectly, the 'BEST' query type became 'JUST_BEST', and the old 'BEST' query type became 'OLD_BEST'. Below is the condensed version of the above image, using the 'JUST_BEST' query type. 

This relatively minor change has greatly improved rule writing efficiency, and the refactoring required was far from the devastation that I feared. With greater rule writing efficiency, I should be able to create new content faster in the future.

Changes to Survival

After much deliberation, I decided to completely change the survival mechanics in Stellar Cartographer. Below are the primary changes, followed by an explanation.

1. Using the LIDAR no longer incurs any hull stress.
2. Wormhole traversal now incurs a much greater quantity of hull stress (+25% on success, +50% on failure).
3. Some common random events now repair hull stress.
4. Rendezvous Points provide options to increase chances of survival.

Previously, hull stress was incurred on LIDAR ping, where the amount of hull stress incurred depended on the size of the LIDAR scan arc.  This was not popular with playtesters, as it required you to practically shoot yourself in the foot in order to cover larger areas. The result was that playtesters would not use larger scan arcs, instead relying on smaller arcs which made exploration infinitely more difficult.

The solution therefore was to remove LIDAR ping hull stress altogether. In order to keep the game challenging, I massively increased wormhole traversal hull stress. With five traversals between ports, the player would gain 125% hull stress, or 100% hull stress and 25% hull deterioration, each leap. This prompted the addition of random events and Rendezvous Point interactions to repair this hull stress, leading to the players survival being dictated by their luck in event outcomes and discovery value, but also their skill in spending nanites effectively.

Mutiny Mechanics

Ever since I added morale as a survival indicator, I had planned around the assumption that a mutiny should start at 0% morale. Despite this, I had never decided what a mutiny would actually involve. My latest mutiny implementation guarantees the players death, along with a vague message, when 0% morale is reached. In the future, I would instead like to have: 

• The players chance to survive a mutiny be roughly tied to the players standing with their Security Officer (formerly tied to mutiny backing - see Rendezvous Points section). 
• Different types of mutinies that would allow the player to perform different actions to try and survive. Some types would be specific to regions of Security Officer standing.
• The player to loose all of their senior staff as a result of surviving a mutiny, with morale locked at 0% and no further action for the rest of the run.

I plan to make these changes by the next devlog. In fact, the dialogue already suggests that the players chance to survive a mutiny is dictated by Security Officer standing, so it shouldn't take too long.

Rendezvous Points

The addition of Rendezvous Points originated from me wanting the player to have more dynamic interaction with their senior staff, and more ways to riskily save themselves in a crisis. I had the idea when a friend was showing me the ‘ask for help’ mechanic in the game Highfleet, which allows the player to ask contacts for essential resources, often at long term detriment; I quickly planned my own version of this concept on a digital whiteboard:

This concept was to be represented as a physical location within star systems which the player would discover and interact with (eventually becoming Rendezvous Points). Options to decrease and increase survival indicators, at a cost, would be available - First Officer to increase morale, Chief Engineer to decrease hull stress, Medical Officer to increase data value, Security Officer to increase mutiny backing. My first implementation followed this plan precisely, which exposed a few drawbacks:

1. Although it technically made sense that hull stress would increase as a result of directing resources towards security, programs to increase morale, etc, the extra cost did not translate well into the game. It felt like an afterthought that wasn’t well thought out.
2. The morale increase cost being uniform (not scaling with the players journey) put absolutely zero economic strain on the player, withdrawing any difficult decisions. Playtesters could easily afford to repair and increase morale after every leap.
3. Mutiny backing did not make any sense. Its cost was higher then the cost of increasing morale, so it was always more attractive to increase morale rather than mutiny backing. It would only work if a mutiny could not be planned for, rather then being tied to 0% morale.

In my second implementation, I fixed these three issues:

1. Rendezvous Point options no longer increase hull stress.
2. The cost of increasing morale fortifies as the players journey progresses, staring at 20k nanites and ending at 55k nanites.
3. Mutiny backing no longer exists. I decided that the players chance to survive a mutiny would be derived from their standing with their security officer, instead of direct mutiny backing purchases.

Overall, I think my second implementation comes closest to providing the player with more senior staff interaction and more methods to save themselves in a crisis. In the future, I’d like to expand upon Rendezvous Points by adding character story events at varying values of standing (think Stardew Valley), the ability to play cards with your senior staff in the mess hall, etc. 

What Next

These updates have made the creation of new content much, much easier. For that reason, my current goals for the project are related to the creation of new content, both in dialogue and in gameplay. The creation of new content is also paramount as I plan to release v1.0.0.0 by the end of 2025, with no guarantee of further updates - it is currently March. Goals below.

1. All of the planned changes discussed in the Mutiny Mechanics section.
2. More content. I plan to finish writing one planetary anomaly and one special anomaly. I also plan to add two new space anomalies, one generic space anomaly, and at least two generic planetary anomalies. No thoughts on character story events at the moment.
3. Gas layer surveying module. Joining the likes of Audio Visualizer and Long Range Scopes as a 'physical' module, the surveying module will follow probes as they delve into the atmosphere of gas giants. The player will have to watch and remember what gas layers the probe passes through, and then select them in the correct order for rewards once the probe is crushed by gravitational pull. In essence, a complex memory exercise. 
4. A maximum of two 'physical' modules secured to the players starship at once, following the addition of the gas layer surveying module.
5. Multiple changes regarding manual scope targeting.
6. System hazards. I aim to primarily add solar mass ejections.
7. Miscellaneous changes. 

Thank you for taking the time to read this devlog.

End Notes

This devlog is the culmination of three updates: v0.2.0.0, v0.2.0.1 and v0.3.0.0. For future reference, their change-logs are below:

Change-log (0.2.0.0):

• Added a 'total score' counter, which is used to rank the players performance at the end of a run.
• Added a system for managing achievements (twelve added in this update).
• Added a system to sequentially show achievements in banner form when unlocked.
• Added a list of locked and unlocked achievements, accessible from the main menu.
• Fixed 'comparison operators' (greater than, less or equal than, etc) in dialogue management.
• Sub-bodies (moons) radius and mass may now only be 0.75x the radius and mass of their host.
• Removed 'Terrestrial' and 'Silicate' planets.
• Added 'Iron', 'Nickel', 'Sulfur' and 'Coreless' planets to replace now defunct 'Terrestrial' and 'Silicate' planets.
• A planets type is now given tree access during planetary anomaly dialogue.
• Added a new dialogue query type: 'FULL_BEST'.
• Rule criteria values which are 'false', and do not have a corresponding key within an incoming query, will now match.
• Added two new star-system naming schemes: 'TREK' (use of roman numerals), and 'SCIENTIFIC' (gibberish inspired by real astronomical naming schemes).
• The player can now use the scroll wheel to zoom in/out on the system map.
• Replaced a long standing placeholder in the station UI.
• Barycenter Visualizer blips are now darker when out of range of the players current LIDAR arc length.
• Visual improvements to the main menu and stats (end of run) menu. 
• Added a dialogue interaction for disabled (red) wormholes. 
• Added custom tooltips for different parts of the UI, as players routinely missed the default tooltips.
• Body names are now no longer passed through the String capitalize method when being shown in-game.
• Added a cool looking 'typing' effect for dialogue text as its being appended.
• Scenes are now loaded in a seperate thread.
• Added a loading screen with a progress bar, visible while scenes are being loaded.

Change-log (0.2.0.1):

• Migration to Godot 4.3 for editor improvements and sweet performance increases. 
• Fixed several graphics related bugs caused by the migration to Godot 4.3.

Change-log (0.3.0.0):

• Removed LIDAR incurred hull stress.
• Modified wormhole minigame hull stress increase.
• Removed 'BEST' dialogue query type, leaving 'FULL_BEST' as the default.
• Added rendezvous points.
• Added two new ambience tracks.
• Overhauled bodyAPIs.
• Added customBodyAPIs.
• Added support for spawning and generating special star systems.
• Added support for spawning special anomalies.
• Added rare 'VOID' special star system.
• Added a rare special anomaly.
• Fixed closest body 'light up' effect incorrectly including hidden bodies in calculation.
• Added wormhole minigame success and failure sound effects.
• Fixed body discovery sounds.
• Hull stress indicator tooltip now displays cost to repair when the Nanite Controller module is unlocked.
• Comments are now fully supported in rules.
• Added a debug keybind to re-import rules at run-time, allowing any changes to be viewed instantaneously. 
• Star type weightings now morph depending on how close the player is to New Eden - harder star types become more common late-game.
• Anomalies which repair the players starship now have a chance to fail to do so.
• Added a basic mutiny event.
• The system map overlay now disappears at a set distance, rather than being derived from the stars radius.
• Added a gunshot sound effect to relevant dialogue events.
• Overhauled character handling.
• Added player personal standing with main characters (senior staff).
• Journey map now displays the station icon at the location of the next civilised star system.
• BBCode support for dialogue options.
• Changed total score requirements for the Drifter, Wayfarer and Cartographer achievements.
• Modified cost to repair at port.
• Larger anomalies can no longer occur multiple times, and are now prioritised over generic anomalies.