Hyperlink Your Heart - godot4

Lovely, Dark and Deep

2025-06-14T18:28:00+02:00

Back in April I took part in Ludum Dare 57, which had the theme “Depths”. As usual I was eager to take Digression for a spin and see how much it had improved since its last outing for Ludum Dare 48, and this time I managed to come up with something that allowed me to do that. Coincidentally, the theme for LD48 was almost the same (“Deeper and Deeper”), and I ended up making a somewhat similar game in some respects!

The Concept

The initial concept was one I’ve had kicking around for a while, of a post-apocalyptic trading game with two phases to the gameplay - one where you travel between outposts by car, possibly having to engage in combat or other encounters, and another at outposts where you have to trade and maintain your car. I think of it as terrestrial Escape Velocity, though the travel would undoubtedly be much simplified for a jam game.

Of course none of the elements of that idea are set in stone. I usually think of it as being set in a desert (the ol’ Mad Max influence I suppose), but in this case I wasn’t sure if deserts have depths? So that was out. I considered setting it in deep space instead (some sort of non-terrestrial Escape Velocity, I suppose? What a notion), but that seemed too close to the game I made for Ludum Dare 48 already. And so it became deep forest, and then the car became a bicycle because that seemed more foresty.

Most of the rest of the originally envisioned gameplay mechanics fell away as I tried to scope it to the 72 hours available. The travelling became just an opportunity for a bit of dialogue, the vehicle maintenance became a simple stat alongside others for the player, and the trading disappeared entirely. In an effort to introduce some gameplay beyond just engaging in dialogue, I added in a hand of randomly drawn cards at each location and a limited number of action points for their use. I think I had in mind the dice rolls in Citizen Sleeper when I came up with this, but I couldn’t really remember how they worked in that game.

Considering it has been several months since the jam I don’t think I could give you a blow by blow even if I wanted to, so I’m just going to talk a bit about what worked and what didn’t.

What Worked

Digression

Digression worked really well for the most part. I think I encountered one bug, but I was able to work around it. I was able to churn out dialogue really quickly for the encounters and travel, and it was relatively easy to implement changes to the game state during dialogue as well (giving items and buffs and the like) - though that aspect of it could have been better, as I discuss below.

Use of Resources

I used Resource types for all the items, buffs, curses, character classes etc. Although they were a bit of a mess and included some stuff that didn’t end up getting used, it really paid off to work with resources right from the beginning. Often in the past I would implement something like the player’s gun, for example, as just a scene or part of a scene, with the intention to rework it later to allow different guns defined by resources. And of course in a jam that never happens as time runs out and I get fatigued - so there ends up being only one gun, one pickup etc.

Probably the most obvious effect this had in this game is the character class selection. It doesn’t add all that much, but I think it is a neat thing to have in a jam game and it gives the impression of depth.

So, big thumbs up to doing things the right way from the beginning.

Audio

I used old reliable LMMS for the music this time around. Last time I tried some new tools and had a really bad time. I’m really proud of what I made for this game, it had the exact spooky, mysterious quality I was going for. I don’t think beepbox would have cut it this time.

The game didn’t call for many sound effects, but the ones that are there, aside from the UI, are foley - always fun to do that and I think they work pretty well.

Art

What can I say, I think I did a good job on the art. That’s always been my strength anyway so big woop.

I am still using Pixelorama and there are still a few things about it that I find grating, but I have gotten used to it enough that it doesn’t get in my way. It was better suited to this game than my last one because most of the art was large background pieces rather than tiles.

Something that’s kinda new is that I did lot of animation using tweens. Little things like the the back and forth motion of the bicycle and how it enters and exits the screen, and the distribution and flipping of the cards, were entirely done with tweens. They took only minutes to implement and I think they look great, and add so much to the aesthetic of the game. I only had to actually animate one thing by hand, the pedalling.

The Humour, apparently

That Sully, what a card.

What Didn’t

Digression

Though it certainly didn’t let me down, I definitely noticed a few pain points in actually using it for a game.

