next »

[tague]

Hey there,

I've been fooling around with engine design for a while (including an abandoned devlog on here about developing an ECS-based engine...) and one particular issue has always bugged me - the issue of making the camera and player special.

Obviously, the camera entity is special - there can only be one 'active' at any time, and that one has the special privilege of having its view rendered to the screen. And in the case of the player (especially in networked games!) the issue of making players special and tied to a particular user is puzzling. Of course, you could always just keep some pointer to the camera entity, but then more questions arise - how do you choose the initial camera entity if there are multiple in your scene, how should I handle switching cameras, what should my engine do if there's no camera in the scene, blah blah blah.

What approach would *you* take to dealing with entities that need to be 'special' in such a way?

[Schrompf]

Most of the time, I build a small structure outside of ECS that mainly consists of vec3 pos; mat3x3 rot; some_params params; EntityRefId carrier; This way you have to resolve at every frame to which, if any, thing the camera is attached to, and also verify that the entity still exists and is still the same as intended. So the answer to your last question would be: I'm not even doing it inside the ECS in the first place.

I mostly use some glorified ArrayIndex to address entities/objects/components, so in case of heavy load stuff might be deleted and the slot might be reused in the same frame. But for networking I also carry an InstanceIndex which is simply increased for every reuse of a memory slot, so I can additionally verify the InstanceIndex and be reasonably sure that I can detect if the camera's carrier entity is deleted.

I once tried to implement the "Camera Attached" behaviour as a ECS component, which works well, too. The thing is that there might be more than one of these, and you need to resolve the conflicts arising by this fact. And you probably want to preserve some of the "carrier-less" approach for cutscenes. It's somewhat inelegant to spawn an entity and some components only because your camera system requires a carrier entity.

Nowadays I'd probably go for the first option because I prefer code that operates at some specific data instead of the usual ObjectOrientation approach of implanting it inside the system. The carrier entity reference needs to be solved robustly, though. If your objects live somewhere on the heap, you have no way of noticing that it's gone. And the usual method of dealing with this - tracking references and cutting them in the destructor - is even more cumbersome than some proper entity reference class.

Choosing the initial camera is a design decision, not a code decision. I usually have a "start level" or "spawn player" script, and I can easily create/attach/declare the camera there while I'm already at it.

[Daid]

Obviously, the camera entity is special - there can only be one 'active' at any time, and that one has the special privilege of having its view rendered to the screen. And in the case of the player (especially in networked games!) the issue of making players special and tied to a particular user is puzzling. Of course, you could always just keep some pointer to the camera entity, but then more questions arise - how do you choose the initial camera entity if there are multiple in your scene, how should I handle switching cameras, what should my engine do if there's no camera in the scene, blah blah blah.

My home grown engine doesn't do "there is only one true camera". It supports multiple cameras, I even need multiple cameras. As I have multiple scenes, and for example the UI/HUD live in different scenes with different cameras. I can also setup multiple viewports.
So, I create 1 or more viewports (which take up the whole or a portion of the screen). Attach a one or more cameras to each viewport, and that decides what and where to render to and from. Any other camera just gets ignored.

The details are a bit more complex. But in general, it works really well. Things I've done with this are local hotseat split screen, or a spaceship game where you have multiple view angles on your ship at the same time.

Automatically searching for the first camera if you have none sounds useful at first, but will cause annoying problems later on. So I decided to require a bit more initial setup to have more flexibility and predictability.

[Schrompf]

Good suggestion! I remember setting up multiple "cameras" back in the Splitterwelten days. For example you could add an object to a "lake" entity which rendered a mirrored view of the current camera to a texture. Back in the days when screenspace reflections weren't as omnipresent as today. And I still think they're ugly. But I admit it's a simple catch-all solution to an otherwise difficult problem.

Other applications might include additional views in the HUD, like the view from a observer drone hovering at an elevated point, or a surveillance camera and display.