Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+5)

Wow. The game looks and sounds amazing and the fact that it's RTS is impressive by itself. Clearly of work and talent from everyone on the team.

I managed to win without the tutorial, so game is very intuitive - with about 0.5 fps :) But of course I cannot expect it to be super optimized, with all QOL features - it is beyond anything I imagined possible in such short amount of time as is.


I'm curious about the optimizations you implemented. if you could share some tips :)

I wonder what ended up using most of the resources? Units update?

Did you use any pathfinding, or do units just go in a straight line?

Is everything running on a single thread?

Any other optimizations, tips or lessons learned for this kind of game?

Hey, thank you for playing and for the feedback! 

As already stated, the hard limit on the units did not make it into the game, this is probably the issue for the fps drops.

I didn't work on the performance heavy stuff, but I guess its mostly the navigation (and possibly other unit ai) that takes up most of the time. Afaik one of the optimizations we did is to only update navigation every x frames instead of every frame. Some more options would be the grouping of AI logic (or herding,boids,..), and using more simplified navigation variants (coarse mesh/pathfinding grids), but we could only do so much within the jam time.

(+1)

Hey, Thanks for the reply.

Totally understandable - making game is hard enough in a jam, with optimization on top of that...

You probably know about this, but maybe someone finds this useful: 

Godot has very good profiling tools that take no time to set up. It will tell you exactly which part of code is taking the most time to compute. 

It worked very well, for me at least, when I was making a 2d RTS prototype. But still, at some point, with about 400-500 units moving I was encountering a hard dropoff in FPS - still not sure why.

Also, for other project I had great success with using threading - no pain at all if you can somehow chunk what you need to process and avoid accessing stuff from other chunks. I ended up creating a 2 copies of data, so that I could read from one and update the other (based on first) every frame, swapping which data I read/write. Now that you can actually use debugging in threaded code it's even better :)

Thanks for playing and glad you enjoyed the game!

Also thanks for your extensive feedback and interest behind the game. It was surely a challenge and glad you gave us some other points to think of!

And you are right, optimizing is a hard task. Especially for optimizing 3D Godot Games the Resources there are rare resources available. For optimizing the 3D assets as example I had to look what other asset pipelines for other engines do and tried to mimic it for Godot.

I was actually surprised seeing so many 3D Models being able to move around at the same time. I had expected that we suffer much faster and harder performance issues. The unit gap Definity would have saved some issues. On the other hand you got a new 3D Benchmark tool with this. But after all this also shows that you can do such things with Godot although not perfect and more Performance Optimizations have to be done.