A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Data Oriented Technology Stack' started by eizenhorn, Sep 26, 2018.
Well Im his listener and he need to make me happy and I want to hear how this game was made
You mentioned you changed core of your game. How much of your 2018 write up on page 1 is now different or bad advice ?
I'm looking forward to the write-up. Can't believe the original post was in 2018. Time flies.
100% (if not count audio\models\textures but even they changed many times and improved in comparsion with beginning), through 2 last years of, from GDC 2018, our game development (and it was 2 years before our decision change our game to DOTS) it absolutely different game, because DOTS evolve, API evolve and change (and we always on latest version). And month ago, as I mentioned, we decided rewrite game core now it clean, much more performant, using better memory management About bad advice - concept still the same, split data effectively, use more atomic systems istead of big complex monsters (same for jobs), know your data, pack chunks with less fragmentation (of course there is caseses where chunk have 1-2 objects, all depends on situation) etc, just API and way of implementation different.
@eizenhorn Ive asked you earlier in your project if you jumped to SRP and you said no. Did you end your project on SRP, I ask because I thought I read somewhere you used shadergraph.
No. We're on built-in. I not use any node graphs, I prefer write shaders manually.
Having not written shaders I didn’t know how to instance them to make what I wanted.
hats off to you again
@eizenhorn that fish jump. I love it.
I have never heard about Addressables until just now. I wrote my own system that sort-of worked like Addressables, but it's not as nice as Addressables. Mine auto-generates an enum type as an "address" for each asset.
How do you pass around addresses within ECS? Since IComponentData can't hold strings because they're not blittable, isn't it a problem if you want a component to hold an address?
struct EnemiesToSpawn : IComponentData
public string addressOfEnemyPrefab1; // error - not blittable
..... inside of a system....
Hello! You can use NativeString with fixed length like NativeString64, NativeString128, etc.
What I did was to use a FixedString4096 (I don't think I will ever reach that length, but optimization comes later ) to store it.
EDIT: lol, didn't saw the reply above
Awesome - thanks guys!! I've been using FixedList, but I didn't know there was a FixedString. That will work perfectly for Addressables.
I just when through the the Game Mechanic on steam for Diplomacy is Not an Option. Super entertaining especially
'Populations and Funerals "
Can't wait to try out Diplomacy is Not an Option - it looks freak'n amazing. You're going to be one of the first of us to release a full DOTS game on steam - Make us proud Eizenhorn!
Were you able to figure out a way to get a FixedString to work in the inspector? I can do it with IConvertGameObjectToEntity, but that is a huge pain in the ars. I have a whole bunch of components using [GenerateAuthoringComponent] that used to have things like "public Entity myPrefab" to reference prefabs, particle systems, audio clips, and other things to instantiate. It will take a long time to write authoring components for all of those components.
The ideal situation would be a type that could be added to IComponentData that could be filtered by 1 or more labels, so that the level designer could be working on a prefab in the inspector and have a drop-down box that let him/her select from a list of available assets - for example: a combo box of "enemies", "particle effects", or "sound clips". That's probably unobtainable... for now I'd be happy with just a string field that works in the inspector without having write authoring components for everything.
I almost never use the GenerateAuthoringComponentAttribute myself, but AFAIK this is a known limitation (and hopefully will be supported somewhere in the future).
What do you use instead? Subscenes + IConvertGameObjectToEntity?
Working hard in the middle of the week!
Correct, I always create 1-to-many authoring components (so the GD don't need to figure by himself which components are needed to add X feature to an Entity).
It is the most powerful weapon in the game.
No, this is most powerful
Reimagined spells system (just visuals, for now, will restore explosions soon)
Sweet mother !!
rock paper scissor this motherload
Are you using UI ToolKits or new Input with DOTS in your game
com.unity.inputsystem with our own wrapper for DOTS
Excellent job and thanks for sharing! I've got a question. How did you make game configuration/setting in DOTS? I'm looking for a way to make entity template(Archtype + Default Values) without using Prefab(GameObject Based + ConvertToEntity workflow). May be ScriptableObject's an option. So wanna know you way in production. How do you config workerman's properties(such as speed/effeciency..)? Really appreciate for your reply.
Our global configurations are ScriptableObject's they store procedural generation parameters, navigation parameters, physics parameters, initial user data (like resources amount, initial building set, buildings\units\upgrades shops parameters etc.), parameters for citizens logic like death\born coefficients etc. For units we have prefabs of a unit which contain parameters like base speed, base damage, base rotation speed, renderer, colliders, navigation agent, and other parameters for a unit, then after loading required prefabs through addressables we converting them and all shared immutable data become blobs, which mean every unit not spend chunk space to same values but only spend 8 bytes to
BlobAssetReferenceData (can be implemented differently by hash map\blob etc of all units parameters references and access them by unit type id and thus reduce this 8 bytes to 4 bytes of integer id, but we decided just use blobs directly because it's not so much cost, it's convenient and works perfect for us.
Hi @eizenhorn. I've only experimented with DOTS in hobby projects, and am considering starting a production project.
My question is, if you were to start again, would you use ECS or MB? And what advice would you give to someone who is going to choose between the two for a new project? How has ECS contributed to development complexity and time for you, and would you have been able to achieve what you have with a MB architecture?
Personally - only DOTS, next project also will be based on DOTS. I just love DOD approach and ECS, for me they match game development process perfectly.
Advice? Well if you ready to change your brain, if you ready to challenges with preview tech stack and if it will give you really benefits - use it, if you experienced enough, it wouldn't be a huge problem. But not all projects require benefits of ECS, you still can use other DOTS parts like Jobs and Burst with MB land and it will give you performance gains if you require them. ECS itself not only about performance (performance came from DOD approach with which ECS works very well) but about architecture structure and code organisation, and this is very convenient for me.
About achievements. Well, you can do something like that in MB of course, but from MB left only very small core parts. You can manage multithreading by yourself as it was before DOTS, you can use your unsafe collections and exclude MB straightforward way and manage everything on your own array-like storages, you can draw by yourself through DrawMesh(Instanced(Indirect)) etc. and it will require much more work from you eventually. But it's about performance. If look at this from iteration time and project complexity side, you do not always need what ECS offers, you not always have time to cover lack of some features in DOTS, it's not a silver bullet, in this case, you can develop with MB, eventually - people developed with MB many many years and it was not only simple but big AAA and complex games. As some middle ground, you can always mix DOTS (not only Jobs and Burst) and MB in some sort of hybrid approach, moving some complex simulations to ECS/Jobs/Burst and presentation/simple simulation\regular gameplay logic to MB.
Now we know your next project won't target mobile devices .... DOTS is so broken on Android right now that it will likely be a very long time before it can be used in an Android game.
Hello there It's been a long time from the last update We signed with investors and now working much more hard than before
Fresh news! After rewriting core we finally restored and improved indicators logic! Rethought a bit game bars (heals, upgrade etc.) now they really feel as part of the world despite all they are just screen space texture through post-processing which renders in 1 drawcall. Improved explosions logic and spells! BTW there is new in-game UI template!
(Video directly from the editor with music from Spotify, as I have no time now for pretty recordings )
First: Great work!
Second: I'm currently working also on a building game with units on DOTS. How do you handle savegames? i struggle with dots serialization at the moment :/
In two words - our solution is remapping non-serializable types to serializable by unique ID on preprocessing before world serialization (we have our own GUID system for every prefab\asset\etc.). On deserialization - remap back on world deserialize postprocessing. Types which serializable by definition we don't even touch and they serialized\deserialized as is. Also, we excluding blob serialization (remove on preprocess) and then restore them from addressables on deserialization (it allows us dynamically change immutable data with patches\updates even with old serialized saved games)
Hello, what is the polygon count of a single screen in the final version of this game?
Can you tell us some performance indicators of the limit?
Which version of Unity3D and other DOTS components do you currently use?
Our team is evaluating how to use DOTS to make our game.
Do you want to try to release your game on mobile?
Oh duno why I missed your post @steve_zeng (as I subscribed to every message in both SRP, DOTS, Graphic Experimental and Beta maybe overlooked)
Not measured that yet as art still evolving and changes a bit from time to time, but for example in this scene (beginning of city with pre spawned army:
Don't get what you meant, you mean total limit when everything becomes laggy? Well, all depends on hardware, but on Ryzen 9 3900x limited by JobsUtility.MaxJobThreadCount = 4 device with 32 RAM and GeForce 2080SUPER, with all our current logic, our pathfinding, our physics, economics logic, citizens lifecycle, food consuming, etc. etc. it's around 40-50k for ~60fps but depends on actions - floating between 50-65, as some UI instant actions can do some cost things.
Always on the latest packages and latest Unity beta.
That's sad to hear but basically answers my question as to whether DOTS is even worth considering for a cross-platform title.
I'm compiling for Android and iOS "without" show-stopping issues (see my signature). And now that the animations package is "usable" i have everything DOTS related that I need. It's definitely not perfect, but it's doable if you're willing to go the "'extra mile"...
That's interesting as Iclemens' mentions Android being a show-stopper in my other thread. But additionally, the game is cross-platform multiplayer and network sounds like an additional massive barrier. Which prompts me to another thread idea...
FYI, my overall crash rate is ≈1-1.5% on Android, slightly lower on iOS. I'm not using multiplayer or any sort of "netcode". Most of the crashed isn't due to Dots, but Google Mobile Ads...
Can confirm that Hybrid v2 currently has a few showstopping bugs, but they seem like small issues not fundamental ones, but the progress has been quite noticeable. I'd say 3-4 months until I can switch over. Also after switching over to 2020.1 I can't build AABs for some reason, (just APKs directly), but that's likely not dots related and more likely a editor/platforms-package issue. 2020.2 SubScenes don't work at all right now, so I can't try URP 10. It's somewhat of a minefield and stepping on all those mines will be a big productivity hit until you hit the sweet spot of editor/package combination that allows you to be productive for a month or two until you have to update for some new feature that you need.
I hope you're right about the HRV2 issues being small issues. You make a good point there about finding that "sweet spot". Some of these issues aren't directly the result of DOTS, but they are indirectly the result because many of the DOTS packages only support a few of the latest versions of Unity (like 2020.1), so we end up using other preview packages which have bugs.
We should use the other thread ( https://forum.unity.com/threads/when-is-dots-going-to-be-viable-for-commericial-deployment.1016752 ) so that we don't hijack this thread about eizenhorn's badass game
Eisenhorn... what do you use for animating characters? Are the animations baked into textures, or baked into meshes, or did you make your own animation system... or something else?
Our custom animation system with our custom handwritten shaders and MaterialPropertyAttribute's (We're on built-in render pipeline, not SRP). Currently baked position\normal into texture, but we will improve it to compute buffers for better flexibility and blending.
Cool! It looks good in your videos. I wish I had the knowledge to write my own baked texture shader... for now I'm trying to find one that's already written and can work with ECS and Hybrid Renderer V2. Is it true that compute buffers won't work on most mobile platforms?
Well, in most cases Compute Buffers requirements match Compute Shaders requirements (but not always):
Windows and Windows Store, with a DirectX 11 or DirectX 12 graphics API and Shader Model 5.0 GPU
macOS and iOS using Metal graphics API
Android, Linux and Windows platforms with Vulkan API
OpenGL platforms (OpenGL 4.3 on Linux or Windows; OpenGL ES 3.1 on Android). Note that Mac OS X does not support OpenGL 4.3
Modern consoles (Sony PS4 and Microsoft Xbox One)
That's not too shabby! I saw some stats from back in October that said Vulkan is only on about half of Android devices, and most of the remaining support some version of OpenGL ES. Of those remaining devices, 2/3 were OpenGL ES 3.1 and higher.
I think the 3.0 devices were about 15% of the remaining GL market... which won't support compute buffers/shaders. So I guess some phones will be lost between 3.0 and 3.1, but not too many.
Some screenshots of the current process, soon we'll update Steam page with new pretty funny teaser and new screenshots, as very soon we'll release
This thread is my DOTS inspiration
Curious what you're using for UI. UI Toolkit or the older existing UI system?