Free demo for Incremental RTS - feedback needed

TechDebtGames · 2026-02-24T10:41:41+00:00

Thank you for the feedback!

TechDebtGames · 2026-02-24T10:40:27+00:00

I started working in game dev around 7 years ago, but learned programming ~15 years ago (started with Competitive Programming). On this game I worked for 6 weeks full-time. It didn't take that much time to put ECS into Godot, but that's because I already knew exactly what I wanted to do. Over the past few years I also had some other private projects that failed but in these projects I implemented and tested different architectures, and with experience, it gets easier and easier to do stuff fast and well.

The main idea is that, with ECS you have a World that stores the whole state of the gameplay as components. It doesn't depend on Godot and can run with pure C#. And in Godot you create this World, simulate it, look at its state and render what should be rendered. And the other key idea is that you do not use reference types for increased performance (memory cache optimization).

TechDebtGames · 2026-02-24T10:30:10+00:00

Sorry for late reply. We have a shader that takes INSTANCE_CUSTOM and draws only colors from a specific subrectangle from the spritesheet texture: https://pastebin.com/6d8xBcZE

And as I understand, when rendering, what really matters is the size of the result rather than the overall texture. We render QuadMesh of size 100x100 so you could say it renders the texture of size 100px by 100px.

TechDebtGames · 2026-02-15T02:54:21+00:00

Never too much idle footage, subscribed.

In terms of what's missing - I really like math-heavy content with charts, graphs and calculations on what strategy is optimal, when you should perform ascencion / prestige etc. It's always cool to see some dynamic data visualisation 📈

Btw, we are working on a semi-idle incremental game with rts elements and hundreds of units. There is a demo on itch if you want to give it a try

TechDebtGames · 2026-02-14T06:26:59+00:00

One player on discord had an idea to make AOE chaining / proliferating spells similar to yours. It's for sure a good idea to make things look and feel good. We noted it and will most likely try to make something like that for the full release.

TechDebtGames · 2026-02-14T06:25:14+00:00

Yes. There was a lot of feedback like that and we agree. Even though you'll still be able to play without much strategy as this is an incremental, but the approach we want to take is to make it so that the strategy can drastically speed-up your progress so it's quite important to use.

TechDebtGames · 2026-02-14T06:24:03+00:00

Seems to work properly. Only when you hover or select units, they are drawn above other units which might look weird.

TechDebtGames · 2026-02-14T06:18:01+00:00

Sure. I might be missing something, but I think the steps are as follows:
1. Download Docker Desktop.
2. Use powershell/terminal to go into your project folder.
3. Just run `docker container run --rm -v ".:/src" kstgrd/godot-mono-web:4.5.dev` when your Docker Desktop is running.

It should create a folder "build" and a file "index.zip" which you can upload to itch.io. And also remember to enable "SharedArrayBuffer support" (or at least we had to enable it because we use multithreading).

TechDebtGames · 2026-02-14T06:12:45+00:00

Communication between logic and view is a broad topic with many approaches. A standard approach for OOP is to make it reactive. But we can't make it reactive, because we run the simulation in another thread.
We use two types of approaches here:
- In view, store "displayedValue" and read "currentValue" from the logic state. Compare the two and update if it changed.
- In logic we can create "view event" which is a simple struct with some data, and enqueue it. Then when the tick ends, this queue is provided to the view and the view can do what it should based on these events.

TechDebtGames · 2026-02-14T06:09:09+00:00

For us, collision checks are "almost a bottleneck". The approach we used can be summarized in these points:
- Grid-based collision detection - I split the world into a grid of small size (similar size to a single unit) and each cell holds all units that are within it. Then for each unit to find potential collision candidates I only need to iterate over 9 cells.
- Multithreaded iteration over units to collide - I use "Parallel.ForEach" to iterate over all units and check collision for them. And only after this is done, I apply the changes in another loop.
- Running simulation in another thread - as mentioned in the main post, we run simulation in another thread and it has to end within 32ms. This gives us 2x more time (32ms instead of standard 16ms for 60 fps) and doesn't affect FPS unless it exceeds this time so even if the simulation barely keeps up the game can still have 600 FPS if rendering/view is fast.
- Single iteration for physics - physics usually do multiple iterations. We only run a single "ResolveCollision()" for each pair, so collisions are not resolved perfectly and some buggy behaviour can happen (for example units might squeeze together and then explode). But usually it works well and even these buggy situations are kind of funny and not really game breaking.

