Introduction

In 'Achievements, Better Generation & More Dialogue' I described six tasks (in essence) that I planned to complete by the next devlog, being:

1. mutiny mechanics changes;
2. more content;
3. gas layer surveying module;
4. special module limit;
5. manual scope targeting changes; and
6. system hazards. 

This devlog will cover the more interesting tasks that I worked on, including some smaller tasks that were absent from the conclusion of the last devlog. I completed all of the tasks except 'mutiny mechanics changes' and 'more content' - my repeated failure to complete these will be discussed in the conclusion. The topics covered in this devlog are:

1. dynamic star systems;
2. gas layer surveyor module;
3. objectives; and
4. miscellaneous.

Dynamic Star Systems

The purpose of the following additions is to vary player movement. The player would only move to interact and to extend the range of their scopes, and I believed that this was a missed opportunity for more engaging gameplay. The hope is that by forcing the player's hand with CMEs, potentially with asteroid belts slowing their escape, the player will have to move more frequently and will consider distance and speed more readily than before. 

Coronal Mass Ejections (CMEs)

When the player first enters a star system, there is a 25% chance that a CME is imminent. This is displayed via a countdown at the top middle of the screen. When the countdown reaches zero, the CME occurs, and the countdown restarts. Subsequently, the CME expands outwards from the star as a ring, and damages the player if they are unlucky enough to be caught within it. The initial time until the CME is randomised, with the lowest possible value being 30~ seconds - I deemed this to be enough time for the player to find a wormhole and leave the system before taking damage.

I believe CMEs accomplish two things. Firstly, they increase variety in movement as per the overall goal for this topic. Secondly, they offer another way to gain hull stress, which I believe makes the game less predictable and thus more engaging. Hull stress from wormhole traversal is too predictable, and events which increase hull stress are often too rare to make a difference, allowing CMEs to fill the gap. I plan to add more system hazards to accomplish similar effects in the future.

Asteroid Belt Slowdown

When the player is travelling over an asteroid belt, their movement speed is halved. This is to mess with the players perception of speed and distance, as described at the start of this topic. It is meant to force players to ask themselves certain questions, e.g. "Will there be time to discover these bodies AND make it back to the wormhole before the CME occurs?"

Initially, I was worried about the technical difficulty of detecting whether the player was within an asteroid belt, as it appeared to require some kind of collision detection for a ring shape, which did not sound easy. Eventually, I had an epiphany - asteroid belt radius was uniform. The solution was to simply check whether the players distance from the host was above the belts minimum radius and below its maximum radius.

Standardised Interactions

Every body on the system list now has a dialogue interaction, unlike previous versions where only stations, rendezvous points, space anomalies and planets with active planetary anomalies had interactions. This is to eliminate any uncertainty regarding what bodies have an interaction and to incentivise travel to a greater assortment of bodies. Doing this required a complete overhaul of the dialogue system, but will allow me to get a lot more creative while making events.

Gas Layer Surveyor Module

'Achievements, Better Generation & More Dialogue' announces that: "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 [the] gravitational pull. In essence, a complex memory exercise." This idea was expanded on in my initial planning:

The process of development soon began - the first step was to create the graphics. I decided to use volumetric fog combined with a basic noise texture shifting upwards to create the 'clouds' for each layer. While rudimentary, I believe this approach was flexible enough for the task of making varied noise layers. The other component of the scene became the 'probe' - an old spaceship model, created by me, that was repurposed with the help of a friend who graciously fixed its topology in Blender. The first two gas layers I created with this system were the following:

Next, I set up the core logic for the module.

Finally, following many improvements and 19 unique gas layer designs, I ended up with the final result. 

The Gas Layer Surveyor module was borne from a desire to pad out gameplay. As stated in 'Achievements, Better Generation & More Dialogue', it "[joins] the likes of Audio Visualizer and Long Range Scopes as a '[special]' module". A cap of two special modules forces the player to make a decision about which two to take, and which one to leave, hopefully increasing replayability. 

There was also a psychological factor in its creation, due to my own studies. The descent time is 30 seconds, corresponding to short term memory (STM) having a duration of 20-30 seconds. The maximum amount of gas layers per planet is nine, which is also the maximum capacity of STM. Of course, this gives players exactly zero seconds to contemplate before making a decision - so rehearsal is a must - but hey, at least it was something I considered while developing it!

