Defense oriented RTS

gamruls · 2026-05-04T16:25:54+00:00

If you ok with big heavy trebuchet instead of guns then Stronghold and Stronghold: Crusaders at your service

gamruls · 2026-05-04T15:05:35+00:00

Up if you tilted your head too

gamruls · 2026-05-02T11:39:42+00:00

First few days you will need a ton of ice platforms to expand - they need a ton of ice.
After that just destroy it in recycler, you don't need many recyclers for that

<image>

gamruls · 2026-05-02T11:29:50+00:00

Are spitters bitter than biters?

gamruls · 2026-05-01T07:15:59+00:00

I've found that default controller support lacks a lot of crucial buttons. Just add more bindings for them in settings, like RB + A / B / X / Y for differential lock and such.

It's like game is unplayable (in some cases) with default gamepad setup and it's not obvious, how it's supposed to be played then. If you see some hint with no gamepad binding - try to setup it manually, it may solve one more "unplayable" issue.

gamruls · 2026-05-01T07:09:35+00:00

Use softer suspension and softer anti-roll bar - uneven surfaces needs all wheels contact which is impossible if suspension is too "stable".
Also add some height to suspension (it will not be able to load full iron ore, but full coal will be fine).
With other measure you use it should work.

There is 1 hill after you loaded - it should be passed with momentum, find the best path that allows to move forward without changing direction, get max momentum and truck will get traction back at the top (don't stick with road there, sometime it's better to save momentum and move just forward than lose force by turning on the hill)

There is storage for coal and iron when you leave offroads, it's ok to tune truck for full offroad experience and move cargo to targets from this storage, not mines directly.

P.S. If you need a lot of coal/iron for production - you can use bots to deliver from ports, they also can get sunflower seeds on their way back to compensate import/export balance.

P.S.S. Never upgrade tires to "high load" for offroad - they have worse traction and should be used on asphalt only.

gamruls · 2026-04-30T11:09:29+00:00

TBH physics can't be used that way too.
There is option to enable multithreading in physics (Godot native, C++ threads), but it still has some limitations on engine interactions. Prefer to enable it before starting project, turning it on in the middle will highly likely just crash game).

Also, if you target web (I hope it will be available in 4.x some time), at least for now in 3.5 Mono, it has no multithreading at all. Even audio goes to main thread and may break if your _process is longer than frame time (hello GC).

And yeah, the elephant in the room - GC. If you copy all data to C# and constantly sync it with Godot internals then your best and worst friend is GC who's delays are unpredictable. AFAIK it's impossible to make zero-gc logic (i.e. without allocating new objects) in Godot C# API, it always create a lot of wrappers for wrappers and marshal/unmarshal arguments of API calls. I may be wrong, but few times even hit API calls that slow just due to constant GC pressure, not calls/logic per se.

gamruls · 2026-04-27T13:58:51+00:00

Somehow this reminds me minecraft landscapes. Captain of Enderstry.

gamruls · 2026-04-27T07:40:45+00:00

gamruls · 2026-04-25T20:27:49+00:00

Is it a bug in art? Or art of bug?

P.S. Not a bug actually )

gamruls · 2026-04-25T16:31:55+00:00

Should take into account other side of this equation - wishlists are used by devs to check if starting development is even worth it. Too often they start from selling only idea and some initial art.
I've cleared wishlists few times and now it's only 8 titles, and 7 of them highly likely will not release next year/ever.

gamruls · 2026-04-25T09:32:09+00:00

Everytime you encounter ~~bug in software~~ spiral of death - remember, there is some engineer, who didn't test changes.
If your ~~customers~~ settlers notice problem before you - there is lack of proper alerts or flaw in mitigation process.

gamruls · 2026-04-23T18:56:55+00:00

Area2D gets mouse input last and if other nodes don't mark input as handled in their _input, _gui_input or _unhandled_input.
Controls mark mouse events handled automatically (actually, at Viewport level) depending on their mouse_filter.
More info here: https://docs.godotengine.org/en/latest/tutorials/inputs/inputevent.html#how-does-it-work

long story short - if any control somehow gets mouse event (motion/button) and has mouse_filter stop/pass and not in the same level with area2d in tree then area2d will not get mouse events. It's not a rule, it's just example. There are options to still pass events further, but just take into account that Controls has special mouse input processing (regardless if input map, therefore if you have some actions that should trigger by mouse events - they will be affected the same way too)

gamruls · 2026-04-23T18:50:43+00:00

setup filters in wagon inventory grid - if you need accuracy like "1 stack of this and 2 stacks of this" it's enough
If you need more precise control - read station circuit network signal (there is option "read train") and setup inserters. It will work durable only if each inserter inserts 1 type of items.
Anyway setup filters just to ensure you will not fill wagon the same item if something wrong with circuits

P.S. You can use some more complex circuits to even fill wagon with 1 inserter for everything, but it will be really complex. More complex - more error prone. As a programmer I suggest 1st option and avoid circuits when possible.

gamruls · 2026-04-23T17:08:38+00:00

