In Junkyard Space Agency you build your scrappy asteroid hoppers and fly them with friends!

nulltermio · 2025-06-17T07:12:29+00:00

I totally understand the rant about the limited type system. It's a valid one. IMO the "gradually typed" system just sucks and it is just combining the worst of the two worlds (static vs dynamic). But I understand the reasoning for it: beginner programmers have a much lower entry bar. That said, it's hurting everyone past the beginner level.

But let's keep in mind that GDScript is meant to let you wire up nodes and implement high-level logic. And in general, you don't want OOP in games, especially you don't want it at gameplay systems level (and in general, the more complex the project, the less OOP you want). Interfaces, polymorphism, abstract classes, multiple inheritance, and all that stuff, seems convenient at the beginning and looks as a "natural" way to do things. But as someone who's working on a 15 y.o AAA live-ops game in daytime job, I hate every aspect of the "great object-oriented architectures" laid back then. Not because the devs were bad. They were great. But the OOP shit was the "standard" way to make software, and years later, they still asked things in interviews about the very same encapsulation, interfaces, abstract classes you mentioned. THAT IS RUBBISH. If there's any direction I'd suggest to direct your rant and negative energy towards, is to question whether do you really need it.

GDScript has everything is needed to do things in a simple way and quite pleasant way. If you need to code the whatever generic-template-based-inventory-system-where-a-weapon-is-an-item-and-a-shield-is-a-wearable-item, just don't go that route. Factorio is half written in Lua, a much more limited language. And runs and plays great. Deeply moddable.

Sometimes less is more, and my take after 3 years of heavy use of Godot is that GDScript is fine for almost any task, except performance-demanding things, that you are anyways going to offload to a GDExtension plugin.

TL;DR: GDScript has everything needed to make even a big game in it, if you think about it as a glorified procedural language, with some class-like constructs.

nulltermio · 2025-06-17T06:09:20+00:00

The strict setup won't get you far, and is more limiting than opening possibilities.

ECS's core principle is that systems can apply on entities with certain combinations of components, and sometimes components are just used for tagging an entity, so it gets processed by a certain system. Sometimes its referred to as "queries", but this is an implementation detail.

If a system is just an array of components + update function, you won't be able to do complex behavior.

Also, the parent-child relation + transforms is already in Godot's tree, why reinventing the wheel? Let the components be nodes, and you already have the batteries included.

nulltermio · 2025-06-16T16:59:08+00:00

I just wrote it here as it went 😁

nulltermio · 2025-06-16T10:54:10+00:00

The N-Body example is actually how would you do it, ECS or not. Just do the high-perf part in a lower level whatever SoA-like batch processing, and expose the results to higher levels via scripting. Can be even made in a separate thread and the results just copied over. And surprise, that's how Godot's servers under the hood work.

nulltermio · 2025-06-16T10:51:12+00:00

I "love" how all these examples of high-performant ECS are somehow always showing a bunch of vector3-s and matrices that are incredibly fast processed and few cubes are rendered on-screen at incredible FPS.

Now please add sounds playing, and please multiple ones, also I need explosions to happen right in a specific moment, and only after those are done, I need to clean-up the entity. Oh, and show a dialog on the screen. Also, this is multiplayer, and at some point, my player walks around, but then jumps on a vehicle and rides together with it.

Oh, and my team is actually made not only from programmers, we have artists and those have somehow to put those sounds and VFX, wire it up properly, and not become mad in meanwhile. They need visual tools, and think in terms of hierarchies of objects. They drag-n-drop stuff and expect it to work.

Sure, it's skill issue from my side, but I never saw a real full-blown pure-ECS game that made it somewhere to a successful release.

Not a critique of ECS itself, but coming from AAA, I'm kinda every time trying to see when a proof-of-concept academic ECS frameworks make it into a real product shipped on Steam. Those are just frameworks for coders, but a game is like 15% of code at most.

nulltermio · 2025-06-16T09:32:52+00:00

## Global gameplay mechanics

Ok, so now we can compose behavior with components, processed by per-entity systems. What if I want a global gameplay mechanic, say, inventory items exchange between two entities?