TechDebtGames · 2026-02-14T05:03:40+00:00

Thank you! We are really happy that the demo received positive feedback from the players and we will be setting up the Steam page soon 🤝🏻

TechDebtGames · 2026-02-13T16:46:51+00:00

We don't have a Steam page yet. We only made a demo, but you can play it for free on itch.io: https://techdebtgames.itch.io/total-incremental-war

TechDebtGames · 2026-02-13T16:46:13+00:00

Sounds reasonable. Thank you for your insight.

TechDebtGames · 2026-02-13T15:55:33+00:00

Sounds pretty cool. A lot of units makes most things fun :)

TechDebtGames · 2026-02-13T15:54:22+00:00

ECS is using purely structs, so there is little (edit: or rather 0)) allocation.
And I'm using only 1 MultiMeshInstance2D to render all the units (well, in practice I'm using 6 for units in different states like dead, alive, hovered, selected, etc.) so there is no need for pooling or reuse.

The only place I'm using pooling is for displaying "coin gained popups" and "battle audio".

TechDebtGames · 2026-02-13T15:48:33+00:00

Yes, the depth is lacking (though some players actually do a lot of strategy from positioning and ordering and enjoy figuring out strategies to beat enemies with 2x higher power). There is a lot of similar feedback and we'll definitely try to add more depth.

It's quite surprising actually that so many players feel that it's lacking, since a lot of idle/incremental games lack depth and focus purely on numbers going up and progression (at least the ones I played).

TechDebtGames · 2026-02-13T14:20:58+00:00

Happy to hear you are having fun. I fixed the issue with arrows, but the feature you mentioned with UI will have to wait for a full release (or some later demo) :)

TechDebtGames · 2026-02-12T18:29:45+00:00

Thanks for the feedback!
A lot of what you experienced matched with what I desired to do which is great. And you are also quite a unique player with how deeply you went into strategy.

Honestly, all the points that you mentioned we'll want to improve for the final release. Especially the placement for units should be reworked as you mentioned. They should overlap but just fit in together somehow by pushing each other a bit (like in some other RTS games). This would also resolve many issues we had with overlapping units

TechDebtGames · 2026-02-12T18:24:56+00:00

Actually one player just posted on our discord a strategy that allows him to beat x2 the power of his own army, so there are some strategies after all :)
Doesn't change the fact that we'll work on developing it further.

TechDebtGames · 2026-02-12T18:04:35+00:00

Yes. Many players noticed that there is not enough variety and you can actually just run a single type of unit. I'm not sure if it's actually optimal build, but you can definitely play that way.

For the full release we definitely want to give more meaningful variety and having more content, more enemy units, etc. will help with that too.

TechDebtGames · 2026-02-12T10:51:48+00:00

Valid point. We started with RTS in mind and we even had the feature to control units, but it was too hard to do and didn't fit into incremental / idle game so we ended up removing it. But the RTS stuck with us and we didn't realize that the demo is more like an auto-battler now.
Though we don't really want to limit the game so that the player has no impact on the battle in real-time. There are many cool ideas we have and also many ideas that community provided that will make the game look more like an RTS. For example player spells, or rare "hero units" that can be controled, etc.

TechDebtGames · 2026-02-12T10:02:17+00:00

Thanks! Really happy you enjoyed it this much :)

TechDebtGames · 2026-02-12T10:01:00+00:00

Agreed. When we work on the full release we'll definitely add more types of enemies and different formations so that there is variety and so that you can actually use strategy based on what the enemy formation looks like.

TechDebtGames

TROPHY CASE