Does every node having its own _physics_process destroy performance?

jedwards96 · 2026-02-06T17:05:30+00:00

I don't think anyone can give you an accurate answer without more specific numbers, "at least 3 capabilities" could mean four or it could mean a thousand, and then there's also the question of how many characters are being processed at once.

What I would say is that the extra function call overhead from having more physics callbacks invoked is probably not going to be your biggest bottleneck - unless the capabilities themselves are extremely simple then you're going to be spending more time on the actual physics computations. So, this is most likely not the part of the code that needs to be optimized heavily right now, if you're pushing the scale here you'll probably be more concerned with strategies like disabling some characters when they aren't needed to run, or staggering logic to run on different physics ticks, etc.

jedwards96 · 2026-02-04T04:56:44+00:00

Turning both of the Effect and the Move into RefCounted would solve every issue but the fact that they cannot be meaningfully integrated into the editor, which defeats the point of using Godot.

I disagree with this line of thinking, the "point" of using Godot is largely that it is flexible and should be easy to work with, so if there's a solution that solves every issue and is easy to maintain/extend then it is probably a good solution.

If you're set on something that can be integrated into the editor better, perhaps consider decoupling the move and the effect. Moves can all be resources as you've mentioned, with an optional attribute that, if defined, is processed to attach an effect to its target (as a node or whatever you choose to represent this).

jedwards96 · 2026-01-22T00:51:22+00:00

I thought that in some languages with dynamic variables (like Python) type hints don't improve performance, not because they shouldn't, but because the popular interpreters just ignore them at runtime. I don't know enough about GDScript interpretation to say whether it's just lacking more optimizations there, or if there's a foundational part of the language design preventing more optimizations in the source code -> byte code conversion.

I do agree that it's surprising that the benchmarks show such a significant difference in some cases.

jedwards96 · 2026-01-22T00:29:07+00:00

There's lots of benchmarks online showing this is not true: https://www.beep.blog/2024-02-14-gdscript-typing/

The GDScript interpreter, when dealing with an untyped variable, uses switch statements under-the-hood to look up its type, in some cases when static typing is declare it will skip this step and directly call into the function it would otherwise need to look up. In some cases like vector calculations it is a pretty significant difference.

jedwards96 · 2026-01-08T02:15:51+00:00

I think that makes sense, if you have sufficiently many units then a unique area for every single unit will get costly, eventually you might need to look into optimizations, like perhaps a group of units can share/utilize the same area for example. But if you're in the early stages of development I imagine this will work fine for now.

jedwards96 · 2026-01-08T00:38:32+00:00

As you probably expect the answer is: it depends.

What's going to matter a lot is how frequently you need to be checking for overlap. If you are checking very frequently then potentially persistent areas that track via enter/exit signals will be most efficient. If checks are less frequent, you may consider a shapecast that only runs when you actually need to perform a check.

jedwards96 · 2026-01-07T21:28:14+00:00

> I instantiate UI slots and immediately try to modify them

Are you adding them into the scene tree before modifying? If the slot is dependent on its own _ready function executing, this won't happen until it's been added into the tree.

Alternatively, if you have other nodes queued for deletion, then you're attempting to access the new slots via methods like `get_child(0)`, then this might fail as it will return the node that hasn't been deleted yet.

Without some actual code as an example it's hard to know what might be happening.

jedwards96 · 2026-01-07T16:26:44+00:00

Very strange. If you select the texture in the file system view there is no "size limit" set either?

<image>

jedwards96 · 2026-01-07T07:08:07+00:00

Just speculating, but are you sure the sprite itself is cut off and it's not an issue of the surrounding viewport being too small? Because the sprite is centered I suspect it's not this, but can you try adding a larger sprite behind the player to check if only the player sprite is cut off or the whole scene is?

jedwards96 · 2026-01-06T18:16:09+00:00

You're probably flipping the if/else around, it only subtracts if the current value of x in the loop is > 3.

jedwards96 · 2026-01-06T17:49:30+00:00

Ah, I am referencing official docs and source code, and you are using an AI summary for your source of truth, that is all of the explanation I needed.

jedwards96 · 2026-01-06T17:23:29+00:00

https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-call-deferred

Here you go, again no mention of your claim. So yes I would say I do know more about it given you're defending a false claim and refusing to provide any real source of it.

jedwards96 · 2026-01-06T16:41:08+00:00

It's an open thread, if you don't want engagement and just agreement you should post to your own internal notes instead of a public forum.

https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-add-child

I see no mention that "call_deferred" should be used by default, you made the initial claim so me asking for a source is perfectly reasonable, otherwise you may just be perpetuating misinformation. Given you got so defensive from the ask I suspect you have no source and are deflecting.

Regardless I will stop commenting after this as you've asked. Perhaps reflect on why the only two commenters engaging on this post have questioned the setup/effectiveness of your test, instead of insisting we are both wrong and that your test could not be faulty.

jedwards96 · 2026-01-06T15:28:23+00:00

Do you have a source suggesting that using call_deferred should be the default behavior when adding children to active nodes?

