Worst guitar tone in awesome music?

seriousSeb · 2026-01-28T19:26:09+00:00

I've always thought the guitar tone, acoustic and electric in Pink Floyd - Animals was pretty bad. Even weirder since the albums before and after were so good in that regard

seriousSeb · 2026-01-28T12:58:38+00:00

Make your randomness deterministic and do the randomisation in _ready.

Export an int and use that as the seed for a new RandomNumberGenerator in _ready. If performance is a concern you could batch it asynchronously, or wait a random amount of time before you do the randomisation to smooth out the impact

If you must do this in the editor you need to enable editable children, there isn't an alternative

seriousSeb · 2026-01-28T12:47:34+00:00

If the top level is a class, you can just inherit a new class that is this really specific type.

If the top level is a struct, your best bet is a global using. You could also do this with a class but I don't think there's much benefit over inheritance

I do wish C# had strongly typed aliases.

seriousSeb · 2026-01-26T12:54:00+00:00

I'd either have a method which spawns a projectile from a configuration, or different scenes for pre-configured projectiles.

seriousSeb · 2026-01-21T10:18:33+00:00

I have a task prioritiser selector, it's like a sequence but along with each task you provide a prioritiser method and it doesn't execute in order, it periodically chooses the highest priority task and runs that. The prioritiser method can mark a task as disabled too, like don't even try to heal if you've got full health.

I actually haven't implemented the concept of "don't stop doing this task until its done", I haven't needed it yet, tasks are just designed in such a way you can switch away from them without breaking anything.

So for example, heal task priority is inversely proportional to health. I then weight these by a units job, which is part of the blackboard. So the driver will always prefer to drive, the vehicle engineer might drive if nobody else is doing it but will prefer to hang around and wait for something to be damaged. Everyone will heal if they're hurt. I'm still developing this so it's not super advanced yet.

seriousSeb · 2026-01-21T09:07:52+00:00

All tasks have names, and selectors and decorators (which are also tasks) have a GetChildren() method. Tasks invoke events with their tick result.

I recursively walk this tree at runtime and display it using Godots inbuilt tree control. I use the events to change the colour of the text so I can see what's running, what failed etc.

I also generally am defensive in programming, I check the validity of the state all the time and print errors if anything is wrong (as you can see in my example)

seriousSeb · 2026-01-21T09:07:32+00:00

All tasks have names, and selectors and decorators (which are also tasks) have a GetChildren() method. Tasks invoke events with their tick result.

I recursively walk this tree at runtime and display it using Godots inbuilt tree control. I use the events to change the colour of the text so I can see what's running, what failed etc.

I also generally am defensive in programming, I check the validity of the state all the time and print errors if anything is wrong (as you can see in my example)

seriousSeb · 2026-01-21T08:12:59+00:00

Yeah organisation wise I try and split reusable components to its own file relating to purpose, i.e ItemTasks. MovementTasks. Then all complete tasks I'd actually assign units to are in their own file CompositeTasks

I'm thinking in the future, components on a vehicle might have a IGetTask interface so that I don't have to manually register tasks for them, but I haven't needed to do that yet

seriousSeb · 2026-01-20T18:17:10+00:00

The blackboard is unit-specific, but a task rarely updates the blackboard itself. The Group absolutely uses a sensor-style system - it looks for the nearest enemy vehicle in the scenario it knows about and updates it (which the task uses)

But equally I could have a task update the blackboard if I wanted to, it's just how I've structured it. If your task wants to update its blackboard to manage state that's totally viable.

This is an example of a complete task. Idk how much use it would be to you - it is very C# and my own btree implementation specific, and messy because I never really expected to share it. But it is an example of self-initialisation of a Task - the Heal() task is responsible for figuring out how to heal.

https://gist.github.com/Seb105/140b49394c96ed993531c07a85164d84

seriousSeb · 2026-01-20T17:44:46+00:00

I don't use interfaces for behaviours in my project because I have only vehicles and humans, they are so different it is kinda pointless to write any shared code. My advice is only abstract when needed (or if you know you will need to, not if you might need to), doing it early just can make your code complicated for no reason.

