• Introduction
• Development progress
  • 11.8. - 22.8.
• Upcoming planned next steps
• Closing statement

Introduction

This week: we give up on single sprites and make a huge sprite sheet.

Development progress

11.8. - 22.8.

After last week’s episode on sprites and caches - we pretty much sat down and reconsidered what we were doing. It’s nice to have singular sprites - but the overhead is simply unfeasable. So, my task as, to create a big sprite sheet.
Luckily there were a couple of commercial tools out there to help us… yes, sure, we gotta pay because we got that much money to spare. No, not at this point.
This also doesn’t solve the issue we currently have:

• I imported the sprited into Unity, and wrote a editor script to split those sprites into separate sprites.
• If I import the sprite sheet and split it into the original objects, I cannot make “sprites of sprites”, so we had to export the splitted sprites
• There was not standard tool exporting the splitted sprites into PNGs.
• I need to name the split textures/sprites exactly like the splitted unity texture/sprite objects, as I refered to them in the units JSON already, requiring me to refactor all units.

So… we had to create a little tool to do this - works on all objects and creates the PNGs in the same folder. No guarantee if this works in 2-3 versions from now, but in our current version it works out of the box. Incase anyone ever would need something extremly specificially like that, you can check out this gist.

With those files in hand, it was a matter of finding a proper texture packer. Luckily there is a very cool tool out there called “Free Texture Packer” - you can either download it, or use the web version of this tool. Either way, this tool managed to create a file encapsulating all sprites and a matching metadata file to enable us importing the sprites into Unity.
This required us to add another plugin/script to the project, to read those “.tpsheet” files - the “TexturePacker Improter Script”. Luckily this is free on the asset store and/or on codeandweb.com/texturepacker/unity - so we were able grab it, throw it in, and, voíla - state as before, but one big sprite.

Now you probabbly ask, Chris, why the hell do we even do this?

Simple: First of all: I had a bug in my texture importing script, which resulted in me regenerating and recreating all the sprites for every object in the game. That may count as memory-leak, but, since there wasn’t a build out, I don’t count it as one. :D
Secondly: look at this:

10 MB, starting within seconds, and barely any memory footprint. Easily the best performance increasing thing I ever did. We need to take that into account for mods tho, as that may be a bottleneck later on if people start to add own units and buildings to the game.

Oh yes, and we implemented A*. AStarProject, to be precise. Still some improvement for the movement script in general required, but the moving is working.

For the queue system we now have proper tool tips on the researches, and the queue itself it built in theory, now we’re up to pushing and tweaking some values to get it feeling more natural.

Big steps forward!

Upcoming planned next steps

Something something, eating my own words about coming back “regulary”. I’m not really regular at this point, I prefer to use the time on hand to plow through the mechanics, so irregular updates it is, at least until we are feature complete. You are always free to poke me in #devlog on our Discord tho!

Closing statement

There are now chances that I will attempt to stream development progress over at twitch.tv - make sure to get notified on our discord by clicking here.
Also, if you want to see more in-depth dev screenshots or have any questions feel free to ping me in #devlog on Discord!

Stay safe, stay strong, keep your distance and I’ll keep you guys updated soon!

- KuhnChris