• Register
Post news Report RSS Why you might wanna think twice before making an old school-like isometric strategy game in Unity

First of all a little premise. We are making Empires in Ruins with pre-rendered 3d models that are turned into sprites and sprites sheets before getting into Unity. Long story short, this involves a pretty long and slow production pipeline, but allows us to use very high res textures to provide very sharp visuals. This style winks at the 90s strategy games of AoE (and ofc a lot of other ones), mixes it with Baldur's gate production workflow and then adds some sharp modern style...

Posted by on

First of all a little premise. We are making Empires in Ruins with pre-rendered 3d models that are turned into sprites and sprites sheets before getting into Unity. Long story short, this involves a pretty long and slow production pipeline, but allows us to use very high res textures to provide very sharp visuals. This style winks at the 90s strategy games of AoE (and ofc a lot of other ones), mixes it with Baldur's gate production workflow and then adds some sharp modern style and the option for the player to zoom in a LOT. Basically we love to show off.

c691368c70fc44a7a3e175cdf44193d1


I have to say, we ABSOLUTELY love the results this far, and people all across the web seem to like it as well, but there is a higher chance of us deciding to gold plate our crotches than making another game with this style after this one. The reasons are simple: the results can be amazing, but it's harder to find a slower workflow. So, for our very first game, it's taking forever and we are loving it, ok lesson learned. For the future instead we forecast the need of producing maybe more than one game every five years.

giphy (4) giphy (3) giphy (2) giphy (5)


For those still not believing me, here we go with a set of reasons that are behind my words. I would suggest reading them if you're thinking about making an old school isometric-like strategy game with Unity3D.


I am sure you made all of your homeworks, and you finally know all the suggested (and usually very helpful) optimization technique for Unity production. Time to apply them to your new game, and see them failing one after another.

Screenshot_11


  • Forget about batching if you want to have a working "depth" in the scene. Even two objects with the same sprite and same material, if they are at different depths (either in terms of z axis or in terms of sorting layer) and some other objects are in the position between them (and it will happen often), they will require each a drawcall. The sky is the only limit. PS forget about mobiles deployement because of that.
  • If you chose 2D over 3D because the number of tris scared, don't think, if you wanna use alpha-channel endowed sprites, that you will stay too low. Sprites with alpha, and therefore with irregular contour, can use a LOT of tris and vertices too.
  • ALWAYS and ONLY use POT spritesheets. Specially if you want a high resolution and a high level of zoom in the game, this might be the only thing saving your game from being GB and GB of occupied space on disc (in Unity don't forget to crunch your textures before the final build to help this) and video memory pretty soon. Not that with POT you will fit a build easily a floppy disk if your units have many frames of animation and multiple directions, but you might have a chance to occupy less space than MKX.
  • Prepare for some math-endowed pain. You want to simulate 3d-like perspective trajectories of all kind while on a flat plane with an orthographic camera looking at it. Doable, but not as smooth as one could imagine at first.
  • One huge pain will arise if you animations are slightly more complex than basic ones as well. Unless you break them down into a lot of sub-animations (with the consequence of humungous animators to control them), what happens, let's say if you soldier attacks? Ok, it charges the hit, and at frame X of the animation it will have to cause the damage, play the hit sound, etc. Ok, so how to tell the game when does that happen? The only reasonable way it to attach an event to the animation, and till here it's ok. But one big problem might not be obvious at first. You will definitely want your game logic to run on FixedUpdates (because that's how it should run to be reliable and deterministic), but the animations run on the simple Update. Can't you forecast any issue already?
  • ALWAYS activate mipmaps for your textures. Don't even ask why, automate the idea. Activate mipmaps unless you only allow a single predefined level of zoom in your game. Keep in mind that with mipmaps active, textures grow (TL:DR imagine having a 1024x1024 texture, when you generate mipmaps, Unity will spawn a 512x512, a 256x256, etc etc versions of it). I am not trying to explain you mipmaps but know they are needed.
  • Pool pool pool objects. You're trying to take away strain from the CPU, lots of Instantiate and Destroy calls are bound to be your best friends....NOT!
  • You like Unity physics, don't you? A pity that the gravity is not aligned nor can be aligned with your game world fake vertical axes right? So it's life, unfair!

giphy (6) giphy (7) giphy-downsized-large giphy (8)


And in the very end, to summarize a bit :

  • High drawcalls will be almost unavoidable. Drawcalls can create bottlenecks on CPU and therefore on the fps of the game. Solution is (good luck) to keep everything else belonging to the game logic as smart and lightweight as possible. Use coroutines, consider about having some operations not per frame but for example per x frames. Try and optimize for batching when you can, but be aware that for a lot of things you can't.
  • When you're considering the drawcalls, don't forget about the UI. Complex UIs, even if not only for isometric strategy games, can take your fillrate, pack it and send it to brown town in seconds. As much as I love Unity, let's say that not really everything is optimized as it should be. Wrong UI approach, a couple of dynamic text fields, one scroll view, and that little dot you see up there in the sky is your drawcalls counter. That goes to sum up to everything we mentioned above, so keep it in mind.
  • Big textures and big spritesheets mean a lot of videomemory usage. Keep that in mind and never stop aiming for a target maximum usage. True that computers nowadays are endlessly stronger than how they were few years ago only, but unless you are making a game for gamer highend PCs only (and you are probably not), any video memory consumption that risks going above 1 GB is nuts.
  • Make sure you have very good animators/3d guys in the team, sprites animation is unforgiving and uncontrollable once it gets into Unity.
  • Take a very good look at the Asset store for 2d-related ones. There is plenty of assets that for a few bucks can save you hours and hours of painful work and swearing, I guess you can imagine why it might make sense to buy them.
  • If you have a life beside developing your game, pick another style.
  • Unity profiler is your very best friend. Spend hours with it, it might make all the difference you need.

Now ok, I might be coming out of a very nasty week in which i had to charge face first against most of the above topics in the attempt to optimize the game. This might have not helped me in being nice or in sounding optimistic, even though i gotta admit that a lot of stuff got heavily improved now in these last few days.

Screenshot_8


If I said something wrong, please, really please, prove me wrong and give me a link to something that shows what I can do better. I really hope to be wrong and to find new ways to optimize further our game!
Cheers, Emiliano, H&R

Post comment Comments
DonleyTimeFoundation
DonleyTimeFoundation

Wow - super informative info! Great read and thank you!

Reply Good karma Bad karma+2 votes
DrHogan Author
DrHogan

You're welcome man, glad that our experience can be of some use for others! I think soon I will have ready another similar article but a bit more specialized on UI issues (becuase believe me, we're meeting endless of them ;) )! cheers!

