so when you press trigger, it creates an entity from atemplate
#archived-dots
vagrant surge
for something like a simple fireball, the eneity would have Projectile component, CollideSphere comp, and DamageOnHit comp
DamageOnHit holds another entity template, as damage events are done by creating an entity that applies the effect
but
it gets more fun
if i go and give it a Bounce component, the fireball now bounces, damaging on each hit
if i go and give it a AOE on hit component, each time the projectile bounces, it explodes
if i go and give it a SpawnOnHit component, each time the projectile bounces, it creates another entity, creating cluster bombs
you can also create a mine, by having the projectile create a new entity when it hits a wall, and this entity has a big collision sphere + AOE damage, so when an enemy gets close, it explodes
you can also, on any of the projectiles, give it auto-home ability with a comp
and with the damage entities, you can apply complex effects when it hits someone, like applying buffs/debuffs
i only had maybe about 10 components on the projectile stuff, but it was enough to basically create any spell ever
solid flume
This is the primary reason I want to learn ECS
The game I'm about to release on android, adding modular functionality was a nightmare of inheritance and typecasting
vagrant surge
too bad this sort of ecs shanenigans are tricky to do with unity ecs
as they kinda rely on being able to easily spawn stuff and modify stuff, which does sync points
solid flume
sync points?
Is there any way I can make a couple wrapper functions for NativeArray?
deft stump
it forces all jobs to finish and make architectural changes.
solid flume
I figured its the best way for me to make my octree
Will extension methods for native arrays work inside jobs?
Including bursted ones?
And is there any way I can create a wrapper for nativearray?
Looks like INativeDisposable and INativeList<T> are the way to go
mint iron
there's a few floating around at varying levels of maturity you could use. https://github.com/jeffvella/NativeOctree
solid flume
Using premade code is no fun
I want to make my own
Kind figured a method that works for my specific purposes, basically just an 8-d tree in a nativearray
zinc plinth
Then make your own ecs :')
(jk jk)
vagrant surge
look up how to make octrees for gpus
gpus require octrees to be completely flat
so this works great with the way unity ECS and burst works
violet cosmos
@vagrant surge That's actually the system I'm trying to build with Unity's ECS.... "Abilities" that are built from ECS components.
But I'm having a hell of a time
- The hybrid workflow, and many small bugs adding up
- Can't load a single prefab, need to load a "scene". Need to make a custom way to address a single prefab
- Can't instantiate a whole prefab parent/child from a deserialized entity correctly at runtime
- Can't destroy a prefab and it's children correctly
- Runtime initialization requires a custom solution, and is tricky to mix in data outside ECS
A lot of my expectations have definitely hit the wall with a sickening sound, my friend
violet cosmos
Yes, but I'm trying to take advantage of the performance side of Unity ECS with Burst. I could just make this with MonoBehaviours as a "component" and Jobs
vagrant surge
you cant make a spell system of this sort performant on unity ecs
making the same system in unity will be faster
(no joke)
violet cosmos
I know, I already have one in regular MB
vagrant surge
but it doesnt matter much because abilities are not usually a perf bottleneck, its something that only happens every now and then
violet cosmos
Everything in my game is an ability. An arrow. A bullet. Abilities are also a bit more... complex than fireball waiting to hit a target
vagrant surge
uhmm
violet cosmos
Also, all enemies will use the same system
vagrant surge
what sort of scale are we talking about? how many
violet cosmos
Haven't decided yet. But, I am recently considering walking away from ECS, because of those issues I mentioned
vagrant surge
at the current state/pain level of ECS, i would only really use it if i have a project where im running hundreds of X, and need the accelration of multithreading + burst
i would just run entitas, or not run unity at all, if it was a more moderate project
vagrant surge
yup
trail burrow
its good for math acceleration
but the rest it's just... meh for
just use GO/MB system if you want to build an actual game
and then use jobs+burst to accelerate some math heavy stuff if you need it
vagrant surge
or something like entitas, which has had years to mature and works pretty well (if you want to do ECS stuff)
trail burrow
but Unity ECS as a whole is... well, ugh.... not finished, half broken, keeps changing, etc. wouldn't recommend it to anyone
violet cosmos
I'm learning that, and honestly I haven't even delved into the Physics package which I'm also very concerned is just as many broken expectations
trail burrow
Just don't even bother right now
maybe in 3 years or so
they might have something
vagrant surge
pretty sure Svelto ECS (from sebas) could also be a much better option
and that one is pretty high perf
violet cosmos
What's silly is they could address my issues with two devs and one doc writer, in one month. But, I feel looking into the source code of ECS that it transitioned from being an API into a dumping ground to make MegaCity
trail burrow
@vagrant surge yeah but they all run into the same issue of having to use unitys go/mb physics, unitys nav mesh, unity animation, etc.
vagrant surge
@violet cosmos have you looked into the TPS demo lol
trail burrow
right so at that point its just a thin wrapper to structure logic
with some fluff and callbacks around
vagrant surge
@trail burrow yeah, but thats pretty alright
violet cosmos
@vagrant surge TPS?
violet cosmos
Ah, no. Is that ECS?
vagrant surge
yes-ish
trail burrow
they kinda bastardized the 'old' fps sample?
vagrant surge
yup
trail burrow
into some new thing
vagrant surge
its a bastardized old fps sample but with the newer ecs animation and couple of thing
an absolute mess
trail burrow
i mean what did you expect it to be properly done and neatly architected without hacks? lol welcome to unity
vagrant surge
the current best ECS projects unity has is the TinyRacer and other Unity Tiny samples
@trail burrow quite a lot of games get very quickly bottleneced in the game logic
in unreal, its a daily occurence
deft stump
I'm still not sold on the existence of project tiny
vagrant surge
tho unreal is even worse than unity on this
trail burrow
@vagrant surge i mean, -ish, it does happen for larger complex games absolutely
vagrant surge
for example, in PUBG, the "hot spots" were on animation (100 characters... ofc) some physics on vehicles, and... game logic for those characters
trail burrow
no matter we pretty much agree with each other
unitys ecs is useless atm
for any real project
deft stump
^ yep
vagrant surge
ECS as a pattern makes multithreading very easy, and is faster than typical oop arches generally. So its pretty nice when your game has "tons of x"
violet cosmos
I'm starting to agree. ECS is not built with real world scenarios in mind. It seems built to make pretty tech demo videos that shows Unity can handle "millions of things"
trail burrow
idk what unity is doing tbh, unity ECS has not gotten very far in 3 years?
vagrant surge
nope
trail burrow
like you cant build any more with it right now then you could when it launched
vagrant surge
they have changed the apis like 20 times
for the better, at least
but editor support is essentially non existant
vagrant surge
and the new packages (physics, animation, render) are all super jank
violet cosmos
You know, if ECS could just save a prefab into an Addressable .entity file, Instantiate that as the full hybrid parent->child chain, and Destroy as the full parent->child chain.... I might continue to struggle with it
But I'm really not sure if I want to write my own serialization addressing system at this point
trail burrow
then like always, they just... uh.. said a lot of big and nice things
and never got anywhere
lol
vagrant surge
i can say for a fact i have better support for ECS in unreal (self rolled ECS and self rolled systems) than what unity does right now
trail burrow
have we seen it before?
vagrant surge
at similar levels of speed
that unreal-ecs is what i used for the ability system i explained above
trail burrow
@vagrant surge yeah we have a better ecs also in quantum, full determinism predict/rollback, custom physics (2d&3d), navigation, etc. can run in .net core if you want, etc.
vagrant surge
neat
violet cosmos
The point of Unity ECS though is memory optimization, to be fed into Burst and on to cache. I get it, but somewhere after that was done and today some other team picked it up and it's a mess
I really feel like the internal demo projects MegaCity and very likely FPS shooter steered it wrong
You can see the other team's code, it's like.... stapled in there
trail burrow
@violet cosmos yeah, all aware of this, we do the same thing in quantum but for different reasons
violet cosmos
@trail burrow Is Quantum Burst compatible?
trail burrow
no, absolutely not
violet cosmos
haha, damn. Burst is important to me
trail burrow
we have our own memory optimized ecs, etc. all that stuff
really? it's barely faster than regular .net core
deft stump
i'd take .net core over burst any day
deft stump
the only thing I dont want them to take away is the job system, that shit it cool imo.
deft stump
sure the safety system makes it quite limiting to use other than for computational stuff.
but hey, at least you got a proper multi-threading solution.
trail burrow
yeah, we built our own task system
but actually wrap each 'worker thread' into an IJob
as it has less overhead than manually managing monos managed threads
violet cosmos
@trail burrow What does defining a task and returning it's results to the owner look like?
trail burrow
this is all proprietary code sorry
violet cosmos
Birds eye view
trail burrow
give or take same as any task api
nothing special
it is a very purpose built system specific for quantum so
deft stump
welp I'm convinced. I have to re-migrate my game back into mono unity.
the choice of either, trying to hack my game just for the sake of getting 1 frame more,
Or actually making the f'n game... I should have chose the latter 2 months ago.
good thing I kept a branch just for mono unity
violet cosmos
@deft stump I'm coming to about the same conclusion
trail burrow
@deft stump yeah, 100% this is the thing
violet cosmos
The last few days have been.... difficult
trail burrow
sure if you HAVE a game which can benefit from massive parallelism
sure, go down that route
but for 99% of the games that are made with unity
its useless
deft stump
for better or worst.
Unity's marketing team are rock solid.
they've managed to get people excited for dots
trail burrow
yes, but when there's nothing to back that excitement up
it's ... well
looks like a failure
people come
all excited
then when they start using it
they meet broken samples, out dated docs, broken functionality
changing APIs
vagrant surge
i mean, stuff like megacity is the real deal. good luck doing something like that in unreal or custom engine
trail burrow
broken promises about all kinds of stuff
violet cosmos
You know, I wonder if I can gut ECS and turn it into a memory management task-feeding machine
trail burrow
@vagrant surge yes but its a small demo hand coded by a team at unity, and its not a re-usable thing
vagrant surge
just the 50k cars they have flying around? literally not possible, whatsoever, to have 50k objects flying around in ue4
yeah, but it was a nice sample
trail burrow
@vagrant surge but thats the thing, they just do nice samples which look cool, but never materalize in real usable tooling - i feel like epic is the opposite (most of the time).
trail burrow
Maybe not as flashy demos, but most stuff materializes into something
trail burrow
yes, exactly
vagrant surge
existed since before ue4 was public
you can still run shootergame on 4.25
on ps5
trail burrow
that's what should be done for unity also
vagrant surge
in fact, shootergame can compile, and can pass QA, on all platforms ue4 supports
all of them
trail burrow
but it's like they are ALLERGIC to supporting and imporving exidting functionality
always have to throw away and start over
vagrant surge
they use shootergame in ue4 as a test suite, basically. Its part of their testing
but so are the other samples
they still use Elemental and Infiltrator to check regressions and do performance testing
trail burrow
look at networking:
- raknet networking - thrown away
- unet networking - thrown away
- dots networking - not ready/broken still
- now they are building unet 2.0 networking for go/mb system again...
like wtf.
vagrant surge
you forget unity tiny
violet cosmos
Well, that was good for Photon ๐
deft stump
god I wish unity made their engine open source.
I would make 5 pr's in a singleday
trail burrow
it's like this with everything
mecanim abandoned?
old renderer abandoned?
all of it, just left by the wayside
vagrant surge
- unity tiny prototype in JS - thrown away (it was a prototype tho)
- unity tiny C#, 2d based - thrown away (such a godddamn shame, it had a working editor)
- unity tiny, but now 3d based, with barely working conversion workflow
or the absolute 180 they did on the visual scripting
vagrant surge
yup
trail burrow
people waited on Bolt 2.0
vagrant surge
second version was lit tho
vagrant surge
the visual scripting...
holy shit seriously
original version was about autogenerating ECS systems
it generated C#
deft stump
wait what? Bolt 2 is no more?
I thought Bolt 2 will still be released?
vagrant surge
newer version is basically bolt but unity
violet cosmos
@deft stump I have to admit, if ECS and hybrid were on GitHub, and they actually had a workflow to take PR's, I might stick with it and help improve it. But... They refuse to actually work with the community on a meaningful level. They don't even have a next update roadmap FFS
vagrant surge
and now they bought bolt
absolutely hilarious planning
if you are going to buy bolt
you already have a "event layer" visual script
vagrant surge
so why remove the visual scripting for codegen/ECS, and convert it into another event layer visual script
basically starting from scratch
trail burrow
@deft stump sticking with Bolt 1.0 and integrating it tigheter into engine instead
it's gone
2.0
vagrant surge
@violet cosmos bestest part is that they could clone what entitas does in like... no time flat
deft stump
vagrant surge
and that works fine for hybrid
you just have a normal MB Component that links into a "mirrored" ECS entity
coarse turtle
oh wow they updated that blog post to say its dated ๐
coarse turtle
north bay
amber flicker
north bay
If they manage to break plastic ill be really mad
north bay
lol
trail burrow
deft stump
true
trail burrow
i'll take it ๐
deft stump
so along with their marketing team, their graphic designers are also rock solid
mint iron
looks worse to me, why is it square?
deft stump
I forgot 2019's splash screen
but it was baaad
2020 is a win for me, in splash screen deparment
trail burrow
2019
violet cosmos
VFX graph looks fun, I need to play with it but unfortunately doesn't work so great on mobile chips of when you're GPU bound
mint iron
ok yeah, i had blocked that from my memory, thats pretty bad
trail burrow
but yeah it should be widescreen also i agree
amber flicker
oh nice.. gluon and up to 3 users free... not too bad (https://unity.com/products/plastic-scm)
trail burrow
lol
mint iron
huh, first i've heard of plastic scm
coarse turtle
I just like the file locking feature when I used it briefly ๐ค
great for binary assets - git lfs also has that too since april
violet cosmos
Anyone tried a recent version of Unity Physics (as in, the last month or two). Are there any gotchas with it? Or, core deal breakers with expectations how a Physics API should work?
wheat stump
Can anyone tell difference between pure ECS and hybrid ECS
violet cosmos
@wheat stump Pure ECS is you creating all the entities and components and systems. Hybrid ECS is about serializing existing GameObjects and scenes. I would honestly say to avoid hybrid unless you really have very limited scope needs such as flat GameObject heirarchies and hand built scenes
wheat stump
Thanks @violet cosmos
trail burrow
hybrid is not useful for anything imho
either go full ecs and be ready to do a lot of shit by hand
or stick with go/mb and use jobs+burst for some math acceleration if you need it
wheat stump
Okay @trail burrow Thanks
trail burrow
but really, unless you have a game which REQUIRES ECS for whatever reason (can't really think of one outside of crazy demos like megacity) just stick to GO/MB
violet cosmos
If you need to build things, hybrid is jank
wheat stump
Yeah having fun with it
deft stump
reading the forum thread on bolt 2 being cancelled/pushed back.
wow...
that unity guy (I know he's a sr at the company) is being burned left and right
and his generic responses are only making it worst
trail burrow
yes god did you read their generic responses in the latest Q&A stuff?
on reddit/forums
"we are evaluating the benefits of various systems" and other generic shit phrases lol
deft stump
whenever a user is voicing out concerns (either aggressive OR passive). they just relegate back into talking corporate language
talk human ffs!
trail burrow
it's just... ugh
mint iron
they got burned pretty hard in the Visual Dots thread too; where i guess people liked the first version and then they changed it all to be basically the same as UE blueprints (and removed all the dots related parts - generating components/systems). people weren't happy.
deft stump
trying to play catch up is the fastest way to get left behind
mint iron
i think its an expectations thing, you sell a story, show them how it could be, then take it away and of course people are going to get upset.
if you said nothign at all then people would be chill because they dont know what theyre missing.
coarse turtle
yea - that's the same method that hello games did with no man's sky, overhyped, then stayed silent due to making a mistake, and rebounded by focusing on what current players who did enjoy the game wanted
deft stump
I'll still stick to unity and hoping in the next 2 years, I'll finally be able to properly migrate my simple game to dots
trail burrow
@mint iron they always do this
show amazing demos/examples/ideas
then just water it down
into uselessness
dull copper
they did clearly back from DOTS only future
like for the new netcode thing, they do GO support as well so people can actually use it
and now visual scripting via Bolt is one big change that they've done which was previously a big no-no as they moved their previously functional VS prototype to DOTS
I honestly don't get that one either
vagrant surge
@trail burrow couse the demos are allways one-off huge hacks
and then abandoned inmediately
dull copper
they already had somewhat equivalent of Bolt, then scrapped it, then bought Bolt and now try to make it look like the thing they had in the first place
trail burrow
@dull copper it's gonna be two netcode libraries tho aint it
one for dots one for go/mb
vagrant surge
@trail burrow more business for you
trail burrow
so, unity which has failed to deliver a working networking system in 10 years.... are now going to develop TWO working production ready systems at the same time? Color me ... skeptical lol.
deft stump
Geez, they should have stick with DOTS if they actually believed a DOTS only future.
But nope, we're gonna lose all our customers! We need to support MB too!
And now we have 2 engines mixing together into the same interface!
dull copper
@trail burrow First, this means expanding the focus beyond the Data-Oriented Technology Stack (DOTS) netcode space to solve for current-Unity GameObjects. Second, we are committed to delivering full-stack solutions for key genres by building alongside the incredible talent in the open source software (OSS) multiplayer community.
I read this so that they'd expand the current framework but you might be right, it's not very exact
if they do two backend solutions tho, that would be silly
and they clearly want to rent the servers
so, I'd expect some thin wrapper for monobehaviours for the current DOTS solution but maybe I'm just too optimistic
trail burrow
yeah i doubt that tbh
i mean, maybe?
let me re-phrase, they are going to build ONE networking system that in two different eco-systems?
dull copper
flawlessy ๐
trail burrow
When they failed to deliver a working one for the better part of a decade
dull copper
to be fair, wasn't unet kinda set into some sort of limbo after key people building it left Unity?
trail burrow
so their solution is to abandon whatever people worked on as soon as those people leave? ๐
dull copper
but that's kinda how it's been
it's not even just Unity, similar things have happened on the other engines
dull copper
wonder if Unity ever manages to revive the new GO char controller
they worked on it a lot initially, then dumped it to some other team and they wanted to redo it with simpler setup or something
it's like every new feat in Unity, has to be redone x times along the years before it can be released
altho they did semi-release a preview version of the char controller on git
that being said, I feel that what Unity is doing now for 2021 is very much needed thing
people blame Unity (especially old users) for things being unstable mess, if they manage to tie whole thing down into more cohesive package it's going to benefit all users
trail burrow
they've consistently failed to produce anything usable for 4 years now
engine is basically the same as it was 4 years ago
everything new is preview/broken/unusable
dull copper
so you support their 2021 plan?
trail burrow
what 2021 plan?
dull copper
to focus on stabilizing current feats and packages and not bring too much new into mix
trail burrow
i mean good luck but they've been doing one of these blog posts every year and they always missed their targets by a fucking mile and then some
Provide visual scripting integrated directly into the Unity Editor that is robust, stable, and production-ready.
Iterative improvement of the core experience for URP and stable HDRP. In the Asset Store, enabling users to discover URP and HDRP content easily through tagging and filtering.
Stable, supported, and extensible netcode foundation for current Unity (GameObjects).
Enhanced multiplayer games tooling support.
Core Product interop and stability improvements as above.```so their target for entire of 2021 is stable urp/hdrp and visual scripting?
lol wat
dull copper
and multiplayer
dull copper
we all know MP will take more than next year
trail burrow
like what
trail burrow
because they have what a 1000 engineers?
dull copper
if they keep adding more feats to the mix, it's always going to be what people say now to be a mess
trail burrow
Improvements specifically focused on quality of life, like reorderable arrays and lists in the inspector, improved inspector copy/paste, the ability to mark an object as โdefault parentโ in the Hierarchy, and a long list of improvements to existing features and toolsets.
reorderable arrays and lists in the inspector, improved inspector copy/paste, the ability to mark an object as โdefault parentโ in the Hierarchy, <--- THIS should not be MAJOR feature points, this should be a side notes in a changes list
deft stump
lel reorderable arrays has been in the experimental namespace for YEARS!
white crown
this should be in years ago xD
dull copper
well, you know how some things are close to impossible for them to implement
trail burrow
like how is this "major feature points for 2020 LTS"
dull copper
like, progressbar in their UI
I suggested them that when 2020 betas brought popup window for progress bar
trail burrow
i mean after 4 years of the engine standing still, and so many blog posts about what they are "going to do"
and all of it just falling flat
dull copper
their dev said it's like task that would take them 6+ months to implement
dull copper
progressbar in the main ui
basically the issue there was that the current framework isn't properly multithreaded
trail burrow
i mean i dont care much about progress bars in the editor ui
dull copper
I mean, I call that tech debt and would allocate people to fix that so it wouldn't chug everything down
trail burrow
thats a side thing
dull copper
I care about things that block me
UI should remain responsive
but they've done some progress on that too
vagrant surge
laughs in unreal engine 5
dull copper
it would be hilarious if they got functional ECS before Unity
trail burrow
i dont care much for the comparison between Unity and UE
its useless
they are tools, use the tool which supports your usecase the best
for me it's still Unity, because C# and decades of knowledge in/around it, etc.
but doesn't mean i am unhappy AF with the current way things are going
and if there was another well designed and popular C# game engine i'd jump ship in a split second
vagrant surge
ive just been checking for 3 years if i can use unity instead of unreal for a project (couse asset store spam and better workflow than reopening the engine to compile stuff in ue4)
not for the moment
deft stump
and if there was another well designed and popular C# game engine i'd jump ship in a split second
agreed.
I'm currently checking out monogame see what it can do
trail burrow
@deft stump i've tried most of the others (monogame, xenko, godot with C#, etc.)
it's just... meh
unity is still miles a head
dawn canyon
What are you unhappy about fholm?
trail burrow
well there u have it ยฏ_(ใ)_/ยฏ
dawn canyon
would you say though that it's the speed of updates that don't fit the proposed public timelines on features?
trail burrow
huh
solid flume
I wish Odin came with unity
deft stump
It's more like, unity can do better.
the people running it are probably not dumb.
but they just keep making bad decisions
uuugh
trail burrow
@dawn canyon but to, sum up:
- Engine has not moved an inch with new usable features since 2016 (and a lot of the stuff is now 'abandoned' even tho thousands of projects depend on it)
- Everything new is either experimental/preview/broken state, and can't be relied on
- DOTS has not moved far in the 3 years it's been out, you can still not use it for anything really
- Too many fancy tech demos (book of dead, mega city, dots sample) which when you look at them are just hacked together pieces of functionality that can't be re-used and then is abandoned by unity anyway
- Editor has gotten SO slow the past 2018-2019-2020 release it's almost unusable. Went back and opened a 5.6.7 project a month ago and the editor is insanely snappy and fast
tardy spoke
@deft stump pretty much universally a "person" can be smart, but for whatever reason "people" are always dumb and make weird decisions, hahah.
violet cosmos
This year is going to be another year of pain for Unity users. 2019 was just the start, and I don't think they'll solidify until this time next year at the soonest. They mentioned they were going to focus on soldifying existing features, and I honestly hope that means they quit trying to add in new things
They need to take a long hard lesson from how Adobe handled Flash. Where the focus on introducing so many features made it a buggy security hole, which lead to it's demise
trail burrow
It's just a joke at this point
violet cosmos
@trail burrow Believe me, I know. It's effected me directly in a number of ways, across a variety of systems
tardy spoke
@vagrant surge Haha the component spell system is a super great idea. Sounds like an awesome approach. Fireballs with a bounce component are always more awesome than just normal fireballs, hahaha.
mint iron
reminds me of borderlands weapons, they seem to just be able to mix and match affixes to give grenades all sorts of weird effects
violet cosmos
Sadly, I'd have that system done if I didn't peruse hybrid ECS the last two weeks ๐
I already have it setup in MonoBehaviour with SO's
tardy spoke
Wow, just watching Entitas videos... their syntax and workflow seems a lot simpler lol
I dunno what it's performance is like but it sure looks... easier.
trail burrow
idk why anyone would use entitas tbh, maybe for the organizational aspect? but meh
at that point just make something bespoke for ur game
tardy spoke
Does it have any performance benefits or anything?
mint iron
i think some people like the organizational aspect, and the 'reactive systems' approach
trail burrow
you'd use it for the architecture benfits (if you consider those to be valid)
not for perf benefits
tardy spoke
Yeah. I mean, I really like the ECS architecture currently, because I'm not super strong at OOP and my belief is it'll allow me to build a "bigger" game without stepping on my own toes as much because I've messed up the architecture.
trail burrow
@tardy spoke the architectural benefits of ECS are still up for debate
imho
it makes some stuff easier, but makes fine grained and complex game logic much harder, imho
tardy spoke
That doesn't surprise me haha
deft stump
makes fine grained and complex game logic much harder, imho
yeah this one is creeping up on me.
tardy spoke
Yeah, definitely.
trail burrow
this is why quantum never comitted to a 'pure' ecs model, and we use a blend of ecs/oop
tardy spoke
If I wasn't doing my own design specs I would likely shy away from it in that regard. Luckily most things where I'm like "that would be hard af to do in ECS" I just take out of the specs, hahaha.
trail burrow
i was never a fan of the pure ecs way of doing things
especially not one as simplified as the unity one, with all its restrictions
hollow sorrel
@trail burrow not related to the current convo but since you're here. there's one thing that boggles my mind about deterministic rollback
i assume rollback usually goes to max 8 frames or so to account for 250ms ping
let's say worst case scenario someone has a shitty pc and their sim tick takes 2ms to complete and is 60hz
this means they're already over the frame budget (8 * 2 = 16ms but then you also need to render)
what kind of sim tick times do photon quantum games have? are they all aiming for like 0.5ms even on crappy hardware or is there some other trick
trail burrow
@hollow sorrel lots of other tricks ๐
@hollow sorrel target for mobile is usually 0.5 seconds of rollback
hollow sorrel
woah
trail burrow
we're building a 120hz fighting game sample atm
with half a second of rollback
which is 60*60 frames per second
deft stump
we use a blend of ecs/oop
I'm watching this dev on yt.
he's using some very early prototype game engine.
but, looking at the code.
he rarely uses the ecs architecture other than mission critical parts of the game that needs the perfomance boost from being cache friendly
trail burrow
or 3600 fps
hollow sorrel
i can't imagine how that's possible ahah
i mean if it's just one spike you can pause and catch up
but if someone has a consistent high ping so you constantly need to resim then huh
hard to find resources about this sort of thing too
trail burrow
@hollow sorrel the fighting game is using a hard 3600 fps because its such a limited simulation
it can run at that speed w/o problem
quantum is fast enough to do that for small game state games
basically gives each tick something like 0.15ms budget or something i think?
fighting game is special tho
for more complex games we have a myriad of optimizations/strategies to let it run with huge rollbacks
dusky wind
Wait 3600 fps? 0.5 * 120 is 60...
trail burrow
@dusky wind 120/2 = 60, and then you have to do that 60 times per second, 60 * 60
for every rendered tick there's 60 ticks that need to be re-simed
deft stump
@trail burrow hahaha making my own fighting game here (it's an mmbn-inspired one).
- how is hard is it to make my own rollback netcode?
trail burrow
@deft stump hard
dusky wind
You can store 60 reference frames
deft stump
thanks for crushing my hopes and dreams
dusky wind
So you don't need to resimulate all of them...
trail burrow
https://youtu.be/IUyluTmmkPA?t=26 @deft stump demo of old old quantum fighting game sample
@dusky wind doesn't work like that
@deft stump top/bot on left side is p1 and p2, right side is p1/p2 interlaced with each other to see how accurate the prediction is
(hint: its almost seamless)
dusky wind
I literally wrote the port of GGPO to C#/Unity
trail burrow
@dusky wind congrats
hollow sorrel
for more complex games we have a myriad of optimizations/strategies to let it run with huge rollbacks
are these aimed at reducing the sim tick? or to still allow rollback despite high sim tick cost
trail burrow
@hollow sorrel ... both-ish
dusky wind
You can avoid this via simple state checksum tests.
trail burrow
@dusky wind ok, great
trail burrow
@deft stump 120 ping thats played with i think
hollow sorrel
i made a lil prototype with unity ecs but after adding Unity Physics with 1 collider and pretty much nothing else in game yet it's already hitting 1ms sim tick lmao
trail burrow
video recorded a long time ago
@hollow sorrel like, literally everything is custom to hit these rates:
- custom memory allocator
- custom task/threading system
- custom memory layout/ecs
- physics engine/animation system/navigation custom
hollow sorrel
yea i can imagine that
deft stump
wew. hahahah.
I'm into readymade solutions but hahaahaha I want to save money
trail burrow
espc the task system and memory allocator helped us
hollow sorrel
can you reveal some strategies for allowing rollback despite high sim cost
or is that all proprietary
trail burrow
to hit these rates
hollow sorrel
๐
trail burrow
@hollow sorrel all proprietary sorry :p
hollow sorrel
np
trail burrow
not trying to be coy, i will gladly talk about this
but i cant reveal how stuff is done internally
in public chat
hollow sorrel
yea that's understandable
hollow sorrel
simtick or just rendering?
trail burrow
sim ticks
hollow sorrel
damn
trail burrow
have to come up with some custom stuff just for that to i think to push it so far
hollow sorrel
i just got a 240hz monitor so now i'm trying to make sure everything i make hits that, but 240hz sim tick sounds crazy lmao
that's just 4ms
trail burrow
4.2 or w/e it is?
dull copper
you can do a ton of sim in that time
trail burrow
@dull copper yeah but not with half a second rollback
that gives you 120 ticks in 4.2ms
๐
or 0.035ms per tick
4.2/120
it's too little time
i've tried ๐
and u need to render and shit also
so realisticly it's half of 0.035ms if you want to render at 240hz also
giving rendering half the frame time
tardy spoke
I'm excited to test out SpatialOS for my game thingy. Maybe one day I'll be able to understand what you guys are talking about. I like the cool words you're using like "rollback" and "sim ticks".
dull copper
well, rendering is another thing ๐
trail burrow
i think with a custom setup i could probably hit 240hz for the fighting game
maybe
but it's faster than most peopls TVs are anyway, so goal is 120 for now
hollow sorrel
0.035ms won't even buy you the overhead from scheduling jobs with unity ecs
trail burrow
@hollow sorrel yup i know ๐
tardy spoke
Ahhh shit, my sim ticks are rolling back. Here we go again.
tardy spoke
@wheat stump looks like a hybrid approach?
Also that video is older, and the API's are different now, I would suggest picking a newer one if possible, haha
trail burrow
@hollow sorrel afaik the fighting game stuff uses 0.1ms per tick
wheat stump
Thanks @tardy spoke. Any links please
tardy spoke
Whole bunch there on that page!
wheat stump
Thanks
trail burrow
tick budget is 1000/120 = 8.33 * 0.75 (25% for rendering, 75% for sim) = 6.25 / 60 = 0.104ms
trail burrow
but this is absolutely worst case ofc, nobody playing fighting games with 500 ping
tardy spoke
That makes me happy to be working on an MMORPG where I believe the typical tick rate is actually approximately 10 per second?
trail burrow
MMORPG way harder than this lol
hollow sorrel
you wouldn't even need input delay if your simtick is so cheap right
tardy spoke
To do well, of course! To do very poorly... we'll find out. ๐
hollow sorrel
can just run right to the metal fulltime
trail burrow
@hollow sorrel no there's no input delay at all
@hollow sorrel we can also do partial tick simulation, so we can simulate say tick 100.4
and still stay deterministic
so it stays in lock-step with rendering
no input delay, no interpolation
trail burrow
ยฏ_(ใ)_/ยฏ
shit and giggles aside, that's all there is to it really just think about the problem over and over and over for waaay to long time.
@mint iron donnu have not used unity ecs for a long time
oh u removed it lol
hollow sorrel
inspirational
mint iron
sometimes i have to contain my snark ๐ฆ
trail burrow
we have invented so much custom stuff, data structures, physics broadphases, all kinds of shit for this
it's basically bespoke down to every nut and bolt
mint iron
very impressive!
deft stump
you're a wizard, fholm
dusky wind
I am very curious now
What did you mean by "custom threading solution"?
As in you made your own fiber/OS threads?
trail burrow
@dusky wind ... custom task system, like unity job system i should've been more exact in what i wrote my bad completely
dusky wind
I legit don't know of a threading solution with overhead that low.
Even for cases like high frequency trading
trail burrow
special made for our purpose
it's not a generic task system, but made specifically for our deterministic sim
dusky wind
Does it not go wide then? The overhead of scheduling onto multiple threads seems to be larger than your tick budget.
At least on consumer machines.
trail burrow
it's nothing special, just hand tuned/optimized for our very specific use case
im not building the fighting game stuff so i don't know if it's using the task system or not
i just now they hit their sim time target, don't have all the impl details (we're a big team)
dusky wind
I am also aware that Quantum uses fixed point determinism
trail burrow
Yes
dusky wind
But that also means you likely aren't using vectorization.
Unless you are explicitly using AVX256/512
trail burrow
Well we can't because we have to run inside of Unity, but we cant tie ourselves to Burst because that means we cant run outside of it also
also burst wont vectorize 64 bit int math anyway last i checked so
dusky wind
Yep
Mostly because 4 x 64 bit instructions are not commonplace enough in consumer hardware
trail burrow
We are not doing anything 'magic', just carefully implemented systems, hand optimized for our use cases, a lot of bespoke/custom stuff invented to hit said target, etc.
dusky wind
Or are limited by thermal throttling in cases like Intel's CPUs
Does that mean it isn't flexible enough for general use?
trail burrow
Depends on what you mean, it's not built for fighting games if that's what ur wondering
dusky wind
Or would it need to be hand tuned again for another use case
trail burrow
Our use case is 'predict/rollback simulation'
not 'fighting game'
fighting game is just a sample that's being built
dusky wind
Then are there any other benchmarks for it?
trail burrow
benchmarks against what? we have nothing to compare us against
trail burrow
i mean there's tons of launched games
dusky wind
And a good number of them I don't see hitting 3600 FPS 
vagrant surge
unreal is adding some new prediction stuff that does rollback. But given how unreal engine blueprint tick already takes 0.01 ms without doing literally anything ๐
trail burrow
@dusky wind and... your point?
vagrant surge
overwatch uses rollback networking
is relatively similar to ggpo fighting game networking, but for an FPS
dusky wind
My point is that is there a good example of these numbers in a release build
Or is the 3600 tick count a toy data point
trail burrow
@vagrant surge overwatch uses eventual consistency with client side prediction + rollback + corrections
not deterministic predict/rollback
@dusky wind no for a fighting game that is a real number, 120hz with 0.5 seconds of rollback, very real. Most games just don't need that level of update rate - so why would they target it? That's just a lot of work for no reason
most games are 30hz mobile games
trail burrow
yeah, with 8 ticks rollback i think?
vagrant surge
yup
trail burrow
which gives max ping of ~130ms before they start adding input latency
@dusky wind since you built GGPO port for C#/Unity, you know how this works - most fighting games would not let people play with 500ms, as it'd be insane to do such huge rollbacks, visually it'd look like shit even if it can do it performance wise. It's an internal performance target we set, to make sure there is enough head room. Last time i checked it does hit it, but it's all hand optimized code to make it that fast yes.
Makes sense?
Nobody going to let ppl play with 500ms and then jerk them back half a second in time to correct, when some actions take just a few frames.
dusky wind
As an library/asset developer, I can see the appeal of microoptimizing your systems for others to use.
deft stump
500ms of delay is brutal lol.
experienced that with many, MANY, arcsys games
minor sluice
oh, this conversation is great,
I might want to use the ggpo port for c# later too, already got an eye on your repo james ^^
My (at the moment abandoned project) was built with the truesync physics an a slightly altered implementation of the fixed point class from FixedMath.net. Basically shortly quit before doing the network communication steps, all systems needed to get ggpo to work, if it was used, should have been done (although I haven't tested it on multiple PCs yet)
btw, for quantum, is there a limit of how many resimulation frames of rollback you allow (in the framework and/or demo) per single logical frame, or is that entirely up to the user?
trail burrow
@dusky wind So like, if we hit that perf target (which we do, again last time i checkd) - when we have customers that build stuff on our samples, they are going to be adding even more stuff, which makes it slower most likely, etc. It's basically a way for us to say: this is our 'halo' product, this as far as you can push it on todays hardware, here you can build on this and do as you want, etc.
@minor sluice no limit, configurable you can set anything from 0 (lockstep) to 1000000
dusky wind
However, there's a reasonable tradeoff between performance and general flexibility, and this sort of flies in the face of reason for me.
minor sluice
your github stuff is really great james,
btw, how is development of fantasy crescendo going? I assume the intention was to use your gppo port for this game right?
trail burrow
@dusky wind well, there' no flexibility sacrificed for it really - we're just talking a bout a sample project for Quantum now, not quantum as a whole.
dusky wind
porting the core engine to ECS/DOTS
Just got deterministic rollback working for it as of two days ago
It's open source too if you want to dig into it.
I should probably slap a license on that repo though.
trail burrow
Like i said inside of quantum it's all custom, including the memory allocator the entire way down. All to facilitate making rollback and resims as fast as possible.
minor sluice
oh wow, haven't seen that, interesting!
Thanks!
Do you think a fighting game is a good fit for ecs? because it is easier to make a snapshot of the world state etc?
At the moment, it is still far easier for me to imagine fighting games with the regular approach.
dusky wind
It's great!
trail burrow
Some stuff is hand optimized even in the fighting sample i think, but most when i talk about the optimization it's stuff that's done in a general level for all of quantum
dusky wind
The use of multiple worlds has really made it easy
violet cosmos
@dusky wind How did you manage syncing addressables with ECS? I think we chatted about this the other day?
dusky wind
This uses the GGPO port I mentioned, but the code for creating snapshots is really simple.
trail burrow
@dusky wind how fast is that code to snapshot your game?
deft stump
Im interested in the hand made stuff in quantum to make it as fast as possible. realistic or not. can I get hired just to look at code?
minor sluice
oh, so you use one world to hold the previous confirmed (with all right inputs) game state and if there is a deviation, you just use this world and simulate it up?
also, how far is the ggpo port, is there anything you still want to do/fix or is it basically functional?
minor sluice
that's great!
dusky wind
It's a full memcpy of the world state
trail burrow
@dusky wind how big is that?
dusky wind
About 600 entities since I preallocate hitboxes
minor sluice
hmmhh, I haven't thought about that approach yet, but that seems like a good idea considering all components in the world are structs (and if they are pointers to immutable reference objects, should work too)
dusky wind
@violet cosmos I don't yet. I plan on having a SHA-2 hash of the loaded asset bundles which is included in matchmaking lobby parametsers to make sure that players are using the same assets.
violet cosmos
Well, I'm referring to synching ECS and GameObject that's being displayed
dusky wind
@trail burrow last I checked, 212KB/state when I used SerializeUtility.SerializeWorld
trail burrow
oh you're using unitys SerializeUtility.SerializeWorld ?
dusky wind
I was earlier
trail burrow
i didnt get that from the code
dusky wind
I'm no longer using it
trail burrow
oh
dusky wind
but that was the size of the world when I was using it.
Most of that is ECS's chunk overhead
I have a lot of archetypes with only a few entities
so a good portion is garbage data.
trail burrow
yeah we went for a different memory model that the archetype one
specifically due to this reason
dusky wind
It doesn't bother me though, it's more than sufficient for my use case.
trail burrow
most customers having lots of entities with varying component types on them
vagrant surge
@trail burrow what memory model, somethiong more similar to entt, or entitas?
trail burrow
@vagrant surge it's all native memory, closer to entt ye
to facilitiate fast remove/add of components
less fragmentation of memory chunks, etc.
vagrant surge
entt runs sparse sets, one per component, and then entity ID is used for indexing into those
trail burrow
yes we use sparse sets also
vagrant surge
entitas stores the components by the entity, but systems have lists of entities with matching comps
trail burrow
we debated this back and forth like crazy internally, and looked at what games were being built with quantum, etc.
spent probably two months
measuring and testing
various memory setups
before we comited to sparse-set model
vagrant surge
i also did a lot of experimenting. My end result was basically "sets has non-contiguous iteration (cant use simd), is worse for memory in large quantities, but its much faster to add/remove comps, and much faster in general than archetypes in small sizes"
trail burrow
yeah same conclusion we had
vagrant surge
if you have like...
trail burrow
and our use-cases match the two last points
minor sluice
by the way, I was wondering, how much more performant would entitas be compared to the regular monobehaviour approach,
because entitas operates on reference types right? so you get the architectural benefits of ecs, but I wonder how much faster it is
dusky wind
It's about the same
trail burrow
@minor sluice not much, give or take same
minor sluice
ah, good to know, thx.
minor sluice
guess it depends on the use case
vagrant surge
with tryharded flat ecs reaching 2 orders of magnitude
dusky wind
The overhead for MB requires C++ side allocation
Entitas is pure C# so it doesn't have that coupling/allocation
vagrant surge
the problem with MBs is the huge overheads of all the Update() calls and the "GetComponent<other>" to find the siblings
dusky wind
but it's memory layout is about the same
vagrant surge
in entitas thats much, much quicker
entitas is also designed around "reactive" systems
the idea with it is that most systems will only run once something they care about changes
so most of your systems will do nothing
until something happens, and it triggers a cascade of edits
for a vr music game i made on entitas (beat saber clone), i used 1 entity per note, and it was about 1000 notes on 1 ms
trail burrow
We're currently working on producing a full competitive grade FPS in quantum FWIW (sample), including lag compensated raycasts, etc. whole nine yards.
amber flicker
@vagrant surge & @trail burrow you think any chance the simd bit-backed .enabled states meaning you rarely need to change the archetypes are going to help breach some middle ground?
vagrant surge
running about 3-5 systems on those notes that would update velocity and timing on them
minor sluice
oh, sorry that I ask this again
but really wanted to know about that since you're here:
Is the base of backroll essentially finished, or are there still some missing features or additional features you want to implement?
vagrant surge
@amber flicker unity ecs can have per-chunk dirty flag, basically
dusky wind
I'm still on the fence
vagrant surge
so yeah its ok
dusky wind
I'm using the ECS port to test Backroll in production.
vagrant surge
the issue with unity ecs (and generally the chunk model), is that it really sucks for low entity counts due to all the empty chunks
trail burrow
We found that Unity ECS has too many edge-case issues to support back-rolls
for anything but simpler games (like fighting games, etc.)
it gets too complex to put your data into unity ecs
so it can be rolled back/forth
dusky wind
If it works out, I might try to factor out parts of it into Backroll itself @minor sluice
minor sluice
ah, excellent ๐
trail burrow
For something like a fighting game it's still fairly easy to produce just flat buffers of structs or w/e to house your state in
But for complex games with complex mechanics, lists, dictionaries, etc.
dusky wind
as like #define enabled optional code if Entities is also installed
trail burrow
unity ecs becomes a PITA when you try to rollback it
dusky wind
I haven't had any issues with it
vagrant surge
btw, making a entt style ECS using burst and dots would be fairly doable, as the "basic" model is really easy to implement
you only need nativelists
dusky wind
You just need to disable/manually tick the systems.
trail burrow
@dusky wind no i mean, like... just storing and saving the data
minor sluice
pretty great approach, so you leave the monobehaviour approach and the ecs approach in the same branches, and users can use whatever they like, with conditional ecs code compilation if they have entities installed?
trail burrow
as long as it fits strict into the entity-component model, fine
dusky wind
?
trail burrow
but the second the data doesn't
and you need to use collections, etc.
it becomes an absolute pain to deal with
in unitys ecs
dusky wind
I guess?
trail burrow
like if you can fit it all in entity+component+buffers or w/e its' called
dusky wind
I haven't had any issue fitting my data into it for my fighting game
trail burrow
and that works well for some types of games
like fighting games, yeah that would work well
dusky wind
@vagrant surge so I actually did that NativeList thing with my other library
I wrote this back in 2018
right after C# jobs came out, and before Unity Collections and ECS were a thing.
vagrant surge
lol, bullet hells are about the best use case for that sort of thing
vagrant surge
lol
trail burrow
https://github.com/fholm/unsafecollections here's all my native collections
dusky wind
Like @trail burrow has demonstrated, use case optimized solutions can be very powerful.
trail burrow
implements basically entire collection library from .net in native memory
dusky wind
I got about 120,000 bullets on screen on a Samsung Galaxy S3 at some point.
vagrant surge
@trail burrow an awesome resource
@dusky wind lmao
thats a lotta quads on a phone
tardy spoke
the idea with it is that most systems will only run once something they care about changes
How is a reactive system done in Unity ECS? What's the easiest way to manually tick systems based on events or something?
trail burrow
@tardy spoke they can do it on chunk-basis
vagrant surge
"reactive" system in ECS is chunk based
trail burrow
with chunk versioning
dusky wind
It was approaching GPU particle levels of efficiency. haha
vagrant surge
i implemented it on my own engine
works pretty well
you can also add a Dirty{bool isdirty} component if you really want the per-comp thing
dusky wind
@vagrant surge they were full Unity 2D sprites
vagrant surge
wow aht the fk
tardy spoke
Do you just disable it's update loop and call it manually or something from other systems, or what's the typical approach?
vagrant surge
i believe there is a semi automatic approach @tardy spoke
vagrant surge
reminds me of how godot chokes at 5k sprites on phones
couse it does 1 drawcall per sprite
tardy spoke
Would be good to get an example of manually ticked ECS "events" type system on the wiki
trail burrow
godot is nice and all, but performance its not one of its strong suits lol
tardy spoke
Because a lot of systems in a real project don't need the update loop constantly running
vagrant surge
i mean, i literally made its renderer 2.5x faster
overall
in like a week
for fun
XD
just fixing some absolutely hilarious dumb shit
violet cosmos
https://gamedevbrothers.com/events-in-unity-ecs/ - I linked to this in the wiki, a way of doing "events"
minor sluice
so for danmaku, you didn't need to implement something like manual DrawMeshInstanced (Indirect) calls to get the performance?
dusky wind
@minor sluice that's exactly what I did
minor sluice
ah, nice!
vagrant surge
tardy spoke
@violet cosmos Great, I can probably use some of this for my quest system and then extract it for a wiki example
vagrant surge
absolutely hilarious
hollow sorrel
oh i saw that too
vagrant surge
tho i will say i was being kind of an ass in the first message
deft stump
@vagrant surge good Now i have something to take my mind off hahaha
minor sluice
I am using a library for efficient 2d sprite rendering now too, and I was wondering it because it uses the same approach,
but that library is a bit of a hassle - to clean up entities from the drawing system when a world/scene is destroyed
vagrant surge
but absolute bests is stuff like
replace octree
with literally just a for loop
10x faster
dusky wind
oh man that thread
I'm surprised that Godot doesn't use spatial hashing
or at least a hilbert curve for that kind of stuff
vagrant surge
even the new vulkan 4.0 stuff still hasnt touched the octree
tho there are plans for it... eventually
too bad the vulkan abstraction they made is deeply flawed, so it will be a huge mistake
also fun stuff like "lambdas are banned, no excuses"
couse the dev doesnt want to learna bout them
dusky wind
@minor sluice so uhh, I used a shader that takes in a buffer of location, scale, and rotation.
The actual local to world matrix computation is actually done GPU side
vagrant surge
@dusky wind the factorio developers talk about exactly that
they have a friday blog about rewriting their sprite renderer
and finding whats the best way to batch everything
factorio easily renders 10k dynamic sprites or more when zoomed, its numbers are absolutely massive
dusky wind
I mean, when your aniamtions/sprites are all the same
I don't see why not
10k? I have had factories that eclipsed that easily.
Love that game so much, for both the games and developers themselves.
minor sluice
Damn, that's smart james ^^
I basically just use this library
https://github.com/fabriziospadaro/SpriteSheetRenderer
Another thing I was wondering:
Input prediction.
Seems like the most common approach to just assume that the input state is the same than the frame before for predicted input right? But is this usually the best solution or are their games that have very specific algorithms to how they predict inputs?
vagrant surge
found it
the factorio devs are incredible
that game really does data oriented stuff in practise
hollow sorrel
i've read posts about rendering 1mil sprites in unity ecs but they all assume you're just rendering the same set of sprites 10000 times
as soon as you have a bunch of different sprites with different animations then reaching 1mil is gonna be difficult
vagrant surge
reading the blog is amazing, they are incredibly next level
dusky wind
@minor sluice for the vast majority of cases, that's true, it's not like the player is going to be hammering the attack button 60 times a second.
Though I've been curious about trying a small LSTM ML model to try to get better prediction accuracy.
vagrant surge
It seems the best way to do point sprites is to use a constant buffer or texture buffer to pass point data to a vertex shader, and expand points into quads there. But at this time we already have all the optimizations mentioned in the first part, and the CPU part of rendering is now fast enough that we have put the point sprite idea on ice the for time being. Instead, the CPU will prepare 4 vertices per sprite with a total size of 80 bytes, and we will use a static index buffer to expand them to two triangles.
kinda the same issue i have with hybrid renderer, they assume most of your rendering will be the same mesh+material 10000 times
if you try to have 10000 different meshes performance is abysmal and they all get their own chunk mansion to live in
minor sluice
@ Scorr, I think it is easy as long as all the sprites you use are the same material/share the same sprite sheet
vagrant surge
factorio builds a few absolutely massive 4k x 4k atlasses
and everything has basically the same unlit shader, with some exceptions like trees, water, or particles
vagrant surge
@deft stump told you its straight hilarious
minor sluice
good question ^^
I noticed that in the library I use.. well you can just do the depth sorting of sprites with the actual z position of the passed matrix, (generally in unity)
so that makes sorting really quick and easy, so the z position can basically just be the y position (maybe with a multiplier if desired) to have proper y-axis based depth sorting
trail burrow
@hollow sorrel this is the entire problem with their ECS arch, they assume everyone wants to do the samet hing 10k times, and not 10k unique things
minor sluice
thx james,
Though I've been curious about trying a small LSTM ML model to try to get better prediction accuracy.
this does sound interesting,
would it be like: letting the ML model learn from the player behaviour/inputs and use that as a base to determine predictive inputs?
vagrant surge
i did some experiments precisely about it
when i was making my own unity style ecs
violet cosmos
or any unique things, just one. You have to load scenes to get preconverted entities
vagrant surge
what i did is to create a set of entities with a random set of 10 components
dusky wind
I was thinking it would be trained on the player's local matches
dusky wind
sent over the wire at the start of a match
vagrant surge
like, if you had 1024 archetypes and 1024 entities (worst case scenario), the performance of the ECS was kinda sad
dusky wind
and it would locally predict the player's inputs on the remote machines
vagrant surge
in those cases entt model was something like 10x faster
trail burrow
@vagrant surge yeah we did similar tests, for all kinds of breakdowns, yes archetype ECSes win when you're talking about 10s of ks
hollow sorrel
sounds about right
vagrant surge
im thinking of making a sparse set ECS for unreal engine, as i am using entt in my experiments, but the postmodern cpp17 of the lib gets in the way a bit
dusky wind
It's an idea I've floated for quite some time, but never got around to implementing it.
trail burrow
but it doesnt seem to win in the 'general case of a game'
vagrant surge
which is kind of a shame
the Conan Exiles dev did a talk about it on unreal dev fest
they made their own ECS, with their own job system
integrated into unreal
for fast stuff and high scalability
minor sluice
oh, so you get the model data of the opponent at match start, makes sense,
and that is used to evaluate predicted inputs of the opponent.
I wonder how this could be implemented practically.
while I probably won't go back to my fighting game for a while, your projects will certainly be a great help for my development too ^^ (whether it is using a library or just inspecting the code of one)
trail burrow
what mem model?
vagrant surge
it was a massive ripoff of entt
they didnt say the memory model
but they had exactly the same api as entt
just with unreal-ized names
trail burrow
ah
dusky wind
though thinking adversarially, if a bad faith actor were to send a faulty model.
vagrant surge
so i think its pretty clear they just did their ecs based on entt, but using stuff like TArray instead of std::vector
dusky wind
I'm not sure what would be best to do
I guess just discard the model if it's performing worse than dumb prediction.
vagrant surge
their job system stuff was unique tho. Entt doesnt have anything of the sort, its essentially a very fancy data structure
hollow sorrel
@dusky wind i could be wrong but i feel like anything ML in gamedev is gonna be abysmal performance in comparison to doing it the usual way
vagrant surge
@hollow sorrel keep in mind ML doesnt mean huge
you could create a markov chain or similar, trained at runtime
dusky wind
haha, my day job is optimizing ML models
vagrant surge
with barely a few neurons
vagrant surge
if you have some perceptron with something like 20 neurons it would even be overkill for a simple case like this
and that takes 0 to calculate
dusky wind
and it might be worth it if it dramatically reduces rollbacks.
minor sluice
it is just generally pretty impressive to me how well the simplest solution for the prediction works in most games,
I guess it also depends on how many startup frames each move has, how fast the move speeds are etc
hollow sorrel
wouldn't that be very inaccurate tho
vagrant surge
for example, did you know that Ryzen branch predictor does that?
its a mini neural net
with barely a few nodes
dusky wind
@hollow sorrel if it statistically is signifgantly worse than "dumb" prediction. It can be discarded and fallback to dumb prediction.
trail burrow
@vagrant surge the problem we always came back to with all ecs:es we looked at, is that none of them are optimized for predict/rollback, and you end up paying and arm and a leg for it. WHich is why we made our own, otherwise i'd gladly just ripped entt straight up or something
dusky wind
so dumb prediction becomes the accuracy floor.
vagrant surge
yeah, if you make your own, you can do some interesting stuff for saving the back state
minor sluice
it's also crazy how smash bros melee now has rollback netcode, also made by one guy over the course of like half a year (or maybe more)
I haven't tried it yet, but I sure will within the next few days or so
dusky wind
Project Slippy is... interesting.
trail burrow
@vagrant surge yeah, ecs is good like that you can adapt it to your needs
dusky wind
The rollback really has wonky effects on a GameCube game
vagrant surge
after all, the "core" concept is... very high level
it all just matters that Entity is some sort of lightweight key, components are stored... somewhere efficient, and systems iterate over sets of comps
how you implement it is up to you
and all the fun stuff you add to it
minor sluice
if someone made a proper testcase with prediction models and comes to the conclusion that plain stupid prediction performs better, that either means that,
- the prediction model could be improved
or - confirmation for other devs that it is best to just save the effort because the simple solution works so well
dusky wind
Melee at least
minor sluice
what are the specialties with project slippy and melee?
I haven't seen a lot, other than things like: prediction of roll tech when in reality it was a slideoff etc., but that is to be expected with rollback
dusky wind
Nintendo can't be assed
minor sluice
sadly nothing from nintendo themselves ^^
trail burrow
oh, not the official game?
minor sluice
nope
trail burrow
ah
dusky wind
They miiiight get DMCA'ed to hell for it. Nintendo can't have a bunch of fanbois making something better than them.
haha
minor sluice
I wonder if smash will ever have official rollback netcode,
it is much more expensive then plain delay based code but I think ultimate might be performant enough coded to handle it? not sure.
there is also this cultural thing in japan where many companies don't want to use products that were not made in house or in japan, for a long time this also concerned the use of netcode solutions (or still does)
dusky wind
It'd require Japan to have higher ping internally
minor sluice
I think if you're operating a business ,you should ignore that aspect in decision making though.
higher ping?
dusky wind
Delay based netcode works pretty well in Japan since their internet tends to be lower latency, at least within the country
So if your developers don't see a need for rollback...
minor sluice
ah I see,
yeah that makes sense,
so to consider other types of netcode according with the effort it requires, they would also need to strongly consider their global audience, and not just the japanese players,
someone recently told me that arc system works had a recent survey of desired features for their next game (haven't seen that myself but), the most voted thing was apparently rollback based netcode
dusky wind
That and they tend not to use data driven approaches to game development
No analytics means they aren't usually aware of the problems that affect player happiness.
minor sluice
iirc, netherrealm studios, in their 8 frames in 16ms talk mentioned that they spent about 8 man years to do their rollback solution for injustice etc. with around 1 - 1.5 actually being core development and the remaining time was just analytic tools and interpreting/evaluating the analytics and acting accordingly to it (bug fixes, choosing different approaches etc)
hollow sorrel
it's interesting so many people know what rollback netcode entails now and are fighting for devs to add it
before gamedev i would've never thought about those implementation details
yet the other day my friend who plays fighting games started explaining it to me (i didn't ask but it came up in convo) and how important it is for fighting games
minor sluice
I love how resources have gotten so plenty and available for all kinds of stuff,
I still think that implementing proper netcode can be hard (depending on your specific needs), but at least it is pretty accessible now and there are so many good free frameworks and solutions that you can use to help you.
what really impressed me was when dani (who makes Karlson) basically made some netcode close to state of the art for server authoritative realtime multiplayer games within 2 weeks for his game
hollow sorrel
@minor sluice ohyea i watched that one too, and in the end they got the new mk to ~0.5ms sim tick which is pretty much the only resource i could find when looking for how long sim ticks generally take in these games
very good talk
minor sluice
certainly, amazing talk.
I somewhere have a folder for rollback netcode resources and that was a pretty valuable one for them
also remember a blog post from a game called inversus
dusky wind
I still think that implementing proper netcode can be hard
It is, and always will be. I'm convinced there is no general solution to the problem.
trail burrow
there's quite a few fighting games being developed with quantum fwiw
donnu if any of them are in jap market tho
doubt it
dusky wind
It just happens that a lot of the talk/dev work has been closed source for quite some time.
minor sluice
by the way, are the quantum conditions for eligibility still the same of have they changed? last time it was really pricy on a year based subscription model, but you could bet a reduction or a free year if you developed some sort of a framework for quantum
dusky wind
Which has changed a bit with GGPO's MIT licensing.
trail burrow
@minor sluice yeah its 12k/year or 1k/month
however you wanna think about it ๐
idk if we do any of the free trial/etc. stuff anymore
too many customers to keep up
hollow sorrel
@trail burrow out of curiosity do you have anyone making offline games with quantum
who just take advantage of the determinism for other reasons like debugging
minor sluice
thx!
I'm sure it is a great solution, but I probably would want to go with something free or at least very minor priced.
I think for many really small indie games, that might not be worth the investment.
dusky wind
I personally find it easier to deal with direct code examples of rollback than general blog posts of how the architecture/paradigm works.
minor sluice
is there an option to self host quantum too or not? (I guess it wouldn't make that much sense when you can have the photon infrastructure, but just curious)
trail burrow
@hollow sorrel we have a few games which are 'offline' multiplayer which is the closest you can come
@minor sluice not at the moment no
dusky wind
And I'm sure plenty of other developers do too.
trail burrow
@minor sluice so the difference between something like GGPO and Quantum is that GGPO is 'just' the predict/rollback impl, nothing else... quantum has the rest of the 'game engine' needed to build a game: fully featured physics engines, navmesh implementation, AI frameworks, prefab systems, etc.
FWIW quantum is 150k loc
give or take
dusky wind
Holy shit
trail burrow
entire ecs model also, full collection library, etc.
so like, yes they 'do' the same thing at the core - but they are very different
dusky wind
Wait does Quantum support non-Unity games
trail burrow
yes
minor sluice
ah okay.
I like to use what unity offers, or c#, but one thing that really cost me time was the realization that I had to properly decouple the logic simulation from the visuals. So that's certainly one aspect to keep in mind when starting with such a game
in my game, which is a mess in terms of code organization, luckily there are only a few different types of entities,
so for a snapshot, it just has to store character state, projectile state and moving platform state. Although I was considering to use methods that evaluate the platform state based on full game time instead of deltaTime movements.
dusky wind
Ah that explains it
trail burrow
its not tied to unity at all
@dusky wind i mean not like you can use unitys physics, navmesh, etc. for deterministic games anyway
so you'd still need to rebuild it
dusky wind
Haha, at least Unity's built in physics engine
the new Unity Physics package for ECS is floating point deterministic
dull copper
for one platform
minor sluice
although if it is decoupled, it can make sense to have the logic layer just with c#, outside of the unity framework.
another question: how do you decouple visuals from logic in your games/frameworks?
hollow sorrel
Unity Physics should be deterministic across same architecture, even havok backend iirc
dusky wind
though comes with a hefty overhead
manic aurora
quantum bringing its own physics seems super cool, writing netcode over existing physics sucks
dusky wind
@dull copper yeah correct.
dull copper
burst cross-platform determinism is still a dream
dusky wind
Nope, I got it to work across multiple machines.
hollow sorrel
same platform
trail burrow
maybe it same platform
dusky wind
Same platform, not same machine.
trail burrow
we need full x-platform determinism
trail burrow
yeah
dusky wind
Though, I'm curious if we just sed s/float/f64/g the Unity Physics codebase...
trail burrow
osx vs windows wont be deterministic i think
dusky wind
dull copper
if it were that simple, Unity would have done it already
trail burrow
since they use different toolchains
dull copper
instead they keep postponing this year after another
minor sluice
for the visuals to data coupling
I think in my case, iirc, the current state was inspected and there was an mapping between data objects and visuals:
- if visual entity already exist, apply current data state to it
- if visual entity doesn't exist, spawn visual entity and apply state
- if there are left over visual entities that have no data representation anymore, despawn
dull copper
nah
trail burrow
we need full x86/arm and osx/win/linux/xbox one/xbox sx/switch/ps4/ps5/ios/android
determinism
minor sluice
I also have no idea how unity forces deterministic calculations with their math library when you use certain job/c# attributes
dull copper
if you use different compiler it gives you different result
dusky wind
Hmmm
dull copper
altho you'd really want to only use burst for deterministic part
but still, burst is not crossplatform deterministic today
minor sluice
olento, do you have any idea when the deterministic cross platform part might be usable? or an estimation?
like this would be amazing, but I really don't trust that, and it could still take a while
dull copper
no idea because Unity keeps postponing it
trail burrow
@dull copper we found that fixed point was faster than float when constrained to IEEE standard and all optimizations disabled in our tests we did