Please give me a simpler sample.

I may look rude in English, because i'm not in English country. I am sorry this. But I have to say what I need.

If Unity find it difficult to maintain Wiki, I think Unity should at least give an easier example.

The sample is to show the performance. and is not to the tutorial for the primer. This is because there are already a lot of developers confused. The principles are already found everywhere. However, there are not many shared codes, and the Unity is forcing its developers to reverse engineer with sample. (or without a latest manual)

Therefore, Unity is necessary to release even simpler examples for the primer to have easier access. For example, a simple 'For' loop in OOP into Pure ECS. How would you explain if the primer was blocked here? If you give them a link to the sample, do you think it'll work out? The answer is NO. Some people are solving it, but on the contrary, many people are starting to give up and others who confused. This is the current situation.

ECS and JobSystem announcements are already more than two years old. However, the reality is that it is difficult for developers to using it.

 

I'm from third world country like lot of people here. There are many samples out there for people to google unless you live in China.

For learning ECS through incomplete doc and reverse code, I think this is good learning curve practice since you have to figure out how stuff work at really low level like hardware level. And, it kinda make sense to learn it this way if want to leave OOP and move to new DOP.

It really took me entire day to figure out the magic [Inject] and how Unity Sample magically spawn tons of stuff without reference in scene. So yeah, good learning practice.

 

The best you can do for your mental health is to forget about ECS for a next year or so. Unity released ECS very soon and it is probably good, but it can leave a lot of users used to supersimple gameobjects frustrated. Just come back later and everything will be much more user friendly.

 

Although he sounds rude but he has his point, having a "hello world" sample is the most efficient way to introduce new things to other developers.

Software development has been there for a century but a lot of people still can't provide "hello world" example. When someone say this issue out how about thinking is the sample really too complicated, is that really good for other developer rather than simply fighting back to the poster.

 

Don't get me wrong, but how you going to print help word with current ECS?
You need already hybrid approach to display text. Which is beyond simple line of code. Hence this will be first difficulty of getting head round for most beginners. So already is beyond beginner level.



ECS is not for production ready. Simple as that. And we know that, as has been repeated many times over.
Its core is in Beta, and many features probably in alpha, while many more more not even there yet.
Plus ECS is evolving a lot and dynamically. Hence writing detailed documentation is counter productive.
Unity team has no obligation to supply wiki or tutorials, for betas / previews.
However, they did great job so far, to what they supplied and documentation.
And if you follow pinned threads, you will know, Unity team took our feedback seriously.
But for average Joe starting journey with ECS, this will not be obvious.

I would ask anyone, to write documenation on their game project, while in mid production. You probably would realize quickly, that your documentation becomes obsolete very soon making your time wasted. You will end um most likely rewriting everything from almost scratch.

Unity team should be priced, not kicked, for the fact, we can use Unity features (ECS), far before they meant to be released. If we were few years back, you wouldn't be able touch ECS, before is for production ready. That would be years.

We all know, that ECS requires at least intermediate level of programming knowledge. Specially Unity C#.
Without that I would go back to Classic OOP, spent some time with it and back sometime later (at least months), when I think I am ready to try again.



But bear in mind, we had so far great input from community, who wrote bunch of scripts, working systems and much more. Problem is, anything before second halve of 2018, is probably already obsolete, throwing errors, due to evolution of ECS. Possible to fix and Unity team did update projects. But can not expect update day to day. Few youtube tutorials are already completely obsolete. Yo need understand this simple fact, of where we all standing.



And yet, nothing stops anyone, from adding and posting simple working examples, rather than just complaining. Feel free to update wiki. But how many really use wiki for programming purposes? We got forum, we got github, bitbucket and more. We go great assist from community and Unity team. And if asked politely, people get support.



So personally I don't see issue with Unity, but individuals at most.

 

Yes, I am a student from abroad and I am new to the Unity Community. In other non english countries, primer developer are held only in low-level communities, avoiding formal forums. If the people studies for ECS and JobSystem, he follows examples posted on a blog or YouTube by someone other than this forum. these examples do not match each other, so if you install them, you can only see errors from the beginning.