Reply Good karma+1 vote
Zarkonnen
Zarkonnen

Thank you, that is actually super-useful to me. I struggle a lot with getting drawing performance on Airships: Conquer the Skies to acceptable levels, and I'm perversely glad that things wouldn't just be super-easy on Unity.

Plus I'm planning a Unity-based game where I was wavering between prerendered isometric and full 3D, and this has definitely helped me decide to just go for full 3D.

Reply Good karma Bad karma+2 votes
DrHogan Author
DrHogan

Glad to hear my rant is being useful! As I said in the end, there might be a lot I am doing wrong, and therefore maybe some problems are easier to get around by knowing the right best practices, but these days I am reading REALLY a lot about it, optimizing and changing things, and it seems that indeed, it's not a smooth easy way in any case! PS your game looks very very nice!

Reply Good karma+1 vote
Guest
Guest

Couldn't you use the animation event (in Update) to flag a bool, which is then consumed in the next FixedUpdate? I imagine that'd sort your game logic determinism issue, and still leave all the audio + visual effects in frame time.

Reply Good karma Bad karma0 votes
DrHogan Author
DrHogan

Mhm I gave it some thinking. At first I thought it might work, but then I think the following would happen : the specific even calling frame would be synced with the fixedupdate, but all the x frames passed from the start of the animation would probably still be bound to the update loop only no? I think that would be only solved if I made sure that each single frame is called in the FixedUpdate, but that sounds a very heavy overhead.

Reply Good karma+1 vote
Galandil
Galandil

I don't know if you're aware of the existance of the updateMode enum for Animator components:

yourAnimator.updateMode = AnimatorUpdateMode.AnimatePhysics;

With this, every single frame of the Animator will be executed every single FixedUpdate() instead of Update().

Reply Good karma Bad karma+2 votes
DrHogan Author
DrHogan

You might just have made my day, like big big time! I love unity, but man, sometimes the information on how to do something is so well hidden! Gonna try right away, tips like these were what had me writing the article in the first place! Thanks a lot!!

Reply Good karma+2 votes
Galandil
Galandil

Glad to be of help, Unity documentation is indeed badly written and scattered! :)

Reply Good karma Bad karma+2 votes
DrHogan Author
DrHogan

Scattered is the big problem. Basic info about one topic on one page, then after endless searching you find the rest of it in another page, obviously not linked from the first one ;) Grazie ancora, appena ho tempo provo ad applicarlo!

Reply Good karma+2 votes
qixotl
qixotl

Looks beautiful, but sounds like you caused yourselves a lot of pain. Obviously I don't know the details of your game but I would have put the orthogonal camera at a 45 degree angle so your environment could be a genuinely flat floor with upright trees/buildings/units (and scaling to compensate for sprites angled at 45 degrees). Then gravity/physics would work as expected, sorting/batching would work as expected, 3D trajectories and LOS would work as expected...
That said, I'm working on my first Unity game after decades on a proprietary engine, and it certainly can be hard to find just the right bit of critical info. Thanks for sharing your experience!

Reply Good karma Bad karma+1 vote
DrHogan Author
DrHogan

Hi mate, first of all thank for the nice words! About the technical side instead, it's not as straightforward as you describe it unfortunately. The first issue is that Unity has a fix axis for 2d setups, so your camera needs to face that one. I mean, you could change it, but then every imported sprite would face the wrong direction, you couldn't use any longer the 2d mode in editor, etc.
Beside, yes, trajectories and gravity would work, but the issue with batching and sorting would remain basically the same (Unity's own nature) I never tried a setup like that in 3d, but i guess with ortho cameras there would be no need to scale to compensate for the position. I think it could be an option (someone already suggested something similar some time ago), would probably save some pain in simulating the 3d environment but left untouched the 2d issues.
But the way, I just did right now, before hitting save, a quick test. It looks like deforming sprites in house in Unity is not producing the best compression. To be used in the way you described, the terrain should be made squared and then angled so to be seen in this "fake perspective" we have. It seems that stretching and compressing in unity ends up in pretty ugly results. (right now the terrains come out of rendering phase already with this sort of faked ortographic "perspective")
But as I said, most probably giving it the lenght of thinking i gave to the current one, your approach would also work. It would have its own slightly different pros and cons too most probably.

Reply Good karma+1 vote
Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: