#Is there a networked DOTS FPS engine?

1 messages · Page 1 of 1 (latest)

opaque anchor
#

I'm hoping to get started with DOTS with something it should be really good for. Specifically:

  • The package would support networked replicated "physics" similar to Source Engine, interacting with a CSG style representation of the world geometry that supports mostly-naturalistic physical behavior.
  • The package would support non-networked Unity physics for clientside only cosmetic effects.
  • The server records game states and resolves causality and latency issues like two players shooting each other at the "same time" from their clients' point of view. This is maybe called "rollback."
quaint dock
#

that does pretty much describe dots netcode & physics

frozen marlin
#

NetCode also supports lag compensation out of the box.

opaque anchor
#

this looks like it isn't used by anyone 😦

brazen slate
#

What do you mean by that?

#

Are you judging this by lack of tutorials or something?

opaque anchor
# brazen slate Are you judging this by lack of tutorials or something?

it's organized under a character controller project, it's not upgraded to DOTS 1.0, it's not packaged to be consumed by other games, and it's deprecated on the asset store https://assetstore.unity.com/packages/tools/physics/deprecated-rival-dots-character-controller-for-unity-225129

(Deprecated) Rival - DOTS Character Controller for Unity | Physics ...

Get the (Deprecated) Rival - DOTS Character Controller for Unity package from Unity Technologies and speed up your game development process. Find this & other Physics options on the Unity Asset Store.

brazen slate
#

You don't add it via asset store anymore

opaque anchor
#

okay sorry that was

#

in the docs

#

this is helpful but it's like 10% of the problem

#

also it seems to use ordinary Unity.Physics

#

which afaik isn't aligned with FPS engineering traditions

brazen slate
#

I have no idea what that means 😅

#

How is the stateless nature of unity physics not ideal for a fps?

sullen temple
opaque anchor
opaque anchor
#

i'm not sure about fortnite & valorant

#

not physics in the sense of how naturalistic behavior is implemented

sullen temple
#

Can you elaborate on the differences, or on what would make unity.physics less well suited?

opaque anchor
#

i am really not an expert in this

#

so i'm the wrong person to ask

#

i know that hammer editor creates a file format and source engine has a data structure for that level geometry that is different than what i build in the unity editor, and afaik the way the source engine actors interact with the level geometry is "Really Important" for making games where you have to shoot things that turn around corners very quickly

#

maybe it isn't important

brazen slate
#

I'm still really unsure what feature you're suggesting physics is missing

opaque anchor
#

afaik, the format is important for something like limiting what information is sent to each player

opaque anchor
#

do you see what i am saying

brazen slate
#

No

opaque anchor
#

hmm

brazen slate
#

😅

opaque anchor
#

i don't think i'm being very ambiguous here and @sullen temple probably understands what i am saying.

brazen slate
#

I consider netcode basically designed for fps games

opaque anchor
#

yes but building a networked multiplayer fps... the least interesting part of the problem is the transport layer

#

and decisions like that

#

valorant was built on top of unreal engine (at the time) and that still took 7 years to make

quaint dock
#

netcode != transport; transport is com.unity.transport and yes it is not interesting

opaque anchor
#

hmm

sullen temple
#

I'm under the impression that the "limit what can be seen" thing would be a responsibility of your game code, and not of the physics engine

opaque anchor
#

do you see what i am saying

#

in the same way that building a linux headless server is easy, but orchestrating it on kubernetes correctly is hard. and unity doesn't release a helm chart to install "a scalable game backend." it sells that, even though they are materially commoditized

#

right now i see a dump of a project by 1 guy who i recognize as the developer of Rival and KCC

brazen slate
#

The graphics package actually has occlusion support as an experimental additional

#

You could probably use that tbh it's very fast for runtime occlusion

sullen temple
opaque anchor
#

like i said i will take what i can get

#

at least with regards to

rollback & prediction
rollback & prediction, and we really mean "resolving conflicts between clients in a competitive FPS multiplayer game", is tightly coupled to all of these missing features

#

that's why i keep talking about "traditions." because representing the level geometry in the same datastructure source engine uses allows it to support all of these complex features

#

at least, that's my assumption

#

i don't think anyone was like, "i'd prefer to use this complex thing instead of a bunch of collision meshes hanging out in my scene graph (unity)"

#

i assume they made these choices on purpose

#

so it's true, there's rollback and prediction in the sense of, character movement and rotation is simulated on the client

#

and maybe, it's impossible to tell at a glance, maybe there is conflict resolution for "i was shot by an opponent who popped a corner on his machine and i never got to see them due to inconsistency"

#

but doing stuff like that is tightly coupled to a bajillion things, so it's not like i can just go and iteratively increase the "responsibility of your game code". that is a physics problem @sullen temple but maybe i'm wrong and this is tedious.

#

it's like a physics and gameplay and ... it's an everything problem

#

it's all very tightly coupled

brazen slate
#

it has nothing to do with physics imo
everything you talk about is netcode responsibility

#

side note: doesn't csgo have a lot of wall hacks?

#

therefore it's not using relevancy to stop data being sent to players?

opaque anchor
# brazen slate therefore it's not using relevancy to stop data being sent to players?

i think the reason there are no moving platforms or even opaque doors in CSGO competitive rotation maps is that with a totally static scene in their physics implementation, it is extremely efficient to forecast player positions and visibility, considering latency, and send the "ghosts" (the replicated players) to their opponents who are most likely to actually wind up seeing them.

quaint dock
#

there is only 1 correct answer, and it's what happened on the server. whatever clients predicted is immediately thrown away upon receiving a new snapshot from the server

opaque anchor
brazen slate
#

as far as i'm aware, everything you've said in this thread is already solved and implemented in netcode

opaque anchor
#

hmm

quaint dock
#

what? yes it has?

#

it works great?

opaque anchor
quaint dock
#

i mean it took several years to be great

opaque anchor
#

afaik

brazen slate
#

atm netcode struggles at high latency simulations games

opaque anchor
#

or valorant

quaint dock
#

i have no idea about csgo

opaque anchor
#

i think valorant also copies csgo

#

which is why i say traditions

brazen slate
#

it excels at low latency twitch based fps or racing games

opaque anchor
#

it's not that it is or is not server authoritative. that's just an incomplete way to describe the problem

quaint dock
#

all i can tell you is that in com.unity.netcode, what i said is true, and there's no "wah wah this happened on my screen" ever

opaque anchor
#

"server authoritative;" "rollback & prediction" - these are bullet points in a features list. i don't know what words to use to describe CSGO's behavior, but

if my opponent, from his POV, rounds a corner, shoots me, then hides back
and the amount of time that that sequence of events takes place is less than the RTT between that player and me
depending on a threshold, CSGO gives me a chance to see that happen on my screen and shoot him back
and consequently, it's possible for that opponent to be less visible around a corner and get shot than he was actually visible when i saw him on my screen

opaque anchor
#

there IS wah wah this happened on my screen in CSGO

#

all the time. like that's the point of its approach to resolving conflicts

brazen slate
#

isn't it better to not have conflicts? ^^

quaint dock
#

i vaguely suspect this is called lag compensation and this package does it, but this is slightly beyond my knowledge

opaque anchor
#

it's server authoritative in the sense that the server is aware of how the conflict could have occured and makes a decision

opaque anchor
opaque anchor
#

the "package" (which is basically a whole game engine) would have to be aware of guns and corners and the velocity of the players (physics)

brazen slate
#

the whole rollback prediction loop is built in for you

opaque anchor
#

that's why i'm trying to say it's all tightly coupled

quaint dock
#

no, i don't think it does have to know that

opaque anchor
#

hmm

#

well i know a lot less about this than the people who made valorant, who went through this exercise, it would be worth consulting them

sullen temple
#

Your own game code would be informing netcode systems about velocities, guns, corners, etc...

opaque anchor
#

right, and i'm saying that's all extremely hard to do

brazen slate
#

netcode makes it really easy

sullen temple
#

Can't have the notion of "gun" built-into an all-purpose netcode solution

opaque anchor
#

and at a glance, knowing what little i know, things like the way physics work have to be different than what unity.physics is to support all those features

opaque anchor
#

i think you get it now

#

so an all purpose netcode solution isn't sufficient for making an FPS

brazen slate
#

you don't seem to understand how netcode works, can i suggest you just go use it for a bit?

quaint dock
#

this seems pretty made up to me

opaque anchor
#

i haven't seen the source for overwatch, which for all i know works totally differently, but supports a colossal game design space*

#

maybe that's how overwatch works

#

there are only a handful of truly robust networked FPSes than anyone plays.

#

like maybe less than 20?

#

CSGO is kind of a bad example because it doesn't have to support a big design space. TF2 supports a bigger design space. overwatch supports a really big one. i don't know how it works.