If you think it's trolling, I think it's just Thread's title. I am sorry about. However, at least the current learning curve is still too difficult. I saw the same developers of at least English-speaking countries. It was not just a matter of skill for them. He was a good programmer. but, it costs a lot of time to learn. Face the reality. Difficult is difficult. They are by no means a low-level programmer. Nevertheless, there is too little information to access it.

However, I may be wrong in the way I suggested. Because ECS and JobSystem are complex. That is why I used the forum to see other people's thoughts. For the tutorials that fit DOPs as much as possible.

 

I started with "ring of cubes" example and immediately confused where the entire thing came from. No where in the docs said they are automatically run by class reflections. IMO the docs should teach you to make a class with ComponentSystem, OnUpdate with Input.GetKeyDown, then logs a message and finally reveals you that's a system. That's the kind of hello world equivalent of ECS.

However that's preview for you. We are all waiting for the "unknown" that is going to replace ComponentDataArray and injects, imagine there are extensive tutorial already it would all require an update once that arrives, so I understand why UT haven't put effort in this area yet. (The current docs already contains some deprecated API, even around the cornerstone chunk iteration methods) Bare example might be harsh, but they are easier to update along with the API because you just fix errors. Complete tutorial and documentations cannot report errors and requires proofreading.

I expect the tutorial with the level you described to be available way after CDA and inject replacement, after "lambda workflow", and after "ECS editor" from UTiny get out of tiny mode. I think that's beginner friendly tutorial should be based on. And that's why it should not be written today.

 

Yes. And indeed true at current state is, to find right information, need to dig in multiple places.

When I started with ECS, (over halve year ago), I looked at samples, and start messing with them. Then read forum. Mind, back then was even less information. So I start asking many questions. People were able to guide in right direction. Then looked into documentation. Which initially looked overwellming. But over the time, all become clearer and clearer. Then read forum search for information and solutions. Back to documentation. Then start looking into source code. Look again into sample. Mess with them, with new knowledge.
And so on. To the point, where I was able to start giving feedback to others eventually.

Now I would say is a bit easier. Bigger community. More forum threads. However, many may be scattered.
Hence, currently need still dig quite a bit. And effort is must, to get head round.

Unfortunately we can do only so much with obsolete content.
For videos at most we can take down, or switch to unlisted / private, if we have ownership. Or ask owner to turn of public mode.

Similarly for documentations from community. They often may be left unmodified for months / forever. Others may keep up to date them. But people comes and go. So nothing is guaranteed. Hence initial reading need be taken with grain of salt. Until up to date validation is confirmed. Or opposite.

Either way, forum is so far best way to get up to date info on ECS

 

I think examples are the best source for learning but the current Unity hybrid ECS sample is very bad for newcomers. So for now I would recommend you look at the Survival Shooter ECS project and blog posts, since this is probably the best place for new people to start learning today.

I personally think the wiki is greatly underappreciated and misused. When done right it can be an especially helpful resource for newcomers. Acting as a kind of repository of useful tidbits of wisdom from the community. For example in this case it could at the very least warn newbies that ECS is maybe not for them. Also video and text tutorials can quickly become obsolete and this is again why I would argue that the wiki is actually better because it can be easily edited and updated.

Just think of the wiki as a kind of community blackboard where you can write down useful public notes and insights you've learned to share with others. Don't worry so much about the content becoming obsolete. It's not any worse than other forms of content. In fact, it is actually better because anyone can come along and update it if needed.

In any case I think what we really need is a complete Unity OOP to ECS example game project and accompanying tutorial that explains everything and walks you through each part. Of course right now making such a thing is no easy task. But I hope to make something like this in the future as maybe even supplemental content to the wiki.

 

You can't just take my word "Hello World" example as printing hello world onto the screen, it's mean the simplest possible example to execute.

One great example made by Brackeys via:

In his example he only introduce one thing, how to rotate an object with ECS.
In that 9 minutes tutorial he efficiently covered the basic introduction to ECS, a working example on simplest possible implementation.

The only reason I can think of Unity not going to write a rotate an object example is that they think it's too simple. They had been facing ECS everyday and developing it everyday, they are too familiar with it, that's what a lot of game studio make mistake as they play through their own game everyday and think the player can handle it and finally making the game way too difficult.

