Building a turn-based game prototype using ECS - Unite Copenhagen

Get a high-level overview of the Entity Component System (ECS) and turn-based game loops, and see a proof of concept built using ECS. The session covers some of the pitfalls and also shows concepts of ECS in a slightly exotic context.
Speaker: Florian Uhde - Three Eyed Games
Slides available here: www.slideshare.net/unity3d/bu...

[@joshua.jebadurai]

I was waiting for something like this. Thank you so much.

[@nameplaceholder]

I prefer having something like an 'enum component' and just using that in a predicate compared to using different 'tag components' - but only if I know I will add/remove them often, though.

[@supercc66]

simple and clearly

[@nguyenhoanglong420]

haha i like you :)))

[@user-kt8rw7wu7o]

any chance to get this project?

[@AdowTatep]

Does anybody have a link for the keynote he is often mentioning?

[@spiral9316]

If course there can be better patterns. But what's important it's getting used to syntax and component system interplay. Using a simply and generic tag way ear the best explanation they could do for basically every type of game out there . It isn't near bthe best performance one could get with ECS but for getting the 5to20x increase it works. Specially in complex systems the way tags simplify and quick to implement is very a very good pattern. What I don't like it's that he trashed his talk just because he was probably mad about not being informed beforehand or some minor change to ECS.

[@jasonmcevoy2552]

where is the project??

[@jaylee7512]

Stardew valley!!

[@Gundalian]