It was originally a main-screen editor, and at some point I decided it should be in the bottom dock - probably because Godot didn’t provide an official way to add a main screen plugin and you had to sort of hack it in. However it requires a lot of space to use properly, and having it in the bottom dock was an impediment to that. I have moved it back to the main screen since the jam.
Having to manually manage the size of dialogue nodes was a hassle. I have since updated them to be resizeable width-wise, but to grow with the text length-wise. Much nicer to use.
Similarly, it was kind of a pain scrolling up and down a node when there was a long section of text. I have since partially implemented a mechanism to allow the dialogue node to be “maximised” when you want to focus on editing, and I will be doing the same for the choice node.
The lack of an open graphs list made it a bit awkward to move back and forth between graphs, as I had to find them in a scene or the filesystem every time. I have since added an open graphs list, as well as an anchors list for navigating around a graph.
The two different signals for dialogue and choice dialogue struck me as a little awkward in retrospect. I will be consolidating them I think.
There are a few problems with the variable management system. One is that they lacked defaults - I have added these since. Another is that the variables didn’t mesh well with the overall game, i.e. game state and dialogue state felt like two separate things that I had to bridge. I’m not sure how I am going to address that yet.

Gameplay

The gameplay was pretty awful. I clearly do not really know how card games work. Limiting the player’s actions to a random selection of cards just resulted in frustration, especially when it was not obvious that some actions required items, and when their use of the cards was also constrained by action points.

The stats generally degraded too slowly as well and there were unclear interdependencies between them - your health doesn’t degrade until you exhaust your food or water stats completely.

The encounters were fun, I thought, but there were too few of them and they were too random - you would see the same ones over and over sometimes. Too many of them had disappointing outcomes, and if you didn’t get the right cards there was nothing to do.

I think the random encounters worked a bit better in Out of Gas for two reasons: most encounters involved combat, so that is just inherently more exciting - and the fact that you were fleeing something, and could be killed, was slightly more compelling than a set of depleting stats.

Overall, the randomness just left the player with little sense of agency. I would have been better off dropping the gameplay altogether and just making it a short visual novel, with agency expressed only through dialogue choices. Though I’m not sure I could write a compelling story for a visual novel in such a short timespan either…

Bugs

I introduced a bug at the last minute that prevented the game from ending when your health or vehicle state reached zero lol, lmao.

Results

Much better than my last two outings, and some good ratings in several categories, but definitely let down overall by the gameplay. I’m a bit disappointed by the mood rating as I felt I nailed that, but it is a very subjective one of course - and it’s still pretty good!

Some notables:

My highest ever rating, and placing, in humour (please clap).
Highest ever audio rating (by a hair), and placing.
First time being in the top 100 in four categories as a solo dev.
First time being in the top 50 in two categories. Third time being in the top 50 in any category.
Second lowest rating in fun - only my Ludum Dare 38 entry, which was only the opening scene of an adventure game and had no gameplay, was lower!

Post-Jam

Nah.

Future Developments

I was inspired to work on some sweeping improvements to Digression and have made a lot of progress, but there is also a lot of stuff broken and partially completed now. I will post about the changes in more depth when they are done.

I also created a set of placeholder graphics to use in future jams. I used the default Godot robot sprite in this game, but it is not ideal in some ways because everything ends up looking the same, and when you put in the actual art you have to undo any scaling that was done to make the placeholder the correct size.

From Hell’s Heart

2024-05-14T22:46:00+02:00

From Hell’s Heart is my entry for Ludum Dare 55, the first Ludum Dare I have participated in since I made Out of Gas for Ludum Dare 48 in 2021.

I was not thrilled with it overall (and neither was anybody else - but we’ll get to that), but it was good to get into working on actual gameplay programming again after several years of only working on tooling, and it has inspired me to do a lot more gamedev work since.

The Concept

I was quite disappointed by the theme. I had an idea for the theme “It Spreads”, which was one of the final round themes, that I was very invested in. I was going to make a zombie shooter where the weapons were all spreadables like jam and nutella and so on, and I had a lot of fun art and gameplay ideas for that.

So when the theme of “Summoning” was announced I was disappointed. But, the theme is rarely the one I would prefer, so I got to brainstorming and came up with the idea of “reverse-Doom”, which evolved into something not explicitly Doom related, but where you play as a demon fighting soldiers nonetheless. For a brief moment I was even considering calling it “What if Doom but you’re the Demon”.