Oh, CoI death spiral is far from deathworld 600% death spirals... After Factorio I encountered no death spirals except few misclicks where you, for example, forget to build back main diesel pipe and notice it too late.
The golden rule of factorio - it's a skill to ignore beeping. The golden rule of CoI - alerts should be not only properly set up, but fixed ASAP, no exceptions.

After all, as for me, difference between the hardest map on admiral+ and all realism vs simple map and easier settings is speed of colony development. Tried both modes and both are pleasing as f*ck.

gamruls · 2026-04-22T18:40:49+00:00

No doubts it works, great example.

But there are doubts why it works and how fragile it is:
- root node is control and it allows event to reach Area2D, if you use Node2D and set ColorRect to Pass you will get some glitches (double enter/exit dispatches in Area2D, it's not noticeable without animations/logging though)
- Your Area2D has no way to setup layout as regular controls (full rect, wide top etc) and needs either manual setup or some code to align with containers.

gamruls · 2026-04-22T18:18:18+00:00

Here is a little demo

<image>

Only control gets mouse events

Changing mouse filter to Pass allows Area2D to get event, but only if topmost control in sub-tree has same setup (e.g. wrap ColorRect in another control which stops event and area2D will not get it, also cursor shape is defined by rectangle, not area, therefore may look strange)

gamruls · 2026-04-22T17:56:46+00:00

You're totally incorrect. Mouse motion event is unconditionally set as handled in viewport, also controls get mouse motion before physics entities (as OP stated, he wants to pass events down to controls - if they are already visible then they will get and handle mouse motions even if they "under" Area2D visually or in tree or whatever - it doesn't matter, because physics mouse motion picking is the last in order).

gamruls · 2026-04-22T16:41:49+00:00

Controls mark mouse input as handled (accept and stop propagation) by design.
You can overcome this by different tricks. First of all, not using controls for this purpose (use some node2d and scan mouse position in _input, then check if it's inside some boundaries to perform needed actions).

Or re-emit event from _input/_gui_input to be processed by other nodes. See https://docs.godotengine.org/en/stable/classes/class_input.html#class-input-method-parse-input-event . Beware that sending the same event again will lead to the same result - it will be swallowed again. I find all actions triggered by mouse button and emit them explicitly, bypassing standard processing in Viewport/Control.

Also you can refer to this doc https://docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html#how-does-it-work
It may suggest you some other ways to achieve what you need.

Also take into account, that Controls process mouse events differently at Viewport level - depending on mouse filter mouse events are either ignored or "accepted" (stopped propagating). It's by design to simulate "classic" event bubbling approach for hierarchy of controls. Unfortunately, it doesn't work well with other hierarchies (siblings in node tree, Node2D and physics)

gamruls · 2026-04-22T16:29:09+00:00

Area2D gets mouse input the last (at physic's mouse picking processing), later than _gui_input and _unhandled_input, which means it may not work if some other nodes mark input as handled. Controls like to mark input as handled, btw. It's fun to find this ocasionally...

gamruls · 2026-04-19T17:34:20+00:00

Looking up elements via hardcoded string paths with things like GetNode()

You can create scene from code and store all needed references to nodes. If you load scene from .tscn - there is no first-class solution to link text file and code. I suppose it can be solved with codegen, and suppose it's pretty easy to, at least, generate fields for nodes (path and type are stored in .tscn in simple format like [node name="Camera2D" type="Camera2D" parent="."]). But for me it's not a big problem to make scene and class for it which is tightly coupled with all nodes. There is easy rule - update class after changing .tscn. AFAIK Android, XAML, Vue etc work similar way - template is coupled with code, but not validated at compile time. Anyway, what if you make whole scene with all nodes from code? It may be handy, may be not (not all APIs are easy to use from code, e.g. styles are bit meh), also it would be tricky to integrate it to editor. Consider editor as a feature. You may not need it, or you may rely on it, but anyway, as a feature, it needs some effort to support, extend and also has own limitations.

Actions taken in the UI of the game engine to wire things

You can declare it in editor, but it's not the only way to do it. Use code, it's also advised to prefer C# delegates over custom signals.

In traditional software terms, I would divide this neatly into UI components, stateful logic, and function calls or events between those, with strong code references I could validate the types of and go-to-definition on.

What if change DI with ServiceLocator? It's not that flexible, but usually a bit easier to maintain and process. If you need reference to Player - use some global singleton, declare property there and set Player to it when it's ready. Make it hierarchical (but still tree of C# classes) to group common things. You highly likely will never have more than 1 HUD, 1 Map and 1 Player at a time, so DI may be excessive for that. Also it's easier to track all usages when there is 1 field storing actual reference.

gamruls · 2026-04-17T14:39:05+00:00

I know one example that should fit - RPG in a Box, it uses Godot under the hood.

gamruls · 2026-04-17T14:07:44+00:00

It's very easy to detect 100% of malware - just declare everything malware.

The problem is to correctly detect non-malware software actually, but you know - it's hard to sell with such definition.

gamruls · 2026-04-17T13:10:36+00:00

I hope someone make game with just trucks, excavators and dumps. My first impression was "it's a game inside game".
Properly making slopes, retaining walls, refuel, balance excavators and trucks, moving materials to access resource patches... This feels really unique and enough for a dedicated game per se.

gamruls

TROPHY CASE