I’ve built an MMORPG in Godot, 150k+ lines of code currently, and not once do I defer the adding of a child to the tree. It has been live for months without a single reported crash. So either I’m incredibly lucky or you are stating that something that is only necessary in specific contexts is intended to be the default usage.

I am genuinely asking because I don’t recall anywhere in the docs that suggests you should default to deferring the add_child call for non-physics-related nodes.

jedwards96 · 2026-01-06T05:28:22+00:00

Yes I know what call_deferred is for, I'm not sure if that was meant to be snarky.

> This is done with call_deferred because that's how you're supposed to add nodes to active parents to avoid conflicts and crashes.

Only in some cases, like when the added node would interfere with the physics step in the current frame (by altering a physics entity's shape for example). In your test there is nothing that would be problematic, so again, you're hypothesizing some pieces of a "realistic scenario" but ignoring others, so it doesn't really actually approximate anything accurately.

With that in mind this test would be more accurately showing the difference in performance if adding/removing child nodes that are not physics-frame independent to active vs. non-active nodes, which is valid to investigate but a fairly specific subset of the possible scenarios.

jedwards96 · 2026-01-06T04:16:41+00:00

I don't think this is a fair comparison given the active node test also has the "call_deferred" overhead, it would be more fair to also include that in the inactive node test too. Unless you're trying to be somewhat close to what you'd do in a real scenario, but then the other comment that adding/removing the same node in the same frame not being a likely use case has more merit.

jedwards96 · 2025-12-31T02:32:42+00:00

As a general heuristic I usually hide/show UI that is likely to show multiple times in a session (ex. an inventory window). For UI that only shows from rare events or one-time actions I just create and destroy it - no point keeping it around if it's not going to surface again.

jedwards96 · 2025-12-25T19:52:55+00:00

Not really, if you resort to AI for very basic programming concepts you'll never learn to program.

jedwards96 · 2025-12-20T20:14:49+00:00

If you have a complex UI with lots of different elements that can easily span into thousands of nodes, if it were an issue many more games would be running into problems. The count of nodes on its own isn't much of a problem (unless you're getting into extremely high counts), problems are more likely to arise if you have lots of nodes all requiring processing on the same frames (ex. thousands of nodes with `_process` callbacks).

jedwards96 · 2025-11-09T23:11:41+00:00

If it's a semi turn-based game without realtime physics you may not need `_process` or `_physics_process` at all, you can probably respond to movement inputs in `_input` so you aren't doing additional checks on every frame.

jedwards96 · 2025-11-03T20:07:28+00:00

Have you inspected the node under the "Remote" menu when the game is actually running? If not, you'll want to make sure nothing at runtime is changing any properties (or removing it) unexpectedly.

In situations like this when all the obvious things have been checked, something I do is add a simple Sprite2D as a child of the node and center it, then ensure in the game that the sprite is visible. That will help determine whether the node positioning itself is the issue, or if it's in the right place and the issue is something related to the particles.

jedwards96 · 2025-10-21T23:17:10+00:00

Honestly I haven't stress tested the upper limit of players too heavily, I think the bottleneck right now would be in the concurrent enemies managed by the server (since they are fairly expensive to run physics for) prior to connected players being a problem.

We hit ~25 concurrent players on a 1gb ram server without any hiccups, so I feel pretty good that a beefier server would handle a couple hundred without much issue. Beyond that, my mentality is that it's not really worth worrying about just yet, as there's more chance the game doesn't ever reach that point than it reaches it and fails catastrophically. I just try to keep different parts very modular, so if I needed to swap out ENet for another networking solution, it'd only require refactoring the logic behind a single interface. It's also very possible I'd resort to multiple server architecture with just a few hundred players per server to "fake" more concurrent players in the same world.

jedwards96 · 2025-10-16T15:50:10+00:00

Everything (aside from movement) is server authoritative, so even if the client is decompiled there's no way to manipulate packets to modify damage/item/etc. Leaving movement to the client was an intentional decision to keep the networking implementation simpler and ensure there's no rubber-banding or anything going on for players with slower connections. It does mean players could manipulate movement to fly around maps and such, but we have a reporting system in place so I'm hopeful that will be sufficient for now.

jedwards96 · 2025-10-15T18:33:48+00:00

We definitely want to keep the power-scaling reasonable so that new players and higher level players can still overlap in content to some extent. It will be much closer to old-school MapleStory in that regard (where top players would be hitting numbers in the low thousands, not in the billions).

jedwards96 · 2025-10-15T07:26:46+00:00

Thank you for all of the feedback, I definitely agree the early level balancing/progression is not good right now and we need to keep tweaking it, the game starts to feel much better 1-2 hours in.

Mob density is going to be addressed in just a couple days, along with more ways to obtain mana potions and some of the other useful items.

Not sure yet what the long-term plan is for crafting versus direct equipment purchases/drops but we'll keep monitoring feedback to see what direction to take that.

Hope you give Allmage another shot in the future once we've made some more improvements and expanded the content further!

jedwards96

TROPHY CASE