The thing I liked about this concept was that it allowed me to address the theme in two ways - you are a demon who has been summoned, and you can summon other demons to help you. However, the fact that it is perfectly playable and beatable without ever summoning your demon friends diminishes this somewhat!

One of my hopes for this jam was to try out my dialogue graph editor, Digression, in another game, and unfortunately there was no place for it with this concept. I used it heavily in Out of Gas and Gophers in the past, but it has been fleshed out significantly since then and is ready to be put through its paces. Oh well.

Art

I couldn’t get Pyxel Edit to run on my new computer when setting up for the jam (it is Windows only, and I have run it using Wine in the past), so I decided to branch out and try Pixelorama - a pixel art editor built in Godot. Although my muscle memory from Pyxel edit tripped me up constantly in minor ways it was a good experience overall and I think I will continue using it going forward, as I always prefer open-source and native applications when they are available. The only thing I really found lacking was the way it handles the grid/tiles. There are no tools for quickly copying and manipulating tiles, and the grid is specified in the global settings instead of being per-file, even though one grid is unlikely to suit different files even in the same project.

I also had to adapt the way I managed spritesheets, as Pyxel edit allows you to define multiple animations in a single file, with the frames being tiles, while Pixelorama will only animate the entire file as a single unit. As such, character sprites are spread across multiple files each. In Godot this means swapping the sprite texture for each animation, but that didn’t seem to cause any problems.

I made some big mistakes with the level art early on, initially designing it at twice the appropriate resolution for the characters I had in mind. I was able to take the basic design ideas and downscale them into the final wall and floor tiles easily enough, but it still wasted a lot of time. I designed them for an auto-tiling approach which I developed a while ago, where a tool script populates the floor tiles when you update the walls.

I based the character shapes roughly on the design I came up with for Guerrilla Gardening for Ludum Dare 41, which is very round and fun, and I’ve found works really well for shooter games. It also features outlines for the characters which means there’s less risk of ending up with characters that don’t show up well against the background!

I was quite pleased with the art overall, though when I designed the wall and floor variants for the opening “cutscene” I realised that the game is far too red overall, as the characters looked much better against the bluer background!

I am determined next time I do a jam solo to not do full animations for each character or game element, and instead use the animation features of Godot to bounce, squash and spin things to bring them to life. This will give me much more time to create a variety of characters and objects, which I think would contribute more to a jam game than full run-cycle animations. The only place I used this kind of technique in this game was for the spinning and pulsing of the portal, and I think it was quite effective. People do some great things with this kind of animation and I am missing out.

Music

Music is an element of jam games that I am always trying to find a new and better approach to, as it is something that I enjoy a lot but am not particularly skilled at. In the past I have used beepbox, LMMS and Bosca Ceoil with different degrees of success.

In the week prior to the jam I came across an application called Helio which I thought looked incredibly promising. It looked like it might be as easy to use as Bosca Ceoil but with a wider variety of possible instruments, so I was excited to try it out.

Another type of tool that I am always looking to bring into the fold is modular synth emulators. I have tried VCV rack in the past but never managed to use it for a game, and I recently came across a fork of it called Cardinal and had been practicing with that. I discovered that I could use Cardinal as a plugin for Helio and create instruments in it to control using Helio, so I planned to either do that or create a patch to generate all the music for the game, depending on what idea I was working on. The concept for From Hell’s Heart didn’t really seem to call for techno or ambient music, so I ended up trying the latter.

Unfortunately, things did not go smoothly at all with creating the music. I found Helio to be lacking in some essential features, and with a confusing menu system. It crashed constantly, forgetting instrument settings each time and sometimes changing the volume of notes or moving them around arbitrarily. I think the interface with Cardinal may have been responsible for some of this, and ultimately abandoned trying to use it for any instruments in favor of a selection of sound fonts. There was no way to preview the sound fonts in Helio, and I ended up previewing them on the command line using fluidsynth, but not all of the ones I found that I liked worked when loaded into instruments in Helio. It was just a frustrating mess all around.

Most bafflingly in terms of missing features in Helio, I couldn’t find a way of creating more than one pattern for an instrument, so I ended up having to use multiple tracks of the same instrument when I wanted a different pattern.