No one say it out because they worry about their qualification as a software developer or programmer will be challenged. But this is a mistake.

 

Video tutorial indeed wraps it nicely. But that is ok for introducing into ECS. Anything after that, you probably wont be using videos tutorials, to write your extensive code.

No offense, but if marked examples are beyond user understanding

ECS is probably too early for them.

https://forum.unity.com/threads/samples.522629/
https://github.com/Unity-Technologies/EntityComponentSystemSamples/tree/master/Samples/Assets/Scenes

 

Why not use the debug logger for that? It is super simple and not hybrid.

Code (CSharp):

1. Debug.Log("Hello World!")

Printing the text is actually the easiest part. The complexity comes from creating an actual system to print it. I will probably try writing a Hello World tutorial over on the wiki, since this seems like a good way to introduce some ECS concepts. Someone has actually already done one for the Entitas framework.

However, moving or rotating a cube is actually easier to write because you don't need a reactive system.

 

Rotation Example is obviously doing more than rotating an object

 

Lets assume we are not talking about C# beginners. Because ECS is out of scope for them.
Anyone with relevant competency (skill/knowledge) can remove add some code, to see what is doing. So personally I don't see an issue here. I managed to learn from worse examples.

 

@Antypodish please tone it down. You made the same point multiple times, and it comes off as bullying. Please in future only post on the ECS forums if you are going to actually contribute to the tech discussion, and not to criticise users.

If someone else appears (even if mistaken) to have attitude, you do not need to respond in kind.

Thanks.

 

Thats fine. Thank you for your point.
Bullying however, is not my intention in slightest. I am realist, hence my point may be interpret in such way.
I am not changing my opinion. But however, I do apologize anyone, who may feels resentful.

Edit:
I updated word competency adding skill/knowledge in brackets, as this may cause misunderstanding of meaning otherwise.

 

I gotta agree. Many outsource programmer from my country fresh out of college use google translate on both stackoverflow and when chat with customer.

Most of them are terrible cuz our college was very bad at copy/paste US university course book when it was really useless in actual US dev school.

So well, I guess people did their best but experience and skills are lacking out here. @tempria you should learn some more standard stuff until you got enough analystic/debug skill to learn ECS.

 

From a quick glance (so I may be overlooking something), the only two projects that are not dependent on "planned to be deprecated" API are the boid example and phyllotaxis. Both these projects are way more complicated than the single C# script required to get a million cubes rotating multithreaded. If no one beats me to writing that script and posting it by this weekend, I'll write it.

...assuming I remember
...which I probably won't

 

Using your opinions, This threads points out that all (Official)ECS examples are still technologies that require a deep level of reverse engineering that are difficult to access by existing developers regardless of their skills. Realistically, Unity already promotes ECS and JobSystem. And yet Unity stress that the ECS is not production ready. Unity should face this fact as much as I believe in Unity. This could hurt the emphasis on Unity's ECS & JobSystem merits. (Even though Unity mentioned early access.)

Brackney's Tutorial was very effective at the entrance. But Brackney's Tutorial dose not handle Pure ECS. The tutorial videos covering the transition from OOP to Pure ECS include the Infallible Code, the ShojibTutorials, Etc... but this is a sign that Unity is neglecting the official tutorial.

So This approximates my pointless remarks. Unity needs to supplement Wiki a little more. If this is difficult, a simpler example is needed than the official example. Another way is to support more to informal educators, such as Brackney's Tutorial. Especially in PureECS. If it has been two years since its release and has changed many of times, it needs to be maintain from 2019.

Thank you for giving me examples and directions.

 

I'm not much of a writer so not sure how much use it will be to people, but I just wrote a small article where I coded a simple rotation example three different ways

• Iterating chunks in ComponentSystem
• Using IJobChunk
• Using IJobProcessComponentData

I personally learn a lot better reading source code and so I put an emphasis on that over the actual writing. Anyway maybe someone will find it useful, https://www.bovinelabs.com/ecs-hello-world/

 

Quick question. Does IJobChunk process each chunk on different thread like IJobProcessComponentData or all chunks on single worker thread? I never use JobChunk so.

 