#

anyway it would be much more reassuring to see "here is a highly integrated approach to doing networked FPSes, and here are the limitations on the game design space" as opposed to "here are a bunch of decoupled pieces that don't solve the hard parts"

#

because that's what all the pre-existing fps engines look like that i can go and use. i can't use overwatch with my own assets, but i can use source and unreal

brazen slate
#

overwatch is famously built on ECS

#

one of the first big titles in modern times

opaque anchor
#

and overwatch, i bet, wasn't a folder dump made by 1 extremely talented guy

brazen slate
#

i don't know what you're implying by that ^_^'

opaque anchor
#

you know there is a huge, huge amount of product development between the online FPS sample and a working game

#

is it within the scope of any indie game developer? time will tell. i can certainly make an indie networked FPS using source engine as an indie. how innovative the gameplay can be, i don't know. less so for unreal. i can always make stuff in overwatch arcade, but that's not really the same thing

#

but like, if someone asked me to make a networked FPS prototype, i mean realistically i would be stymied by just hosting it right now

#

even if i didn't care about any of the other hard parts

#

i have no idea if i woul dhave the full flexibility of the design space of Unity.Physics and it would "Just Work"

#

i haven't seen any examples of that

#

i'm not even talking about memes like "it's a player character with a grappling hook". like if i made a destructible component (like rayfire) built on unity.physics, would it "just work" in the way the online fps sample is written? i have no idea

#

in regular game objects / physx world, the answer is "No." none of that stuff is networked "for free"

sullen temple
#

I think you're looking for a layer of tooling that would be built on top of Unity.Netcode and Unity.Physics (rather than built into these), and built for a rather specific subgenre of FPS

For example, a CSG tool that precomputes network visibilities would just be its own package, and would rely on Unity.Physics under the hood

opaque anchor
# sullen temple I think you're looking for a layer of tooling that would be built on top of Unit...

For example, a CSG tool that precomputes network visibilities would just be its own package, and would rely on Unity.Physics under the hood
yes. i would look for some existence of that representation of the game world for, "oh, this can be used for an FPS." i am confident that overwatch has such a thing in the way it's implemented, but i have never seen the source code, so maybe i'm wrong. i am not expecting to get the overwatch engine for free

#

that's like $100m of product development

#

like if i made a destructible component (like rayfire) built on unity.physics, would it "just work" in the way the online fps sample is written? i have no idea
this is probably more important to me as an indie developer

#

surely if i had no innovative gameplay to try, i would just use source engine

#

and i have no idea what the answer to this question is. it would be too good to be true

sullen temple
#

With today's cpu and bandwidth limitations, it would be very difficult to make a super easy esport-grade netcode solution.... unless that solution makes a ton of assumptions about what your game is

#

Which, I guess, is what you were originally asking for

opaque anchor
#

and it is not that limited. the #1 overwatch arcade game i think is parkour, which is what like 90% of people asking about FPS engineering want to do in unity

sullen temple
#

Well that's the "making tons of assumptions" part

opaque anchor
#

right now i am hearing there is like 3 years of product development until OnlineFPS can be used to easily prototype original FPS gameplay that an ordinary person can try in a networked environment

#

maybe it's really 1 year

brazen slate
#