It also lacks a central mixer where effects can be applied. Instead you can add effects on a per-instrument basis. I tried to do this in Cardinal as well, but again abandoned that as time dragged on and the application kept crashing.

So overall it was a bit of a nightmare, took five precious hours, and the track ended up being overly repetitive, with just one melody repeated over and over with the only variation being different instruments coming in and out. I hated it when I was done, but it grew on me a bit when I put it in the game. It did kind of have the mood I was aiming for.

Every time I try to make music in Linux I feel like I am missing out on some brilliant workflow that ties a variety of different applications together with their different specialities, but I am just failing to grasp how it all works, and this time was no different. Back to LMMS next time I think…

Sound Effects

Somewhere that I did get to use Cardinal was for the sound effects! I mostly used the Audible Instruments synth modules with a variety of different setting, and used Audacity to record different notes being played for variety. Some of the results I was really pleased with (the demon snarls), others much less so (the enemy voices, which sounded like robots saying random words), but overall it worked pretty well. I would have preferred to do some foley stuff but there wasn’t time, and it was a step up from SFXR at least.

Code

Since my long-time project, Just a Robot, is a shooter, I had a fair bit of base code to plunder for this jam. I don’t think I did or learned anything particularly interesting this time around, but the base code did include a technique for showing a character silhouette when they are obscured by a wall which is interesting enough, and some automatic configuration of floor and mask tilemaps to allow rooms to be banged out quickly with little possibility of error.

The trick to the silhouettes is to create a mask of the parts of the walls that should obscure game entities using a BackBufferCopy node, and then check that mask in a shader on any sprite that should be obscured. Objects in the game do not need to be children of the TileMap, and in fact there is a different TileMap for walls and floors.

The mask TileMap is populated automatically in the editor using a script like this:

@tool
extends TileMap

@export var copy_map: NodePath
@export var copy_from_layer: int = 0
@export var copy_to_layer: int = 0
@export var refresh_frequency: int = 10

@onready var _copy_map_node = get_node(copy_map)

var time = 0

func _process(delta):
    if Engine.is_editor_hint():
        _tool_process()

func _tool_process():
    if copy_map != null and refresh_frequency > 0:
        _copy_map_node = get_node(copy_map)
        var current_ticks = Time.get_ticks_msec()
        if time == 0 or current_ticks - time > refresh_frequency * 1000:
            time = current_ticks
            _copy_map()

func _copy_map():
    var cells = _copy_map_node.get_used_cells(copy_from_layer)
    self.clear_layer(copy_to_layer)
    for cell in cells:
        if not _copy_map_node.get_cell_source_id(copy_from_layer, cell) == 0:
            self.set_cell(
                copy_to_layer,
                cell,
                _copy_map_node.get_cell_source_id(copy_from_layer, cell),
                _copy_map_node.get_cell_atlas_coords(copy_from_layer, cell),
                _copy_map_node.get_cell_alternative_tile(copy_from_layer, cell)
            )
    self.fix_invalid_tiles()

The mask tileset just has 100% red everywhere that should be obscured, so the shader just checks for red in the screen texture and displays a grey colour instead of the sprite’s texture anywhere it finds it, leaving the alpha intact:

shader_type canvas_item;

uniform bool hide_when_occluded = true;
uniform sampler2D SCREEN_TEXTURE : hint_screen_texture, filter_linear_mipmap;

void fragment() {
    vec4 mask = textureLod(SCREEN_TEXTURE, SCREEN_UV, 0.0);
    if (mask.a > 0.0) {
        if (mask.r > 0.9) {
            if (hide_when_occluded) {
                COLOR.a = 0.0;
            } else {
                COLOR.rgb = vec3(0.2, 0.2, 0.2);
            }
        }
    }
}

It turned out that people really hated the tight corridors and enemies being obscured though, so I probably won’t be using this technique again!

A similar script to the one that populates the mask also populates a TileMap with floor tiles based on the wall tiles. The floor tiles have a different size than the wall tiles however, so it is a bit longer and more involved. I think I would prefer to just put floor and wall tiles on different layers of the same TileMap in the future, or as TileMapLayers or whatever is being introduced in Godot 4.3…

