I am professional programmer but a Unity hobbyist. I have an idea for a game I’d like to make.
It would look much like the sprite baed space shooters of old that used to be in the arcade halls. It will feature a lot of objects floating around in space that can be interacted with and/or blown up. There would be a bit of building like say Theme Hospital and a bit of resource gathering like Starscape. Actually Starscape is a good reference of what look I am aiming for.
So, now comes the questions; for this new, non-deadlined, hobby project, do I dive into ECS? A technology that shows a lot of promise but that I have very little experience with. Or, do I stick to the MonoBehaviour techniques that I know?
On one hand, new tech and the promise of easier scaling and the insane performance boost that ECS delivers or promises to deliver are very attractive. On the other, the tooling isn’t quite there yet and the amount of work to do just to get a few sprites working is quite extensive. ECS seems to be the future, but is that future ready to be used yet?
That video really helped me. Showed me that the way your thinking about it which is the way most people, myself included, think about DOTs is wrong when it comes to whether to learn it or not and when to learn it or not.
You dont have to commit to it at all, you can incrementally add bits of it to your current projects and reap benefits all while learning it incrementally.
Follow that video and I am 100% certain by the end you will have a good idea of how to start immediatly, as well as have ideas for bits in your own projects that could use it.
In short: yes its ready to be used, and its also 100x easier than you would expect due to the new workflow detailed in that video.
I would bang the prototype in classic way first. Ensuring prove of concept. It may be faster, if you are comfortable with GameObjects.
Then, look later, how to transfer relevant bits to jobs.
You grab that concept, then you can convert to DODS.
What you can do, if you are programmer already, start from Data Oriented Design, rather strictly focusing on Object Oriented Programming. Will be easier to convert later.
If you plan to have lots of objects flying around in your scene, then using ECS instead of using a game object for each projectile makes sense. For example, if you plan to have thousands of lasers flying around in your scene, you want to use ECS or something similar to handle those projectiles in a scalable way.
You don’t have to use ECS specifically, though. You can write your own systems from scratch instead of using ECS, but ECS is generally a better option at this point. For example, I released Disputed Space in 2017 using Unity 5.5, and I build my own data oriented system from scratch that used DrawMeshInstanced. ECS was not an option when I built that game, so I developed my own system. If I was starting a new project today, I would probably just use ECS. If you have never built something like this from scratch, then you should definitely use ECS instead of trying to design your own system.
As for pure scalability, using a separate game object for each projectile will never achieve the level of performance you can get with a data oriented system (like mine or like ECS). Data oriented systems are often 6-10 times as scalable as a typical game object pooling system. By using ECS instead of sticking to the MonoBehaviour techniques that you already know, you can get that 6-10 times scalability improvement.
Thanks for those answers. My background is math and data science. Work revolves around Python and R. I play games and I know a about game theory in the math sense. ECS and data oriented is really enticing.
Awesome. You should definitely try ECS. There will be some initial effort learning about data oriented systems, but it will definitely be worth it. Enjoy.
Won’t using ECS for projectiles force you to use ECS for a lot of other things? If you have a player Game Object with a rigidbody and a collider will it still be able to collide with an ECS bullet?
It depends. For example, some projectiles are easier than others to implement. For example, a laser only collides with other things. Nothing can collide with a laser, so a laser does not need its own rigidbody or collider. But a large slow moving torpedo might need to be able to accept collisions in addition to colliding with something, like if a laser shoots a torpedo to blow it up.
Another example would be moving asteroids. If there are thousands of asteroids in a scene, then ECS would seem like the answer. However, a detailed asteroid simulation would need a rigidbody and collider on each asteroid. To make an ECS based asteroid field, you would need to implement some kind of manual collision check within the asteroid ECS to fake some of the physics. But if the asteroid field is merely a visual thing in the distance, then it would not need any collision code and could easily be implemented in ECS.
I think there has also been some progress on ECS based physic this year, so always check with threads about the status when working on this: https://discussions.unity.com/t/736062
Depending on how many “a lot” is, I’d be doing this data oriented anyway. And now Unity have a built-in system to standardise that, so it sounds like a clear win to me.
Of course, if “lots” is really “a few dozen” then I’d go with whatever is faster and/or more fun to work with.
I always think it is important to prototype quickly, actually I follow an agile scrum type model.
Normally, the code you throw together is unorganised and difficult to navigate, but it is a proof of concept phase. Somewhere down the line you need to consider adopting good practices to modularise your code, use higher level concepts to improve performance and maintainability.
E.g. I’m looking at State management + concurrency now (unrelated to unity) and it’s amazing.
That was a truly excellent video. Before that I thought that whole convert to stuff was some sort of crutch. But it’s actually quite effective it seems.
Yes it too changed my perspective on the conversion workflow, it seems like it will be the defacto way to author ECS whilst retaining the speed and ease of prototyping that unity is famous for
Personally I don’t think you need to try the whole DOTS thing if you are not doing something that needs a lot of performance optimization. I mean, you have to learn new stuff, the coding for it is still fairly complicated IMO, the whole job system is still not as easy as it could be, it takes more thought to plan your data structures and stuff etc. I would think actually MOST games don’t really need it. Especially not any kind of 2D game unless you’re trying to do a heck of a lot of pixel manipulation or something.
Did you watch the video above? The coding is certainly not that complicated anymore, it basically is the same amount of code too now, DOTs has changed a lot recently and its probably not like you remember based on what your saying. It certainly is not just for “big things”, which is something they address in the video.
Performance is good for performance sake, and as software developers we should be trying to pick the most performant option vs time consumption to implement it.
Now that DOTS takes no longer to author than monobehaviours and is convertible from one to the other, you should be picking the more performant option where it makes sense. The video highlights that not everything is good for DOTs, but almost any project has at least 1 or 2 places it can and therefore should be used.
^ I don’t necessarily agree with that. Sure it is more performant but async coding is harder to grasp / debug, so your developers need to know what’s the deal.
I’d still opt for the old way for smallish games IMO.
