Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(1 edit) (+1)

From my own experience (made a game in the same genre), players cared a lot more about a smooth/lag-free gameplay experience than about visual effects or tactile-feedback, especially if they're in the end-game where numbers get huge.  There are some things you can do to optimize without a hard-cap; sprite-batching is a big one.

In the end though, a cap is the most practical.  One simple technique you could try is to pool the 1,000 visible-entities separately, so your actions can bind to one of them randomly and always produce a visual effect.  A subtle tradeoff that still provides that visual juice!  :)

You're absolutely right, I have checked our draw calls, it stays around 300 when there are thousands of characters so I think sprite batching is working correctly with Godot's internal design (and I double checked we don't have anything break the batching https://docs.godotengine.org/en/3.5/tutorials/performance/batching.html).

However I do notice fps drops a lot when I instantiate new characters or destroy them, I tried object pooling already but didn't seem to improve that a lot, idk if I'm doing it correctly though.

As you might noticed I'm pretty new to some of these optimization stuff, though thx for your ideas and feedback!