Another neat thing I did in the editor was to have spawn points for portals and enemies draw a line to the thing they are associated with, or an obvious warning if they are not configured correctly. This helped me ensure that everything was set up properly when rushing through the room designs in the last few hours of the jam! I am trying to get into the habit of adding this sort of tooling to everything that might benefit from it.

@tool
extends Marker2D


@export var destination: GameRoomSpawnPoint


func _process(delta):
    if Engine.is_editor_hint():
        _tool_process()

func _tool_process():
    queue_redraw()


func _draw():
    if Engine.is_editor_hint():
        if destination != null:
            _draw_to_destination()
        else:
            _draw_warning()


func _draw_warning():
    self.draw_circle(Vector2(0, 0), 15.0, Color.RED)


func _draw_to_destination():
    self.draw_circle(Vector2(0, 0), 15.0, Color.GREEN)
    self.draw_line(
        Vector2(0, 0),
        destination.global_position - self.position,
        Color.GREEN,
        1.0
    )

I also took from the base code a node-based state machine for enemy AI. This turned out to be a bit confusing and inflexible, and when I tried to introduce some new behaviour on the final day I ended up making the game crash constantly, and had to roll back. I’m still unclear on exactly what went wrong there - I was getting null references due to the summoned allies despawning, even with null checks before referencing them. It was probably really obvious but I was exhausted by then. In any case there were other problems with the state machine I developed and I have started investigating the Godot plugin Beehave as an alternative for the future.

Something that did not work very well was the enemy navigation and avoidance. I completely misunderstood how the avoidance system was supposed to be used, so it was actually not in play at all. In experiments I’ve done since the jam I got it working to some extent, but it seems like it does not work very well anyway, with agents just grinding to a halt in many circumstances even after avoiding an obstacle! The navigation itself would have worked much better with one small settings change of path_postprocessing in the NavigationAgent2D to “edgecentered”, as I discovered later. As I had it for the jam, navigation agents are always getting stuck on wall corners…

Results

My game got lots of nice commments, and also a lot of complaints about out-of-bounds glitches, enemies being obscured by the walls, and being too easy.

I was uninspired by the theme this time around and my skills were somewhat rusty in every area, and the game was generic and buggy as a result, so I was unsurprised by the negative comments. I did think it looked good and was reasonably juicy and sounded alright. I wasn’t expecting great overall ratings, but I did think it would do ok in the graphics category at least. However, the ratings were quite bad across the board, at least compared to previous jams!

Category	Rating	Placing	Percentile
Overall	3.571	574	65th
Fun	3.63	418	75th
Theme	3.413	792	52nd
Innovation	2.739	1080	35th
Humor	2.609	823	50th
Graphics	3.935	428	74th
Audio	3.619	343	79th
Mood	3.457	686	59th

This game did worse in almost every category in percentile terms than my Ludum Dare 38 entry which I didn’t even complete - it was just an opening scene with a short dialog and no gameplay. Quite a drop from my “Gophers” peak!

Post-jam and Take-away

I won’t make my usual promise to work on a post-jam version of this game, both because it’s not interesting enough to be worth it, and because I never keep that promise anyway!

Instead I have been inspired to start working on Just a Robot again since the jam, trying to get combat and enemy behaviour working the way I have always envisioned them, to see if it would actually be fun. The idea is to make it a cover-based shooter where the enemies abilities are close to the player’s, more or less, and combat feels weighty and dangerous in a way that is distinct from bullet-hell shooters.

I successfully implemented a cover system for the player, but when I went to enable the enemies to use it and switch to using Beehave for their AI I quickly discovered that the way I had built them so far was too centralised and inheritance based, so after watching a few tutorials and considering things a bit I decided to start again mostly from scratch with a more composition-based approach. This is working really well for the player so far and I’m nearly back at the same point as I was previously.

I also thought about and experimented with tiling approaches a bit, creating both a very small scale autotiling tileset with multiple terrains, and a mockup of a more organic looking tileset with a wide variety of designs, angled walls and floor sections and the like. I am tired of creating boxy, uninteresting levels. I was initially inspired in my gamedev journey by the art and design of Hyper Light Drifter, and I want to get back to achieving something of that look and sense of verticality - maybe not in jam games, but in Just a Robot.