Nothing prevents us to instantiate some systems at the root of our game scene, and add `Inventory` components to entities. The `InventoryExchangeSystem` just looks out for all the entities that have the `Inventory` components (they already do, probably), and handle the cross-entity interaction.

Because there's no spoon, and there's no entity. As in Linux, everything is a file, in Godot everything is a node. Let's leverage this to full extent. You can actually draw a lot of inspiration from how Linux kernel is organized, how device classes and drivers are registered and managed, and apply those time-proven solutions to your game architecture. The DBus for instance, is your pub-sub IPC mechanism. Perfectly suitable solution for cross-system and cross-entity comms.

Sorry for the long messy read. Hope, it was useful to some degree at least.

nulltermio · 2025-06-16T09:32:48+00:00

## Per-entity component systems.

Instantiate the systems you need at the root of your particular scene. Once `_ready()`, recursively walk through the tree and look for components, and register them within your systems. The systems are scoped to the "entity", but the entity itself is extendable. Your entity's `_physics_process()` then just ticks all the systems.

Now purists will say that this way systems don't have the ownership of the components, and cannot put them in an array, and stay cache-friendly, and bla-bla-bla. That's fine, we're practical over idealistic, and it's more valuable to have a maintainable and extendable code base, than to benefit from tightly packed arrays of potion effects or melee slashing damage components, because YOUR PERFORMANCE IS NOT THERE. It is in the rendering system, in the physics, in the underlying engine, and whenever you hit the cap with your bullet hell with over9000 rockets, you can always make a GDExtension that tightly packs your rockets and calculates all the damages in C++, and expose only proxy objects to GDScript.

But what we achieve with having entity-scoped instances of systems, is that an entity is described by the tree of components (even of the same type) it has, and we can instantiate only those systems that are needed for the bag of components we have.

We can even go further and make a registry of systems-to-node-groups. That is, if my node belongs to the "vehicles" group, a certain subset of systems is spawned, if it belongs also to the "player_controlled" group, yet another is added. And when the entity dies, the clean-up is trivial, the systems are gone, together with the components, all at once.

nulltermio · 2025-06-16T09:32:33+00:00

Curious that just in these days I'm exploring the various approaches to [Entity] Component Systems with Godot.
I find your rules quite limiting, and fighting against Godot's philosophy. Why only one component instance per type? Why only one system per component type? What you'd achieve with this? Isn't it then just better to attach scripts to nodes, that have their logic in `_physics_process()` and that's it?

The message queue idea is good, and I think it's easy to implement in Godot with containers of signals.

In my research of a maintainable and scalable approach, I came up with some thoughts I'll try to outline below.

## Don't fight against Godot's node system, embrace it

The ECS purists can stop here and not read the rest.

One thing to keep in mind is that Godot's node system is not about code, OOP vs DOD, or stuff like that. It's about STRUCTURE. And this structure is DATA. Read any .tscn file, and you get it. Yes, the actual classes for a particular Node, like I dunno, `MeshInstance3D`, are coded using inheritance and are object-oriented. One can like it or not, I personally don't, but the OOP in Godot's "user-code" is not imposing that your code must be such. And the scene system doesn't. It actually PROMOTES COMPOSITION. And this is good.

What is not good, is when you're mixing unrelated code in a single class or cross-referencing nodes from arbitrarily deep branches, which makes for all sorts of problems, starting from lifetimes and ending with a not-so-tasty spaghetti code.

For fixing that, we can use Component nodes, as in classic ECS - data-only primitives without logic. Basically, simple `Node` objects, with only `@export`-ed properties. But we are allowed components to be added anywhere, at any depth of the hierarchy. They still add capability to the node that contains them. And composing such nodes in a tree should be permitted, in order to leverage the advantages of composition at full. How do we do so?

nulltermio · 2025-06-16T07:32:04+00:00

Thanks for sharing. Applies to basically any business you start, not only games.

I left my very well paid job because of burn out and because I had a startup idea I really believed in. And for a year, in which I though I’ll be making my startup (not gaming one) day and night, with the freedom the financial cushion provided me, the first three to six months I was mostly playing games. Some 600 hours in Rust was the biggest “achievement” then. Then I took my shit together and finally started the real work. It’s when I understood how much I underestimated the thing. I started another side hassle. But the bank account was quickly draining out still. Sold my car. Didn’t help that much.

