Introduction

In 'Generating Star Systems & Documenting Celestial Phenomena' I stated that, for the next devlog, I was planning on finishing two main features:

1. The audio visualiser module.
2. An events / dialogue system.

I did manage to finish these two features, and they will be covered extensively here (I am incredibly proud of myself for managing the schedule). However, I also added some additional features of note:

1. General QOL changes.
2. Changes in how orbiting and 'following' bodies work. E.g, the game can now reliably detect when you begin orbiting a body. This was required for the dialogue system.
3. Standardisation of how the game is paused.
4. A few bug-fixes.
5. Core game design changes.

Core Game Design Changes

I cannot think of a way to draw this out, so heres the summary: it's a roguelike now.

This change was prompted by a few factors:

1. I believe that the game being a roguelike will bolster its playtime.
2. I saw that a cast of named characters in games which you can interact with have near universal appeal, and see a roguelike as a way to add such characters to offset the games very niche genre. (more about characters later in this post)
3. I believe that a roguelike structure will allow me to create a more interesting adventure for the player. You start in the midst of human civilisation, adventure to a dangerous frontier, and then to an abyss where you make increasingly bizarre discoveries - how far can you go? I believe it will be more forgiving and intriguing to the player, in comparison to the completely random discoveries that I planned beforehand. 

The core gameplay loop has stayed the same. Essentially, survey a number of systems > enter a civilised system with a space station > buy upgrades > repeat.

Of course, such a massive change in direction will require some work. Primarily, I will need to carefully balance the average game length down to about 2-3 hours (the average game length being infinite currently may complicate this). 

Audio Visualizer

Implementation went smoothly, and is essentially the same as the description in 'Generating Star Systems & Documenting Celestial Phenomena'. Importantly, I added the ability to save the audio profiles of planets you have discovered while selling exploration data at a space station - this allows you to make more accurate predictions on what a planets variation could be.

I recorded four distinct types of sound for planets - each variation of each planet type has different combinations of these four sounds at distinct volumes. Variations of the same planet type follow a logical progression, with a low variation being quiet and a high variation being loud (or inverse):

1. Chimes - a steelpan-esc instrument. Will have to change it eventually, as it sounds out of place.
2. Pops - bubble wrap.
3. Pulses - silica gel packets.
4. Storm - cloth over microphone.

Events & Dialogue

When considering how to add dialogue to Stellar Cartographer, I took ""inspiration"" from Starsector, one of my favourite games.  My dialogue induced madness began with this blog post: https://fractalsoftworks.com/2023/11/13/you-merely-adopted-rules-csv-i-was-born-.... Which cited this YouTube video, a GDC talk from a Valve developer, as the basis of their dialogue system: https://www.youtube.com/watch?v=tAbBID3N64A. The software engineer jargon took me far too long to understand, but I reckon I have a decent knowledge of the topic now, so heres a summary:

1. Have a number of rules, which require a number of criteria - e.g, 'this equals true', 'that equals that', to be called. 
2. When a rule is called, it can do many different 'things'.
3. Have queries, which contain information (facts) about everything in the game world. When sent, a query is compared against all of the rules, and the rule whose criteria has the most matches to the queries information is called.
4. Query the game world at certain times, like when the player is hit, with all the relevant information.

For example (in Left4Dead relevant terms, as that is where this system was primarily used by Valve)  - when the player is hit, create a query and add the amount of hit points lost to it, then add more general information like the map, the time of day, the health of the players teammates, whether the player has completed specific objectives, etc. Some rules that could be matched might be generic voice-lines for different amounts of damage, or more specific voice-lines which would only match when near a specific area, boss enemy, etc. 

This system is made for voice-lines - being used in the Left4Dead franchise - so its somewhat different for dialogue. Starsector has additional 'things' that the rule can do when being called, like opening the dialogue screen, adding dialogue options and adding dialogue text. Additionally, when options on the dialogue screen are pressed, a new query is created, adding whatever information the option specifies.

Starsector uses a .csv file for rules, which can be exported from spreadsheet applications like Google Sheets and Excel - originally, I tried to use Godot resources with export annotations to construct rules - but this had a number of drawbacks. Specifically, manually specifying the type of every dictionary key/value that I added to a rule wasn't particularly efficient. Realising that things are usually done a certain way for a reason, I wrote a parser to convert .csv to my custom Godot resource. 

Key:

I also added 'return states', as depicted below. Can be added as a parameter for the closeDialog function.

Events & Dialogue - Usage

I plan to use this dialogue system for three main things:

1. General entity interactions - like the wormhole example above.
2. Anomalies - dialogue sequences which can yield salvage, data and other rewards, or disaster and death.
   1. Surface anomalies. Marked by a question mark next to an entry in the system list - when the entry is interacted with, a relevant random dialogue sequence begins.  
   2. Space anomalies. Currently unsure if these will be physical locations in the game world, or if they will occur completely randomly.

Events & Dialogue - Characters

When starting the game, your ship will be populated with a cast of distinct, preset characters which you can interact with via dialogue. Some characters will be randomly discoverable. These characters will present special dialogue options which will usually be better than the default options (e.g, having your chief engineer oversee salvage operations rather than yourself - think of the blue dialogue options in FTL: Faster Than Light). However, these options may have a chance to kill the character. When a character dies, they are lost permanently until the next game you play. I believe having preset characters will make the game more engaging (if I succeed in making them sufficiently interesting), and will allow more variety in gameplay, as it is unlikely that the same characters will be alive at the same point in time between runs. I currently have plans for five characters: the players First Officer, Chief Engineer, Security Officer, Medical Officer, Linguist and Historian - however I am still working on their exact personalities and traits. 

Events & Dialogue - Conclusion

I believe that a rule-based dialogue system will make adding new content far easier, however there are several bugs, issues and flaws that I will have to fix in the future:

1. Removed functionality for greater-than and less-than signs in the parser. Will have to re-add eventually.
2. The ‘apply facts’ column is untested.
3. Limited type support in the parser - only strings are supported.

What Next

With the rule-based dialogue system, the game now has the capacity for interesting discoveries - a key goal which I outlined in the first devlog. My next goals are to utilise and improve the system, to add progression which is congruent with the roguelike genre, and to improve gameplay.

1. Game progression and average game length shortening to 2 hours (timing, difficulty scaling graphs, etc).
2. New modules and upgrades. Mainly, I want to add a long range camera upgrade, which will allow you to observe and photograph specific space anomalies in a Pokemon SNAP esc mini-game.
3. Support for space anomalies.
4. Rules for a tonne of planetary and space anomalies. 
5. General polish.

Thank you for taking the time to read this devlog.