The biggest issue I have with this tutorial is that they are showcasing how ComponentSystem works, considering they are not multithreaded. It would be nice to see more examples of multithreading :(

[@47Mortuus]

He talks about the job system which handles thread-safe multithreading for you...

[@chenbin0802]

I don't think ADD/REMOVE flag is a food way for the turn-based game. You will need a lot of flags when developing the full game, and add/remove these flags will become a disaster.

[@47Mortuus]

? That's almost exactly the same thing as setting a boolean to true or false... "I don't think" (quote) - leave it there :D

[@jasonmcevoy2552]

the git hub files are nothing like what you started with!

[@agsystems8220]

That pattern at the end smells horrific. ECS sort of works by assigning a type system to entities based on what components they possess, and then applying systems based on 'type'. Data can be organised based on type, which determines what it can do. It is an optimisation because typically there are many objects of the most important types, and types rarely change. If the data was well organised for the systems in one frame, and none of changes type, it will still be well organised. The overhead involved in keeping the data organised is worth it because it is reused repeatedly. What you do by using components as flags that change regularly is throw all that out. The memory management has to reassign and reorganise every single entity. Hopefully it will be smart enough to realise that it doesn't have to do any reorganisation of the component data, but the overhead in even checking that is non trivial. ECS can be thought of as semi-dynamic typing. It combines the performance of static typing with the flexibility of dynamic typing, and leverages the fact that casts are usually rare (enemy loses the alive component, for example). Behind the scenes you have an optimised static type system managed to look dynamic. Adding and removing components is ECS's getComponent… It is an extremely powerful tool, and fantastic for when it is needed, but should not be on the hot path.

[@lupod3131]

I do not think that using empty components as tags it is a problem here. The tags are changed only once per turn. During a turn, the archetypes are not touched and ECS runs optimally. If these - in terms of frames - rare changes to archetypes would be a problem, ECS was far less exciting than what it seems to me right now. Using empty components as tags seems to be a key design element in ECS. Implementing a system, you can chose to only run it on entities that have certain components (i.e. tags) by using attributes, or to run it on these entities and also get their data (i.e. not tags), by using the ref parameter. It is also used in several Unite 2019 talks on ECS. An alternative could be to attach a TurnState component to each enemy or player. Instead of filtering by the tag, the system would access the TurnState component's data every frame to check if it's their turn. I'd be suprised if that's actually faster. For me it does not even make sense. We only want to run the action execution system on those entities, that can currently execute actions. Why not use the component based filtering for that.

[@phobos2077_]

@@lupod3131 I have to agree with you. In our project we use empty tag components all the time, even every frame. Without it we would have to iterate over all entities and check for some flag inside component data. It'll almost certainly be slower in terms of iteration. I'm still not 100% sure it's the most efficient way to do it but the overhead these tag components add is nowhere to be seen among the bottlenecks in the profiler.

[@47Mortuus]

I mean I would... but even with a blank project, importing the DOTS stack causes infinite import loops and missing DLLs.

[@starkbotha1129]

"sort of works most of the time"... um excuse me??

[@needlessoptions]

You heard the man 😂

[@rogeriocruz658]

It's in beta, so I would be skeptical of anything else

[@armpap1]

I kind of dislike the whole idea to attach flags and empty components as tags to distinguish the entities from each other and to query them. I am sure there should be a better design pattern to work with ECS.

[@phobos2077_]

Please suggest a better approach. I'm very interested if there is any.

[@47Mortuus]

You can just go back to OOP and use classes. No performance for you :(

[@Nomedeusuariodoluiz]

Top da balada

[@renanlifestyle]

hahahaa

[@Alperic27]

Interesting to watch 2y later… nothing has changed, there are no “new things” that use ecs… and ecs is still largely ‘slow cooking’ somewhere in the kitchen ….

[@phobos2077_]

The ActorComponent example he shows is completely wrong. Breaks the component approach. You don't mix position data and target position, these are 2 separate things.

[@spiral9316]

Even if the code would be changed in the future.. he should'nt have 'brushed' it over really it smells like he didn't made the presentation and just found a perfect excuse to not having to explain it. There's really good code there. Such a waste of opportunity.

[@DanyloSyrotynskyy]

i c no benefits with using ecs in turn based games

[@ThatGamingCh4nnel]

ecs is an upgrade in general for game development. Higher learning curve for sure but it is much more efficient easy to scale than object oriented programming. Its not that turn based games in particular benefit from ecs; guy just wanted to make one using ecs

[@baki9191]

Think of the long turn wait times in a game like Civ and Total War. ECS can benefit turn based games greatly.

[@DanyloSyrotynskyy]

@@baki9191 well, in terms of performance DOTS is much faster then classic Unity definitely)

[@mrp0001]

It's performance *by default*, so no matter what you do, you get extra performance to enjoy.

[@DanyloSyrotynskyy]

Mrp1 yeah, it makes sense to subsystems like pathfinders using dots

[@phobos2077_]

You should create a ComponentSystemGroup and update IT instead of every system manually. This prototype has bad practices written all over it... Can't believe Unity couldn't find someone who actually knows programming principles to do this presentation.

[@phobos2077_]

Composition vs inheritance is completely irrelevant to the ECS topic since GameObjects already encourage composition. There's no inheritence involved unless you mess up your MonoBehavior design.

[@joshua.jebadurai]

First

[@tatoforever]

This is obviously not the right way to use ECS. Specially when very simple OOP can do the job faster and better. You want to use ECS when you need large amounts of simulations. OOP mentality is clearly not the problem. Use the right tool for the right job. Btw, this ECS idea is nothing new, this have been around for decades. Relational databases queries, anyone?

[@keldencowan]

OOP mentality is often the problem. A little bit of OOP in an unpure functional/relational program can throw a wrench in the whole works. You are right about using the right tool for the right job. But mixing stateless ECS with stateful OOP could lead to some very hard to trace bugs. Beware.

[@TheMrKeksLp]

@@keldencowan Bad OOP can be a problem (mostly because of deep inheritance problems) but even worse ECS doesn't solve the issue. The way it's implemented in this talk is horrific in my estimation

[@mrp0001]

Although I didn't exactly like the implementation in the video, Large amounts of things is not a *requirement* for ECS. You can implement it in any project for easy scaling, re-using, and performance by default. Add it to a game and just enjoy the performance, if building for Android it saves processor load and battery usage, even if you're not having thousands of things. OOP is directly not faster than this, by the way. Maybe doing this through OOP is, but performance is 100% better with ECS used here.