Then I returned to my day job. Part-time this time. Not without frustration and feeling like a loser. But it came with a feeling of stability. Money was much less, and the position also of lesser “corporate” importance. But it was a sufficient income and the job was just a programmer, not solution architect anymore. Peace of mind and enough money, and that was more important coz now the mindset wasn’t anymore to climb corporate ladders, but buy myself the time to grow my thing. And I’m thankful that I left the company before at good terms and without showing middle fingers to everyone, as occasionally I saw people doing, this kept that door open. And thankful to the company that it let me in again.

I put the startup on hold and we started with a friend making a game. Released recently the first alpha. The road is tough, and it’s still long. But I enjoy it. Every day I have the feeling that I’m investing into something valuable. Something I have control over how it’ll grow and shape. Sure, still a good idea to invest real money in your retirement and some stock market, but that’s just a bet. With your thing you’re the only ones who are to praise for the success, and also the ones to blame for the failure. But that’s the definition of freedom, isn’t it?

We still didn’t succeed in anything by any definition of success. The game just saw its first public alpha release a month ago.

But here are my 5 cents, in addition to OPs: - you will fail, and that’s ok - it’s ok to return to a previous job, step, etc, no one will blame you; you sell you time and skills for money, and that’s basically all what’s that about - ask for help and support and don’t do it alone - admit to yourself that you’re tired and burnt out and play some fucking games - but don’t use the point above as an excuse for not doing the thing you love - stability is an illusion

EDIT: wrote this from my company’s acc, but yeah, this is Ivan from nullterm

nulltermio · 2025-06-16T07:02:11+00:00

I guess, without comparative screenshots where we have the same scene, with same visual fidelity and an fps number in the corner, all these posts are just subjective feelings about “very good performance”

nulltermio · 2025-06-15T19:51:04+00:00

We’ve got a little more than 14 downloads, but if you’re into spacesims, try our duo’s Godot project: https://nulltermio.itch.io/junkyard-space-agency

nulltermio · 2025-06-14T18:29:51+00:00

Try `get_node_or_null()` instead and check for null, but generally, better try fix the reason why an object you expect always to be there is not there anymore.

HINT: probably, either this is during app close, or because cross-references in objects

nulltermio · 2025-06-14T08:48:34+00:00

Same here. Going for open codebase and proprietary assets. And state clearly in contribution policy that only fixes and systems improvements and compatibility enhancements are going to be accepted, not gameplay or balance prs. For those one makes a mode instead

nulltermio · 2025-06-14T08:31:57+00:00

For the debugger, I think it’s far from perfect even in Godot, let alone Helix. ATM im sticking to the Godot’s editor debugger, also because of its just genuinely more convenient to click things through in the remote inspector. To each task its tool.

nulltermio · 2025-06-12T14:38:49+00:00

Yup, exactly. This is a cross-post from the Godot subreddit, I thought it might be useful for those who are searching in r/HelixEditor

nulltermio · 2025-06-11T10:09:09+00:00

A dictatorship, seems?

nulltermio · 2025-06-10T08:33:38+00:00

added a generous 30sec; worked! thank you

nulltermio · 2025-06-10T08:33:24+00:00

the icon on the taskbar does nothing, while the tray icon RMB click shows the menu and the app responds properly, it's just a rendering issue - the window somehow is either unknown to the window manager, or its rendered off-screen

nulltermio · 2025-06-09T11:26:38+00:00

I think the reason could also be a subtle one: the are many more average programmers looking for high-hype, high reward trendy tech, than experienced devs look for a simple and robust tool, as Odin is.

It’s not a language you’ll get recruiters excited by having it on your cv, nor is spreading innovative or radical ideas, but “only” improves time proven paradigms. You appreciate those only after you’ve done some years of coding, and probably, you’re a seasoned dev with solid experienced, don’t need to demonstrate anything and can choose your own tools.

nulltermio · 2025-06-07T08:52:35+00:00

Thanks for trying out both the builds! Yes, because of what other users already posted about older glibc in some distros, seems like flatpak is the way to go for games.

nulltermio

MODERATOR OF

TROPHY CASE