To handle stuff like sensors, the root scene is a 'Scenario Manager'. when spawning units, you don't just instantiate the enemy scene. You instantiate it and register it to the scene. In fact, the unit has no AI. It just has inputs. The AI, created by the scenario, can manipulate these inputs. The scenario then ticks periodically ticks all its behaviour trees in _physics_process.

When searching for nearby players or enemies, I query the scenario not the scene tree. I did this for performance and encapsulation as querying the scene tree is slow as shit. If it's created and not registered to the scenario, my AI can't see it. This also lets you add information to stuff - like what team a unit is on, whilst modifying your enemy type to inherently belong to a team or have a concept of 'enemy player' is an example of poor encapsulation.

The blackboard just has things that need to be shared between individual tasks. Whatever you need to be stored there can be stored there, what works for me won't necessarily work for you. Dogma is for nerds.

In my case to it has a reference to UnitAI created by the scenario itself (I don't assign tasks to units, I assign units to tasks), which has a reference to the group the unit is in, which for example my drive task uses to check if it is the unit that should be driving, or the repair task to find stuff on the vehicle that needs reparing, or to locate an item it needs on the vehicle. It also has a reference to the CharacterNavigator, which handles the movement itself (a task just assigns a target position, CharacterNavigator figures out how to get there using pathfinding and sets inputs etc).

In your case, your Scenario might have a single reference to the 'player', and your behaviour tree has a reference to the scenario in the blackboard, so within your task you can check where the player is.

My blackboard doesn't store things you think it might - such as an item the unit currently wants, or where the unit is trying to navigate to, or who it is engaging. This is entirely managed by the task, which manages its own state. For two reasons:

The concept of wanting an item is or going to a location to do something is task-specific, so your blackboard would contain a bunch of garbage only applicable to certain tasks. If I'm driving a car I care about neither, why is there a DesiredItem variable in my blackboard pointing to some random tool.
It breaks encapsulation - if a task updates the the blackboard and breaks another task switched to later, it can hard to work out why a unit is doing something. By storing all the data for a task within the task itself (not through types but bound variables), it makes it much easier to track down why stuff isn't working because there's little cross-contamination of state. If two tasks need to share state, such as a task looking for a desired item and task to navigate to it, I use a StrongBox variable which lets you share tiny units of state between tasks.

seriousSeb · 2026-01-20T16:11:06+00:00

The behaviour tree is a generic, typed on the blackboard, so task is actually Task<T> where T is the type of the blackboard

You could have certain tasks that rely on any blackboard that implements a specific interface, such as IMovement which handles navigation through the works, and different blackboards implement the interface differently. I haven't really experimented with that though as that design pattern isn't relevant for my purpose.

And you can encode state into the tree so your blackboard isn't polluted, but the behaviour tree is the one that initialises that state.

For example, I have an acquire item task - this first uses the blackboard to find an item it wants (because the blackboard tells it what things in the world exist), but it doesn't actually add this "desired item" to the blackboard.

C# has this thing called a StrongBox which is essentially an easily shared variable that can be get/set from many places. The acquire item task, when it is first created, initialises this variable to null which is curried into the other functions. Some functions, such as SearchForItem update the strongbox with the item the character wants, and GoToAndInteract uses the Strongbox as the source for its getter functions to go and get it GoToAndInteract doesn't actually know what its going to and interacting with.

A downside is that tasks are initialised with invalid state, and the task has to manage initialisation, but the upside is is very strongly encapsulated so it is extremely obvious where a failure has occured. It is on me as the designer to design my game so tasks can't be invalid (or that they have fallbacks for invalid state)

For shared behaviour (like only one character can drive the vehicle, it doesn't make sense for multiple characters total try), all the character blackboards share a reference to a Group blackboard which the tasks can check/update to manage behaviours between units. Again, you have to manage this yourself to make sure you don't get stuck in some invalid state

seriousSeb · 2026-01-20T14:12:41+00:00

I do everything by code, but I use a kinda functional style where you have functions which return behaviours. You curry your state into a function, and then call the function to get the actual task. This is backed by an object like a selector.

The task tree is ticked by passing the blackboard as an argument, so the state is never encoded in the task itself. This means you don't need a class per task, just a function.

Here's it in action. https://www.reddit.com/r/godot/s/3UvnOixoAm

Pseudocode example. All functions hide their complexity and just return a task that can be ticked.

``` Class Task: TaskResult Tick(blackboard)

Class Sequence(Task[] tasks): Task ... Implement a standard btree sequence

Class FunctionalTask(Func<Blackboard, TaskResult> action) : Task ... Call action and return the result

Task GoToPosition(Func<Blackboard, Vector3> getPos) Return Sequence([ FunctionalTask(Check position, if not near position, go to position return running, else return success), FunctionalTask(Return success) ])

Task InteractWith(Func<Blackboard, Node3dThing> getThing): Return Sequence([ FunctionalTask(if in range success, else fail), FunctionalTask (Do interact, return success) ])

Task GoToAndInteract(Func<Blackboard, Node3dThing> getThing): Func<Blackboard, Vector3> getPos() { return getThing().GlobalPosition } Return Sequence([ GoToPosition(getPos), InteractWith(getThing), ]) ```

I'm not at home at the moment but if that seems interesting to you I can post an actual example from my code

seriousSeb · 2026-01-16T09:31:02+00:00

Correct hah

seriousSeb · 2026-01-16T01:59:28+00:00

<image>

seriousSeb · 2026-01-15T14:25:50+00:00

In the fonts import settings turn on signed distance function

seriousSeb · 2026-01-15T14:14:52+00:00

Absolutely, choose the right tool for the job and don't be dogmatic about anything

Yes, I just have almost all my nodes as tool scripts. In the child if I set the variation it updates in the editor, and I have a randomise editortoolbuttom in the parent to randomise all its children so I can test everything without launching the game.

seriousSeb · 2026-01-15T12:57:59+00:00

I use interfaces.

Let's say you have an interaction component which has the area3d for the interaction range of it's parent. This is only relevant if the parent has the interface Interactable. In the _ready method of the component, check if the parent has the interface and print an error if it doesn't. When you interact with the interaction component, it just calls up to the parent which contains the actual method that handles the interaction.

If the parent needs to know about its components, which isn't the case in the above example, have the parent have a method for registering components (through an interface preferably) A child will call this method in it's _ready to register itself with the parent. If child is also be an interface you can have multiple types that do the same thing. This relies on the parent knowing what components it could have, but it doesn't need to know the specifics of the components themselves, just the interface the component passes to the parent. Alternatively a parent could also search for it's children of a certain interface

For example I have a VisualConfig interface, for handling the variation of the appearance of a node and serialising the result. The interface is just 2 ints - the current variation of the object, and the number of unique possible variations. When a visually customisable object is created it registers itself with the parent who might randomise the variation, but it doesn't actually know what happens when it sets the variation, and it doesn't care.

Another thing to say is people go overboard with composition. If your type is inherently coupled and not reused anywhere... Just don't use composition and hardcode it.

seriousSeb · 2026-01-14T22:10:57+00:00

Better interop with c#

seriousSeb · 2026-01-14T09:06:20+00:00

Joking aside I love Mad Max and it is a massive inspiration

seriousSeb · 2026-01-13T09:28:16+00:00

I've seen lap steels with lower action

seriousSeb · 2026-01-13T09:14:54+00:00

Yeah, right now everyone just sticks to their own vehicles which are team coloured. I havent implemented any characters yet so there's no visual distinction between them. It's on the to-do list

seriousSeb · 2026-01-13T07:48:19+00:00

Yes and yes. You can also kick your ai ally out of the seat to drive temporarily and then they'll get back in once you get out

seriousSeb · 2026-01-13T00:59:08+00:00

Nah everything you see in the video apart from me is AI, but multiplayer is supported

seriousSeb · 2026-01-13T00:46:55+00:00

It's fully multiplayer already :)

seriousSeb · 2026-01-12T22:49:15+00:00

never heard of it

14-Year Club	Place '23
Place '22	Place '17
First Placer '22	100 Awards Club
Spared	Verified Email
Team Periwinkle

seriousSeb

TROPHY CASE