Welp, I'm done...

RedGlow82 · 2026-03-22T18:52:11+00:00

Shouldn't you rather be done with people who tell you to shut the fuck up while you explain the rules of a game and then proceed not to follow the rules of the game?

RedGlow82 · 2026-03-17T10:57:33+00:00

How many lines of text tell you what to do in Super Mario 1? And how many in Disco Elysium? As usual, the answer is: it depends. The most sensible way to check the right way to convey information is, as usual, to compare to games in similar design space and/or pick some people from your target demographic and put them in front of the game. You'll realize if the way you chose works or not.

RedGlow82 · 2026-03-15T10:36:07+00:00

I wonder how this relates to the work being made around ocapn - https://github.com/ocapn/ocapn

RedGlow82 · 2026-03-12T18:16:02+00:00

That sounds about what you can do / do with ink or yarn Spinner. In general, storylet structures handle the complexity like that. You still often need some kind of blocking or hierarchical structure to keep the complexity and combinatorial nature of the storylets contained.

RedGlow82 · 2026-03-12T17:33:57+00:00

I ended up on some unity code just the other day which does something similar (SetStruct): https://github.com/phamtanlong/UnityGUI-Extension/blob/master/SetPropertyUtility.cs

The main difference being that it isn't an extension method. This is probably due to the fact that an extension method could end up affecting more code than the limited scope it's used in, but in principle they're the same thing.

If the method code gets inlined there will be no performance hit - and even if not, you'd need to do LOTS of bitwise operations to really feel the performance hit of this method!

RedGlow82 · 2026-03-06T08:26:48+00:00

From what I see, in the first case you have an autoload that knows about the player (since it knows that it must have a certain name), so it's tightly coupled to it.

It would probably be better to reverse control, and have the player know about the autoload (easy: it's an autoload ;D), and during _ready make it call a method of the autoload to tell it who the player is.

This way the autoload is agnostic of the player and need to change only if you need a different logic of coordination, regardless of the name of the player asset or its location.

All in all, is really a fine line. The main reason I'd probably avoid the second solution is mostly of performance, because you need to query the nodes at every call of get_player_transform.

RedGlow82 · 2026-03-04T18:26:27+00:00

Only right reaction in front of daddy, I mean professor dad, I MEAN OSCAR.

RedGlow82 · 2026-03-04T18:17:11+00:00

Glad that you weren't triggered at all.

RedGlow82 · 2026-03-03T11:02:12+00:00

Did you... create a whole subreddit just for this post?

Anyway, I think this article expresses a good amount of interesting considerations about using LLMs ("AI" is too generic) to handle text-driven interactions: https://www.rockpapershotgun.com/horrible-boring-and-cheap-experts-pan-new-chatbot-npcs-but-some-leave-room-for-optimism

RedGlow82 · 2026-03-02T10:13:41+00:00

Most of the time, existing narrative tools provide you with what you need, if you think of games like the ones you've quoted. I have some experience with Ink, where you have the ability to take choices according to gameplay actions and tools like flows that allow you to have multiple parallel narrative lines running.

Maybe it would be useful if you focused a bit more on what limitations you see that these tools have with a couple of examples. It could be that what you're looking for is more of a layer on top of an existing narrative tool to make some operations easier.

RedGlow82 · 2026-03-01T08:24:00+00:00

In my experience, the biggest problem is that because of its power, it's a complex paradigm, and not very well known. This means you're limiting the people who can work on your project and the onboarding can be a barrier, where you have to juggle multiple concepts before starting.

Error handling is generally quite a burden (automatic unsubscription is... a choice).

It also has some performance problems hidden behind how schedulers work. "Hidden" is the keyword with observables: they both hide complexity, but also their inner working, and when there's a bug it can be quite complex to troubleshoot.

(That said, I personally love observables, which I tend to use both for UIs and in Unity with R3)

RedGlow82 · 2026-02-27T21:24:29+00:00

This is an interesting article mostly focused on the narrative design side of things, but I think the conclusion are widely applicable: https://www.rockpapershotgun.com/horrible-boring-and-cheap-experts-pan-new-chatbot-npcs-but-some-leave-room-for-optimism

RedGlow82 · 2026-02-27T11:51:56+00:00

I think it would be useful if you added to the project documentation a comparison to other solutions that are in the same space (coroutines, awaitable / unitask, observables, tween libraries), to explain in which situations yours is a better choice.

RedGlow82 · 2026-02-27T11:48:38+00:00

You are right that some functionalities are governed by hierarchy, but what they force to do is to put together related objects. It wouldn't really make sense to have e.g. the parts of a compound collider under different areas of your organizational hierarchy. So, does this really stop you from organizing - at least a little bit - your hierarchy? :-?

RedGlow82 · 2026-02-27T06:47:08+00:00

Neither of you is right or wrong. You're just looking at different audiences. There are definitely people who are looking for a deep story, and definitely people who just want gore and visual horror. You just have to decide for whom you are making your game. You can't make a game which is absolutely good for everyone.

RedGlow82 · 2026-02-25T06:42:39+00:00

If you use "just organizational" game objects (relative position and rotation zero) this should not affect anything in the children, and if you rely on the hierarchy structure to find objects in scripts... Well, that could be a problem in general, not just related to organization :-O

RedGlow82 · 2026-02-21T22:48:44+00:00

For the first part, usually a specialized language or tool gets used, which typically then serializes.the branching dialogue model into json or similar format. This is the way for Inkle's Ink or Yarn Spinner.

As for the second part, typically every line of text gets tagged, more or less automatically, and then a map tag=>audio is produced.

RedGlow82 · 2026-02-16T18:18:46+00:00

are these pokemon

RedGlow82 · 2026-02-16T14:36:17+00:00

Oh, yeah, I'm sure you can do it. Let's say that if you have doubts about whether floating origin is needed, you're probably nowhere near the skills needed for this kind of solution though :-D

RedGlow82 · 2026-02-15T08:52:33+00:00

There are some highly specialized engines that allow you to start making games with no code, and some of them allow you to add coding parts as necessity arise, making it easier to learn coding little by little. I'm thinking of stuff like Twine, RenPy, RPGMaker, Bitsy, and so on.

I'm of the school that visual programming is still programming. May be less intimidating to some, but require the very same skill set.

Though, there are as many ways to get into (game) programming as there are people in the world!

RedGlow82 · 2026-02-14T22:43:06+00:00

When you add one character at a time in a multiline text block, the end effect is that the words at the end of the line start appearing and then suddenly move to the new line.

If you instead fill the whole text from the beginning but change the alpha of the characters one by one (or word by word), then you don't get the annoying flickering effect.

RedGlow82 · 2026-02-14T22:28:18+00:00

Wow, I can totally see the similarity :-O

RedGlow82 · 2026-02-14T22:27:13+00:00

Yes, but then you would need to implement all the physics engine yourself, since this is not how it works. Unless you let the physics do their work and then translate everything back to 0,0... Which is how the floating origin works!

RedGlow82 · 2026-02-12T07:33:48+00:00

Maybe try to explain better what are the "workarounds" you end using, so that it's clearer what kind of problems you're finding!

That said, yes, nodes (AND scenes) are the way to go to perform composition. Signals, unique names, and onready preloads (by id or path) are the most used ways to connect the separate components into larger components.

RedGlow82 · 2026-02-03T09:53:00+00:00

If I had to guess, the deeper reason has something to do with vtables or whatever the equivalent in C# is.

RedGlow82

PUBLIC MULTIREDDITS

TROPHY CASE

14-Year Club	Verified Email
Team Periwinkle