I started on a greybox version of the above to actually use in designing the game, but it’s not quite finished yet.

I Accidentally Visual Scripting

2023-11-30T22:31:00+01:00

For some months now I’ve been trying to make some progress on the game I’ve been “working on” for probably the better part of a decade, Just a Robot (yep, 7 years ago was the first post there, and it was already in progress for a few years before that!). I haven’t really been working on it for most of that time, though it has always been in the back of my mind.

While I have re-implemented some basic gunplay mechanics, and experimented with auto-tiling and the like, my main task has been improving the editor for cutscene graphs that I designed previously (and which I’ve mentioned a few times before) based on my experience of using it in a couple of jam games, and the anticipated requirements for this game.

I am also hoping that it will be something that other people might find useful, and that I can release in the Godot asset library. As such I try to do things in a generalised and user-friendly way, with nothing that would tie it specifically to my game, or rough edges that I would just ignore myself but be embarrassed if other people had to deal with them.

As a result, it’s taking quite a while!

One thing I’ve noticed is that as I try to maintain flexibility I seem to be implementing tiny haphazard visual scripting systems for calculating values and defining conditions. Of course the graph editing is itself a type of visual scripting, but that that was both what I was expecting to be designing, and has well established UI conventions in the engine. I don’t think there are any conventions or controls for defining values and conditions in the way that I am.

Variable Changes

In the initial incarnation of the graph editor, it was possible to set the value of variables, and branch based on the value of variables, but the way it was implemented was… not good.

Variable names were entered as strings. This seemed like a problem to me - as the scope of a project grew I anticipated that it would become harder and harder to keep track of what variables were being used, and if they were entered correctly everywhere.
Values were also always strings - if you wanted a boolean, just enter “true” or “false”!
There was no scoping, just one global pool of variables for all graphs.
You could only assign constant values to variables. No incrementing or decrementing, arbitrary calculations, or using the values of other variables.
You could only compare to constant values for branching.

My initial changes to improve this situation were to introduce scoping and type definitions for variables. Variables could be scoped to the graph, to the area (i.e. “level” or “room” or however the game wanted to define it), or be global. They could also be boolean, int, float, or string. The UI would change to reflect the type, so you would get a checkbox for booleans and a numbox for numbers.

This was better, but still kind of awful, because everywhere a variable was used the scope and type would have to be selected again! Unlike in code there was no way to declare a variable once and then use it elsewhere with its type and scope already known.

So next… I implemented variable declarations, more or less! These are defined in the project, and anywhere that a variable is required in a graph it can be selected from a searchable dialog.

Now I felt like I was getting places, though the problem of only being able to set and compare constants remains, and is what I’m currently tackling. But more about that in a minute.

Choice Conditions

Another feature of the initial version of the graph editor was the ability to make dialogue choices only conditionally available to the player - for example making a choice dependent on having encountered a particular character or completed a particular quest. This was of course based on the comparison of a variable to a string constant, so it had all the same deficiencies as everything else about the variables, as well as a few of its own:

Only one variable could be used for each choice.
The only comparison available was equality, no greater or less than or anything like that.
There was no possibility of negation.

The minimal improvement would be to allow a comparison of a single variable with a selectable operator, and a constant value. But what if the choice depends on the value of multiple variables? What if you want to make different choices available if the player has encountered a character but not completed a quest, than if they have done both? This could maybe be achieved using branching nodes to set a third variable, but that seemed like jumping through a lot of unnecessary hoops. I wanted to be able to define complex conditions directly on the choices.

My solution was to add a dialog where an arbitrarily complex condition can be defined - though currently only with constants on the right side of any operator.

As you can see above, the condition is structured as a tree with boolean operators grouping the results of comparison operators. The whole condition is summarised as its (frankly much more understandable) equivalent GDScript.

So mission mostly accomplished - it was now possible to define conditions on choices with an arbitrary number of clauses. However, it was starting to seem like a lot of UI complexity to achieve something that is quite simple to do in code - almost like a type of visual scripting…

Visualising Values

Now it’s time to tackle the other side of the equation - the values to set or compare the chosen variables to.