I am quite happy with the final result. From what I've seen from playtesters, it makes you think - which was exactly what I was going for. Personally, I think it's engaging. In the future, I may improve the transition between gas layers, add sound effects, or even implement multiple camera angles; in the meantime, it suffices.

Objectives

Previously, the tutorial was dialogue based - this was not a good system. You would get a long list of instructions, press 'Exit' and perform them - the issue being that players forgot the instructions, or didn't read the instructions, or didn't understand the instructions. Objectives were created in an attempt to fix this issue by being responsive and accessible at any time.

In order to create a system to manage objectives, I first had to theorise how they would work. What I ended up with was a system of categories and objectives, where categories are groups of objectives whose states can be updated simultaneously, and objectives are an identifier, title, description and state, e.g. none, success, failure. Both classes can be manipulated with dialogue and code. Setting the state of an objective to success or failure requires it to already be in memory.

Additionally, I added another system which works closely with 'objectivesManager' called 'eventsHandler'. This system takes information from across Stellar Cartographer and marks objectives via code based on the information it receives. This was necessary as some events like moving the camera, which could hypothetically trigger every frame, would not be suitable to be passed through the long and complex 'dialogueManager' system from a performance standpoint. 

Combining these systems, I overhauled the tutorial to only use objectives, overhauled the module tutorials likewise, and added a base objective for the campaign. 

While I am happy with the final product, the process of making the objective management system was not enjoyable. Specifically, saving and loading the data was riddled with issues - objectives wouldn't save, objectives would load in a state different to the state they were saved in, objectives would not be arranged correctly within 'objectivesPanel', etc. I had to scale back drastically from a system with support for hierarchical objectives - where an objectives behaviour would be dependent on its parent - to the simple list that is seen here.

There are some issues and possible improvements that I see for this system. Mainly, I don't like how objective management is fragmented between 'dialogueManager' and 'eventsHandler' - I don't see a way to alleviate this, but it would be nice for it to be a bit more centralised. In the future, I would like to add a sound queue for when objectives enter memory, as it appears that playtesters sometimes don't notice when objectives are updated. Overall, it will suffice.

Miscellaneous 

The following additions focus on quality of life and do not fit into any particular topic.

System List Visual Overhaul

As I gain more experience in game development, I notice to an ever greater extent the importance of keeping the amount of information on screen at all times to a minimum. Before this, the system list had very little graphic representation and was cluttered with information; planet and star names were always suffixed with their type, and text would often overflow because of the increased length. Ironically, the player did not actually need to know the type of each body at a glance, making the entire setup redundant.

This overhaul focuses on two things: having an icon for every type of body on the list, and removing the redundant information thereof. Both of these things were achieved and I moved the planet and star type suffixes to tooltips just in case. I think the new system is much more clear and approachable. The only limitation of note is that the icons for Neptunian and Jovian planets may be too similar - I may have to re-texture them at some point.

Dialogue Visual Overhaul

Alike the system list overhaul, the dialogue overhaul relates to the importance of keeping the screen clear. In a growing trend, I took inspiration from the videogame Starsector for the new design, which hides the rest of the UI so the entire screen can be used for dialogue. Funnily enough, this concept shocked me - I had never thought of such a simple solution, and instead insisted on placing a solid colour backdrop for dialogue while keeping it smaller than the screen itself. I believe this emphasises the significance of viewing something from multiple angles before making a decision - sometimes, the solution is right in front of you. 

I am content with the new design and bizarrely do not foresee any improvements to it.

Current Action Panel

I found that playtesters were often not sure about what action they were in the process of performing; this prompted the development of the 'current action panel'. It displays the action and distance to the action body, providing some closure. Additionally, it displays travel modifiers (what is impacting the players speed towards completing an action) in an attempt to leave no uncertainty around movement. Time will tell whether it is reliable in reducing such uncertainty. 

What Next

My consistent inability to implement changes to mutiny mechanics and to add new content is a problem. It's easy to see why I fail to add these features - they are dialogue heavy, and writing is extraordinarily time consuming. The few storylines that I have added to the game so far have taken a lot of time to plan, a lot of time to format, and an even greater amount of time to write. It doesn't help that new content usually warps established systems, often leading to more overhauls to compensate. I love writing, but I was thoroughly unprepared for the task of balancing my work towards gameplay and towards content for this project.