(I'm out of the loop, what is OnlineFPS?)

opaque anchor
#

that's the name of that sample P.L. authored with Rival

opaque anchor
#

but just like, usable

brazen slate
#

If you knew what you were doing.
You could prototype a valorant quality networked fps game, in 2-4 weeks with netcode.
How do I know this? Because we did it in a week.

opaque anchor
#

could i write an X rayfire like destruction plugin for Unity.Physics, and it would just work in a networked way?

brazen slate
opaque anchor
#

hmm

brazen slate
#

I have a building destruction implementation in netcode

#

That i fracture using rayfire

opaque anchor
#

have you seen rayfire?

#

hmm

brazen slate
#

The unity rayfire plugin itself is very tied to gameobjects (last time I used it)

#

So doesn't play that nicely with entities/dots

#

My fractures are pre-computed so it doesn't matter

opaque anchor
#

yeah i'm supposing you'd rewrite rayfire from scratch

#

on your machine against unity.physics in a single player scene

#

and environment

#

and you test it and it works perfectly from that point of view

#

then, you drop it into, whatever, onlinefps

#

does it Just Work?

#

i don't know.

opaque anchor
brazen slate
#

yes

#

let me show you

opaque anchor
#

and they're really interactive and it's really fun

#

and if it were a local non-networked multiplayer game, it Just Works

brazen slate
#

this is just a random demo from me testing something specific

opaque anchor
#

that should work fine right?

sullen temple
#

With netcode you can have this in a day of development

opaque anchor
#

i think onlinefps can probably support that, but i don't know what scope of "physically naturalistically immersive" is supported.

sullen temple
#

Not sure what we mean by naturalistic though

opaque anchor
#

there's no such thing as a realistic* energy shield but it is a little natural*

#

lots of stuff in overwatch is extremely fun and not naturalistic

#

CSGO grenades aren't really AP Physics AB (Mechanics). like they do not behave "correctly" but they do behave naturalistically

#

that's why i am not saying "realistically"

#

i mean you guys make this stuff not me so i'm sure there is real vocabulary for all these distinctions

sullen temple
#

Whether you want momentum or not, that's just the responsibility of your character movement code. Both will work, and Netcode knows how to sync regular dynamic rigidbodies

opaque anchor
#

which again there are so many fixed traditions and it's been going on for so long, and devops technology has advanced so much that it is almost completely commoditized

#

like openmatchmaking was an attempt to do that.

#

but you could make a "kubernetes operator for your unity backend server image" and it Would Work

#

that doesn't exist yet

#

you could make "tekton manifests to automatically build your game's backend and deploy it to your server" - that's what TensorWorks is doing for Unreal - but i don't know if that does or does not exist

#

all of those things are ops problems that you need to run a game

#

if i have 8 players in my game, there is a colossal amount of ops between supporting 8 concurrent players and 9

#

nowadays you could dump the entire infrastructure for both deployment and development as a bunch of yaml files, and it would really Just Work for people

#

you're not going to do that but it is definitely essential to making an 8-player FPS that supports 9 concurrent players

frozen marlin
# opaque anchor "server authoritative;" "rollback & prediction" - these are bullet points in a f...

if my opponent, from his POV, rounds a corner, shoots me, then hides back
For reference, this is called "peekers advantage". The reason "Netcode for Entities" (com.unity.netcode) does not specifically solve peekers advantage is because it can be resolved in multiple ways.
I.e. It is a game-specific decision that you should make depending on your games multiplayer design, specifically regarding how you choose to:

  • Resolve and award kills. Example: Compare Halo, where "kill trading" is implemented as an explicitly supported mechanic, with a game like Call of Duty, which (in most cases) attempts to resolve combat to a single victor.
  • Handle animation & extrapolation of interpolated opponents. More aggressive extrapolation reduces peakers advantage, more interpolation gives a more visually cohesive (and latency tolerant) experience.

What netcode does provide is a way to handle one of the most common problems with hit detection, which is serverside compensatation for latency. I.e. "Lag compensation".

We could create an "opinionated" sample for a specific FPS sub-genre in the future.

opaque anchor
opaque anchor
#

i am being asked about this right by someone doing a pitch

#

for example, if i wanted to do weapons with zany found objects as ammunition - imagine loading a toaster gun cannon with chocolate - if i make that work single player using ordinary unity physics or some other well known testable single player constraints, would it Just Work multiplayer?

#

as a counterpoint, roblox promises something similar. but its rigidbodies are not simulated locally. so if you did e.g. rocket league (such a thing exists in roblox), when you hit the ball, there's 100-300ms of lag until the ball flies off

#

whereas when you see your opponents hit the ball, it seems to fly off immediately. does that make sense?

sullen temple
opaque anchor
#

is there a way to work in some kind of constraints where (1) if it looks correct in my single player testing, it will (2) look and work correctly in multiplayer?

#

this is the experience of building a Starcraft 2 Arcade game or Overwatch Workshop game

#

it sounds like the OnlineFPS sample does these specific ghost versus replicated decisions

#

and i would have to do that for every physics based mechanic in a way that is specific to the mechanic. there isn't some constrained physics system - like there is overwatch & source engine - that gives me decent networked physics for free

#

for free meaning, if it works single player, it looks and works correctly multiplayer

#

is that accurate?

#

@sullen temple sorry to mull this over to death

#

i'm just making sure i understand what you are saying

brazen slate
#

Unity physics pretty much gives you networked physics for free. That's not really where your work lies.

#

The difference between using and not using netcode is often small

#

I have a lot of libraries and convenience I write them all sp and then add netcode support

#

For most of them this can be as little as an extra system that runs on client as it might not need the full server simulation

#

After that it's really just authoring your data and determining what needs to be ghosted.

#

This is with the knowledge of how netcode works and I'll need to seperate my input and simulation

#

Honestly you're very obsessed with physics but it's the one area you really have to do nothing with by default in netcode

#

It just works

#

The one exception might be if you want to write a great feeling physics controller like Phil did with rival then you'll gave to wrangle it a bit

#

Good thing he's done the work for you!

#

But if you look at the physics netcode car demo the controller is only a few lines of code

#

And for most things that's how easy it is for physics

opaque anchor
opaque anchor
brazen slate
#

If you start a project, create a plane, put a bunch of balls in the scene and give them ghost components
you will have a beautiful, fully networked ball simulation

opaque anchor
#

rocket league is a good example of a physics innovations game. in your opinion, how challenging is that behavior to achieve with the current packages? like if i made the ball hit well and the player move well in single player, using unity.physics as exclusively as possible, and knowing some general rules like "keep it stateless," will multiplayer Just Work

brazen slate
#

If you write a 1 line input system, 1 line character movement system

#

you will have characters that can walk around and push these balls

#

while networked

#

Have you looked at the racing demo?

#

This is a physics based demo

opaque anchor
#

okay i think i have received enough advice on this topic i really appreciate it

#

my perspective comes from someone who already has a WYSIWYG approach to multiplayer - we just have a single unity instance and stream it to you, like stadia, but multiple players have distinct camera feeds. it's local multiplayer + distinct cameras. so you can play multiple users in your editor

#

i was investigating all of this because the one kind of game this doesn't work well for is an FPS

brazen slate
#

I will say that split screen multiplayer is a huge pain with entities at the moment

#

in theory it should be easy

#

but entities graphics only allows 1 instance of itself

#

if it worked per world then it would be super simple

#

i've basically given up on this

opaque anchor
#

here's an example of building a 4 player game in your editor with this technology

#

as you can see it's Rayfire and it Just Works

#

but also without the drudgery of ECS

brazen slate
#

yeah but this isn't using entities + entities renderer right?

opaque anchor
#

it's not split screen. it's using editor displays to visualize the different players

brazen slate
#

its a cool setup

opaque anchor
#

you could certainly do that, but there isn't a lot of ROI for that. the games are streamed and run on very powerful servers

#

you don't have to stress about efficiency

brazen slate
#

i actually had a system where i used only 1 game view and it split it per world dynamically

opaque anchor
brazen slate
opaque anchor
brazen slate
#

i'm hugely into tooling

opaque anchor
#

well that oreo game was made by 1 guy in 5 weeks

#

and it is essentially a bug free multiplayer game. he pushes to git, we build the unity binaries and deploy them on infrastructure for you

#

there's a lot of product development there, but it is definitely the best way to build small multiplayer games

#

a multiplayer FPS is bad to make on this sort of thing, but on the other hand, it's hard to make those in any case with a small budget

#

the game IS local multiplayer... but it's networked, because it is streamed. the players are indeed in different physical locations

#

and playing over a network... but you know, there isn't a bandwidth shortage.

brazen slate
#

interesting service (just reading the website)

opaque anchor
#

so that's why i'm so specific with these questions

#

like i think about this a lot

brazen slate
#

i really wish i could read the documentation without signing up ^_^'

opaque anchor
#

the racing example is serendipitous. even though there isn't much coupling between the vehicle simulation and netcode

opaque anchor
#

there aren't really any docs... it's literally 1 script

#

everything else is guided for you with warnings in your editor. the limitation is you have to use input system

#

and you can't use low budget glitchy built in render pipeline multi camera effects

#

the multiplayer drudgery is (1) local multiplayer specific stuff, like making two player objects (2) configuring two cinemachine brains (3) correctly using event system

#

it's not really specific to appmana. that's why this Makes Sense

#

my takeaway is that for networked FPS, my best bet is to wait

#

obviously ECS is the only way to do that

#

but it will take a huge amount of product development before it's a comparable design experience to other big engines

#

that's okay.

#

like we get these goodies for free, i'm not complaining

#

that said, for other games? ECS is a lot of drudgery.

#

@brazen slate for example, for vehicles. there's a lot of drudgery in the racing example for the vehicle sim. it's going to be buggy (in terms of UX), because nobody plays the sample, and the 1 person who authored it isn't Edy of Edy's Vehicle Physics

#

when i had to do an autos thing, i used EVP. i wanted to innovate in mobile driving controls. i didn't want to deal with the drudgery of writing a vehicle physics sim

brazen slate
#

Sorry too busy smashing someone at throwing cookies in a random mouth 😄

opaque anchor
#

lol

#

smashing a random canadian

#

the US campaign ended

#

ECS is a lot for me to learn...

brazen slate
#

ECS is confusing as hell for most users

#

I always say it's like a 6month journey

opaque anchor
#

i just can't imagine that the day to day grind at Blizzard HQ involves game designers writing systems

brazen slate
opaque anchor
#

besides, it's relayed. like for the sake of making it work on people's crappy internet

#

i haven't really done the basic networking tasks that geforce now has done

#

but it's comoditized

#

it just hasn't really mattered

brazen slate
#

feels like there must be a way to smooth or dampen it a bit

opaque anchor
#

we already tested with much higher latencies to see if it impacts things

brazen slate
#

i'm on australian internet so i don't know where i'm being served from

opaque anchor
#

in my opinion, i didn't want to even orbit around the car

#

lol

opaque anchor
#

actually that car was run for australians and used to be running out of AWS Sydney

brazen slate
#

very responsive just not that smooth

opaque anchor
#

hence the right side drive and kilometers

brazen slate
#

oh yeah didn't even notice

#

because that's natural to me

opaque anchor
#

i really don't want a Blueprints by Unity either

#

it would really hurt me in the meow meow if ECS is either the drudgery of writing a game engine from scratch in C++ for C# every day, or Visual Scripting

opaque anchor
#

@brazen slate the coda to this conversation is that even if unity.physics and netcode promises to solve all these problems for me, i still have to make builds, deploy backends and all this ops stuff to test it and find out if that's true, for every single kind of gameplay i develop

#

my takeaway is that right now ECS solves the problem of "how do we keep everyone in the unity ecosystem?" developing a networked multiplayer game entirely within the Unity editor, your OS, your own or their backend operations & devops, etc. that's a unity, inc. product problem, not a real problem.

#

meanwhile people have been writing their own backends & devops all this time and it has been fine and working. it takes a while but it isn't strictly speaking bad

#

idiosyncratically, an FPS backend shares almost everything with the client

#

i'm not saying much, but FPSes are hard to write... unless you are making them as a mod for an existing free game. in this respect, i think if i were to do this, i would stick with Unreal Editor for Fortnite. it solves the actual pain points afaik - audiences, devops, etc.

serene sedge
serene sedge
# opaque anchor https://www.dropbox.com/s/yy37mgv0xylu585/Editor%20Experience%204%20Player.mov?d...

I proto the exact same setup, it also work with entities but requires some changes. There is still also the pain when it comes to handle cameras, input etc etc on a per game-view basis.
Not to speak if you have a GameObject manager (or alike) that are written by the client, or cinemachine or timeline.
You need to construct your game around that specifically, instantianting these objects on per "player basis". So you game archicture should be designed for that specifically.

brazen slate
# serene sedge I prototyped that 1 weeks ago, could make it work on per world basis with very l...

I haven't tried recently (probably 0.51 was last time) but in OnCreate it used to have a static dictionary (of something I can't remember) that would be cleared and only populate the first time which broke everything.
Last I saw about this multiple BRG weren't supported so I just gave up on this.
But if you say it's possible now I definitely need to look at this again, it's been a huge 'dream' of mine to support this for workflow in our next project.

#

We've had huge annoyances for QA testing multiplayer in current project (-edit- should say we currently aren't using netcode, but are investigating it for next project) so being able to spin up and see multiple clients in editor is huge.
The other issue I remember for now is gameobjects if hybrid workflow is required as these don't get limited per world. If I spawn a light in 1 world, it's a challenge not to have it rendered in a camera from another world.

serene sedge
#

I can't say it will work without problem and I didn't check everything honestly (i.e creating other lights or gameobjec stuff at runtime).
In an hour or so at least I got this working

screenshot_2023-04-08_at_18.png
#

With the current BRG it is possible to do the some culling on per camera basis for each specific world. Indeed the setup in itself requires some changes to support all the "hybrid" cases.
A proper workflow requires a more structured approach. But I think you can try to hack around and see where you can go.

brazen slate
#

well i have a project for next weekend to investigate. I don't need a perfect solution as my use case is internal for testing and not builds, so this is really good to know.