For setting variables, I wanted it to be possible to increment or decrement values as well as setting static ones… But why not also allow values to be multiplied or divided? What if you want to set a variable to 2x another variable, or the result of a more complex calculation? These don’t seem like particularly likely requirements for my game, but why reduce the flexibility by only allowing a handful of fixed operations?

For comparisons, I initially only considered allowing a choice between a constant or another variable. But would these not also benefit from more flexibility? What if you want to check if a variable is greater than half another variable? If setting variables was as flexible as described above, this could be achieved by setting a temporary variable, but that seems unnecessarily round-about and annoying to have to do. Since the task is the same for both situations (obtain a value for the right side of an operator), it seemed like it would be prudent to create one control that would cover both.

Another factor is that most of the above concerns only apply to integer and float variables. Booleans have another set of operators that might be applied to them. Strings have a more restricted set of operators, but there are a variety of functions that you might want to apply, or methods that you might want to call on them - to_lower, rstrip, replacen, etc. In fact, the same might be true of integers and floats…

With all that in mind the requirements have become quite complex - I’m faced with implementing a small but significant subset of GDScript in a GUI!

The design I have so far allows for multiple variables or constants to have operators to be applied between them, grouped by brackets if necessary, and for a selection of appropriate (for the type) functions to be called:

One thing that annoys me about this is that it’s much the same structure as is involved in creating the conditions (a tree), but uses completely different controls and looks and works completely differently. It’s going to look quite strange when they are side by side in the conditions dialog… However, the tree control used for the conditions probably suits that better because the elements need to be selectable, and the “prefix notation” also suits it better I think, while it would be unfamiliar for most people for mathematical operators.

I can’t really tell at this point if this is at all intuitive or if there’s an obviously much simpler solution that I’ve overlooked. But it certainly makes me long to be able to just enter the values as code, regardless of their composition.

Could I Uuuh… Do That?

I have been thinking about what would be involved in allowing the user to enter conditions and values as the GDScript code they would likely already be familiar with.

Godot includes an Expression class which can be used to parse and execute arbitrary expressions, so conceivably that could be used to run whatever the user input, and make the entire GDScript language available to them. It looks like it can even parse the text for errors before running it, which would be all that I would want to do in the editor anyway. One likely difficulty is that the referenced variables would not actually be GDScript variables at runtime, but entries in one of several dictionaries, so I might have to write my own parser anyway to pick those out and replace them. I’m not sure I really want to do that.

If that didn’t work out, the alternative would be to parse the input myself (even more parsing!) and convert it into the same resource structures that I’m intending to have the UI create. This would likely be much more limited in which language constructs and operations it could support - and that might cause confusion or frustration for the user.

And, there are reasons why allowing these things to be defined as code might not be a good idea anyway:

I don’t really like the idea of having to switch from a GUI way of doing things to a code way of doing things when the rest of the plugin is very much GUI driven.
I don’t like the fact that the predefined variables would not be selectable, negating some of their utility. Or at least, to make them selectable I would have to implement some sort of auto-completion on top of everything else, which might be beyond me!
Some people use C# with Godot, and it’s unclear if the Expression class can parse C# - I suspect it can’t.
Using the Expression class would likely allow arbitrary GDScript to be entered and executed during graph processing. That might be too much flexibility! If I want to allow that it will be its own node type.

One other GUI option I can think of would be to allow value calculations and conditions to be defined using their own type of graphs. This might have the advantage of using well established UI conventions and existing controls. On the other hand, a graph editor is not ideal for defining a tree, and it would probably appear even more unnecessarily complex and confusing for the undoubtedly most common use cases of setting variables to constant values and defining simple conditions based on single variables. It would also not be any less work for me!

Conclusion

UI is hard

Hyperlink Your Heart - godot4

Lovely, Dark and Deep

The Concept

What Worked

Digression

Use of Resources

Audio

Art

The Humour, apparently

What Didn’t

Digression

Gameplay

Bugs

Results

Post-Jam

Future Developments

From Hell’s Heart

The Concept

Art

Music

Sound Effects

Code

Results

Post-jam and Take-away

I Accidentally Visual Scripting

Variable Changes

Choice Conditions

Visualising Values

Could I Uuuh… Do That?

Conclusion

All My Yield()s, Gone!

Cutscene Graph Editor Status

Update: Pure Signals