This shying away from the most important aspects of the game is under additional scrutiny due to the time restraints that I have placed upon myself. If I want to release v1.0.0.0 by the end of 2025, I have to focus on content immediately. The past few months have been some of the busiest of my life, and it has become apparent that there is very little actual time for me to work on this project. Five months remain, and I have to make them count.

I now find myself in a unique position - all of the 'padding' for the game is done. I have no plans for any additional special modules or huge new features. I am in the best possible position to focus primarily on adding new content. The process that I plan to use to do so efficiently is the following:

• Focus exclusively on events for the 'CORE' region.
• All simple anomalies should follow the existing two-step exposition-result formula.
• Anomalies should only be available if all relevant characters and upgrades are alive/unlocked - there cannot be branching paths depending on what is available throughout the anomaly itself.
• Dialogue should conform to writing conventions for short stories, descriptions, etc.
• Dialogue should use the key phrases and frameworks that I have created in the past.

My goals for the next devlog involve bug fixes, improvements and - of course - new content:

• Modifying the system list so it is always in distance order.
  
• Fixing performance issues. The system list and barycenter visualizer are updated every frame, even if nothing changes. 
• Overhauling the tutorial. The new tutorial will be a prelude to the campaign, explaining your purpose more thoroughly and teaching you more advanced keybinds and interactions.
• All of the planned changes discussed in the Mutiny Mechanics section of 'Achievements, Better Generation & More Dialogue'.
• Several new repeatable anomalies which influence character standing.
• Several new simple anomalies which have significant random impacts on gameplay, rather then merely modifying nanites and hull stress.
• Three new 'CORE' region complex anomalies. 
• The first Rendezvous Point character event for Security Officer Walker.

Thank you for taking the time to read this devlog.

End Notes

This devlog is the culmination of two updates: v0.4.0.0 and v0.4.1.0. For future reference, their change-logs are below:

Change-log (0.4.0.0):

• Survival indicators now have red text when critical.
• Added an achievement for travelling to an O class star system during a run.
• Fixed resetting of locked body on wormhole traversal. 
• Overhauled dialogue UI.
• The first star system of the campaign now has a fake disabled wormhole.
• Added Coronal Mass Ejection (CME) system hazard.
• Added an event for travelling to a star system with an active CME for the first time in a run.
• Overhauled the audio system to allow for music to be queued and for music to be muted when certain criteria are met. 
• Added intro music.
• Added two leitmotifs which play at random when the player enters a civilised star system.
• System list visual overhaul with reduced text and new icons.
• System list tooltips now include supplementary information.
• System list anomaly frames are now coloured green and oscillate.
• System list missing audio data and gas layer frames are now coloured dark green.
• Modified draw order for system list frames.
• System list 'INFO' tab is now unlocked by default.
• Improved scopes glint sprite. 
• Standardised interactions - all bodies now have an interaction. 
• Added support for planet and star dialogue descriptions.
• Added Terran class planet descriptions.
• Added an interaction for space entities when Long Range Scopes is not unlocked.
• Added situational flairs for planets when Gas Layer Surveyor or Audio Visualizer are not unlocked.
• Implemented a fix for manual scope targeting visuals on system map.
• Asteroid belts now slow the player down.
• Added current action panel, including travel modifiers.
• Added objectives.
• Removed various console print entries to make debugging easier.
• Migration to Godot's Forward+ renderer.
• Added Gas Layer Surveyor (GLS) module.
• GLS and Long Range Scopes now automatically open on interaction with a valid body.
• Advanced Scanning upgrade now boosts the chance for planetary and space anomalies to spawn by 10%.
• Fixed a bug where stars on the system list have the same tint when locked and also when only viewing. 
• Added a special upgrades system, with the maximum amount of special upgrades locked at two.
• Designated GLS, Long Range Scopes and Audio Visualizer as special upgrades.
• Overhauled the tutorial to include a variety of objectives.
• Added a toggle-able overlay to the system map which shows the names of various UI components.
• Added a new planetary anomaly.
• Added a new space anomaly.

Change-log (v0.4.1.0):

• Added a doppler tracked flyby sound for bodies.
• Removed the Gas Layer Surveyor (GLS) glitch shader that occurred when nearing the end of a dive, as it behaved strangely on different monitors.
• Buffed GLS rewards.
• Module tutorials are now expressed with objectives rather than with dialogue.
• Added module tutorial objectives for GLS, Long Range Scopes, Audio Visualizer and Nanite Controller.