Search Unity

  1. Unity 2018.3 is now released.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. We've updated our Terms of Service. Please read our blog post from Unity CTO and Co-Founder Joachim Ante here
    Dismiss Notice
  4. Want to provide direct feedback to the Unity team? Join the Unity Advisory Panel.
    Dismiss Notice
  5. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice

powered by ECS: Spuds Unearthed - a mix of RTS/TD and god sim now in Early Access! (VR game)

Discussion in 'Entity Component System and C# Job system' started by mmankt, Jan 10, 2019.

  1. mmankt

    mmankt

    Joined:
    Apr 29, 2015
    Posts:
    20


    Hi!

    I am the lead programmer on Spuds Unearthed battle module. Our game studio is called Gamedust and we are based in Poznań, Poland.

    Wanted to share some info on game, our engine and thoughts on using ecs/jobs since we've just entered early access.

    The game is divided into two modes. The core of the gameplay is the battle module (our codename is ‘combat’) which is a mix of real time strategy, tower defense with a bit of shooter elements, all in VR.

    The second part is your home base where you build your army, upgrade your units exchange 'gold' on tokens which let you produce units/turrets etc.

    The whole game is set in a living galaxy of planets to conquer. It's basically an async multiplayer game where players conquer planets controlled either by zombie units or other player's defense systems.

    The player has many different means of battle at his hands.

    You have the titular Spuds that act as heroes in our game. Each Spud can be upgraded into a special class like a pilot, driver, heavy etc. Each class has a unique basic and special attack and a specific role on the battlefield.

    Spuds can also use vehicles. Right now we have a plane and a tank. Any spud can use them but a pilot and driver will add special abilities to your vehicles.

    You can also use turrets with unique VR interactions (anything from a regular revolver to a minigun powered by a crank ). The player can build those turrets by combining the base functionality with a firing mechanic - for example, you can attach a pump from a flamethrower to a minigun and it will turn into a shotgun etc.

    We also have a cannon fodder type of unit - small autonomous Goonbots that are strong in masses. The whole goal is to use all of the provided means of war to conquer planetary systems in our two game modes: Infestation and Conquest.

    In Infestation, you must fight on planets controlled by Zombuds - a kind of corrupted spuds. In all of the modes the goal is to destroy the enemy defense system (base) on the other side of the map. Once a planet is conquered it becomes yours and brings you money. Other players can attack your players and take them from you. This is when the second mode comes into action - Conquest.

    When you attack a planet which was conquered by an another player, you fight with an ai controlled army that the he had left there during his previous battle. Each planet has a fortress which will use artillery fire, deploy tanks, planes and goonbots. Each planet gives you more playdust (our gold/money ;) ) which lets you travel to other planets and to build new units.Once you've conquered a system or you want to try fresh, you can travel to a new one. The ultimate goal is to be the best ranked player in the whole galaxy.

    As the game is in early access we will be adding many new features such as player ranks, new vehicles, spud classes, unit upgrades, traps and new turrets.

    The combat module was developed by a self contained 3-man team and it’s code base is a whole separate module. We get all the crucial info that is needed to start a battle from the server and we just run our simulation.

    The core features of our engine are:

    The simulation is deterministic, lockstep, we use fixed-point math. (because of that all of the code in the sim is custom.)

    All the ground units are simulated in 2D. (gameplay is fully 3d).
    We have a custom 2d physics system (OOP) and a simple 3d physics system (turret projectiles and all the units you can throw into battle) (ECS). Some units have both 2d and 3d colliders.
    The terrain is represented as a height map for view and 3d collisions.
    We use influence maps for ai.
    Pathfinding is done on a prebaked flow field. We also have a dynamic, cost based pathfinding system.
    All of our data like heightmaps, walkable areas and flowfields is stored as a 1d grid.
    The simulation is separate from the view. The view can’t influence the sim.
    One monobehaviour as an entrypoint, everything in the simulation is pure c# in simple OOP systems-based architecture and pure ECS for all the units, ai, projectiles etc.
    We built custom tools to sort system execution order (posted it here), bake map data from unity to our fixed format and to bake flow fields.
    The player can influence the sim via inputs. So for example the player will take an object in VR and throw it - this will create an input command with all the needed data that will create a proper Entity with just the view ‘re-parented’ to it. All inputs are stored and serialized so they can be used to watch a replay of the battle (replays not implemented yet).
    We connect to the view via an index reference. We have all of your view objects stored with a proper id. Once the sim is done we collect all relevant flag components in view systems and send proper events with the view id in them. Everything that doesn’t need a skinned mesh or mono controllers for the view is rendered via an instanced rendering system (so positioning, rotation etc is done inside ecs).

    A lot of our solutions were inspired by Homeworld: Deserts of Kharak talk on Unite <3 and obviously tons of other rts engine materials from starcraft 2 etc.

    We wanted to be fully jobified but in our first tries we found that it was breaking our determinism. We also aren’t using burst at this moment btw. Since we were on a really tight schedule we had to focus on making everything work with the knowledge we had at that moment. We will definitely improve a lot of aspects in the future.

    We’re using Unity’s ecs right from it’s first release and our biggest problem was lack of documentation and the constant changes. We had to look through samples to see what kind of features we can use or how to use them.

    We decided on using ECS since it’s a perfect match for a rts with lots of units and we wanted a high performance engine right from the start in order to support a lot of units in 90fps stereo.

    From performance side we can have a battle of up to 1500 goonboots (single thread) and it runs at 300 fps in our tests. Obviously pretty graphics bring it down but right now we support pretty intense battles and we are very happy with the results.

    I love using ECS and even if it takes longer to develop some simple features it’s really great in the long run. We’ve learned a lot over the course of development and right now we’ll focus on speeding up the engine in crucial places to support even bigger battles. I’m working on some side projects in ECS and experimenting with fully jobified solutions. Really looking forward to the future of ECS. ( DOCS/summary in code PLZZZ! )
    Sorry if the engine description is a bit too chaotic. Just wanted to point out all the important aspects. I’m looking forward to any questions.

    Some fun job based experiments:



     
    Last edited: Jan 11, 2019
  2. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    107
    Awesome job! I'm not sure if it's applicable in your case, but were you able to check your fixed point math performance against using floats? I did a custom SoftFloat in the past to solve determinism. If I remember correctly the performance was 3 to 15 times slower than using floats (best to worse case).

    =D
     
    mmankt likes this.
  3. mmankt

    mmankt

    Joined:
    Apr 29, 2015
    Posts:
    20
    Yes I've tested it. We're using Fix64, (we'e been testing determinism on multiple platforms (pc/android/ps4) and all results are the same.) The perf hit seems to be around 30%. So it's ok. Can't wait till burst will be officially deterministic. I am making a brand new 3d rts engine at home right now which will be fully jobified and based on float and unity mathematics so can't wait to see the results. ;)
     
    Creepgin and Antypodish like this.
  4. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    3,185
    Definitely some smart stuff are going here :)
    The experiments demo are really cool.
    And of course main demo.
    Keep up.

    Just questions, if not mind:
    What 2d physics methods have you used in your second parallel 2D physics video?
    Anything spatial? Colliders, or anything else?

    Interestingly, how you bring homeworld inspiration into your game? I mean both are RTS, but other than that I can see little of similarities from demo. Can I assume, there are some mechanics, similar to homeworld?
     
    mmankt likes this.
  5. starikcetin

    starikcetin

    Joined:
    Dec 7, 2017
    Posts:
    181
    Looks good. The 2D physics demo also looks very interesting.

    I would love to read an article from you about using ECS in production.

    Cheers.
     
    mmankt likes this.
  6. mmankt

    mmankt

    Joined:
    Apr 29, 2015
    Posts:
    20
    1. the parallel demo 2df physics demo is based on force accumulation. I solve all the collisions that occur in a step for a body and just accumulated the resulting forces without changing anything on it. Once all bodies are processed the new velocities are applied so everything solves properly. It's less precise than a traditional solving loop but good enough for certain purposes. It's also the easiest way to solve in parallel.
    The galaxy demo is just simulating the gravity forces of each body on all other bodies, no collisions. Same idea as with the physics demo - I'm accumulating forces.

    2. what i meant about homeworld is about the engine solutions - watch the talk to go deeper but basically we're also using a heightmap, 2d physics etc.

    Cheers :)
     
  7. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    3,185
    Cool thx for explanations.
    Unless I am wrong, seams like your concept is similar to ECS Boid demo?
     
  8. mmankt

    mmankt

    Joined:
    Apr 29, 2015
    Posts:
    20
    We use hash maps to determine body locations etc so it's kinda similar.

    One thing I wanted to point out about working with ECS is that the performance in the editor is really terrible ( I don't remember exactly but from our tests it was around 6 times slower). I know it's due to all safety checks but even when I disable everything from the menu it still runs really bad.
     
    Last edited: Jan 11, 2019
  9. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    3,185
    Yep, many of us are aware about editor performance downgrade. Still it is much better in my experience, than same thing in OOP. Kind of good thing, since you always can expect extra boost after build. So I things work in editor well, you maybe nice and comfortable for even worse hardware :)

    Thx for sharing.
     
  10. mmankt

    mmankt

    Joined:
    Apr 29, 2015
    Posts:
    20
    It's not good when you need to test an actual demanding indie AA budget game and we play in slow motion :'D Builds of such projects usually take a while ;)
     
    Antypodish likes this.
  11. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,232
    Do you have burst enabled on those jobs that are slow or is it main thread code?
    The expectation is definitely that when using burst jobs there should be zero overhead relative to player when disabling the safety checks & job debugger. This is specifically for the time to execute the jobs. Scheduling overhead is still there a little bit in the editor.
     
  12. mmankt

    mmankt

    Joined:
    Apr 29, 2015
    Posts:
    20
    This happens even for regular, main thread, non burst, ComponentSystems. (as I said, pretty much all of our game loop is on the main thread right now. I use pure jobs (no burst enabled) for some heavy influence map analysis for AI and they're very slow in the editor. )
     
  13. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    3,185
    But as mentioned, try convert at least something into burst. It will give you massive kick performance boost. Even starting from smaller less intensive bits of code.
     
  14. mmankt

    mmankt

    Joined:
    Apr 29, 2015
    Posts:
    20
    The funny thing is that my 2d physics demo which was 100% jobified, used floats and unity.mathematics, native multi hashmaps etc and was a really clean example of how to do well optimized code in ecs didn't gain a lot by enabling burst compilation. Probably there was a bottleneck on my side but overall the whole thing ran only about 10% faster. I will be doing some deep testing soon-ish.

    I have a small bullet hell demo with raycast commands which is also very clean and I get 100fps with 30k projectiles with burst and 60fps without. So very nice but that code is really straight forward.
     
  15. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    3,185
    Nice one. But weather is simple code, or complex.is less relevant, if you multiply by number of executions. For example 30k. If you utilise multithreads, that is already release some stress from main thread. Wouldn't be worth to embrace that through project, where possible?
     
  16. mmankt

    mmankt

    Joined:
    Apr 29, 2015
    Posts:
    20
    of course, the goal is to be fully multithreaded with burst. don't worry we will be improving all perf aspects of our game. we didn't go that route because it was breaking our determinism but we figured out the errors we made and we will look into making everything better ;) I don't know if you have any experience with actual game production but I hope that you get my point :)
     
    Antypodish likes this.