Each chunk on a separate thread.

 

Thanks @tertle! That was a really nice simple introduction to chunk Iteration and using IJobChunk and IJobProcessComponentData for OOP peasants like myself. I think the best learning material is source code/examples combined with thorough comments/explanations and you did an excellent job (no pun intended) here in that regard. The only criticism I would make is that naming a component group a query might be confusing and it's not technically a "Hello World" tutorial , but who cares! Thanks for going to the trouble to write it. This is the kind of content we need on the wiki. So I will at least put a link to your blog there.

 

@tempria I just recently started a tutorial series that hopes to do exactly that:

1. Most up-to-date way to write ECS code (with Jobs)
2. Simple example that gets into the mindset of writing Data-Oriented code

The genre I chose is RTS as I feel it suites itself very well to ECS. Hopefully it helps!

Link to post: https://forum.unity.com/threads/tut...ries-to-cover-making-jobified-systems.611743/

Direct link to video:

 

I have put a set of 6 very basic Example/Tutorials up on GameDev.net. They build a simple Conway's Game of Life cellular automaton. They do not use Hybrid-renderer just ECS for simulation and then calls Static methods on game objects to update the screen. They work on Entities 0.4.0 I am now testing on Entities 0.5.0 that came out today. https://www.gamedev.net/tutorials/p...s-life-tutorial-entities-040-preview10-r5293/

 

Just to throw in some thoughts from a relatively new guy, especially to DOTS...

1) Thanks to everyone who has done tutorials. There are tons of you who have been doing it for some time. And also, a huge thank you to the few really active forum members who jump int and share their experience. Frankly, without those, I would have been lost! So a big thanks to everyone!

2) One of the worst things about the DOTS/ECS roll out is just that it got so much public attention from the start. There are too many tutorials built around 0.1, providing solutions that aren't really problems in later versions. My suggestion for this is: The sooner there is a more unified base of information, the better. I realize it may not be time yet, and there is a long road for total ECS conversion. But the popularity is a curse in itself, and I believe has made it a bit more urgent (more for PR!).

3) For anyone doing tutorials, after seeing dozens of them, my suggestion is to focus on the individual elements that make DOTS functional. We have tons of parts of DOTS, and they all get jumbled together. The theory and principles are covered hundreds of times over, but the tools are woefully under-explained.

For example, Jobs! Jobs is a huge topic and is always coupled together with tons of other stuff. Why not cover the 7(?) types of jobs that are used, starting with the ones that are not ECS related. Schedule the jobs from a mono-behavior in update ie: keep it familiar to the newcomers. And that's just a small part of jobs. There are quite a few types of jobs, handles/dependencies, scheduling, ordering, etc. And that's not even getting into burst, the new math library, etc. And all of that is still not covering how to integrate jobs into your normal loop - something that is quite daunting now.

I'd (almost?!) pay for a tutorial series that covered each of the different key words used in DOTS, and the main problem they solve. Like, why do we have NativeArrays? What is a IBufferElementData? SharedComponent? SystemState? Types of jobs that there are available? EntityCommandBuffer? Why would I ever use chunks specifically? (Seriously, why would I?!) A practical guide to each of the elements is what I'm always looking for. Most of what I have learnt has been on the forums when someone goes "why don't you use x", where x is = thing I had no idea how to use properly. (Before anyone jumps in to actually help, I'm using these as examples that I struggled with.)

 

I just went to teach ECS a week ago, I found it was very useful that I explained pure C# Jobs first how you use IJobs and get result from them in MonoBehaviour, and how to perform dependency. Then when I go to JobComponentSystem, they could appreciate the data coming from seemingly nowhere, read/write markers, more parallel jobs than you asked for, and auto handle chaining stuff.. I think the official docs may need this kind of explanation sequence.

I am planning my https://gametorrahod.com/tag/unity-ecs/ to be like this, so there is an article about only SCD, about only EQ overloads of manager, etc. (a guide about only ISystemState__ would also need to be there, but I wasn't content yet) They are less painful to update to follow API changes, than a guide to do specifically some task or example project walkthrough.