7
\$\begingroup\$

I'm in a bit of a dilemma regarding how certain engine components — like camera and UI — know who to follow, whose health and other attributes to represent on the screen.

How do you architect a system where does communication between those components and the entities take place? I could have a separate entity that represents the player, but that seems a bit 'hard-coded'. What if I want to pan the camera? What if the player starts controlling another entity?

In other words, how do I abstract away the data sources for components like the camera and UI, such that they don't care what entity they represent?

An event system will do for a lot of cases, but that is more suited for propagating information that changes or is generated 'rarely' (like the death of the player). For something like entity health and position — which need to be known every frame — an event system isn't well suited.

| improve this question | |
\$\endgroup\$
  • \$\begingroup\$ And does the camera receive input? Or the player character, or some abstract controller. So the camera follows player, whom is moved by the cinput controller? \$\endgroup\$ – deceleratedcaviar Sep 13 '11 at 22:21
10
\$\begingroup\$

The simplest solution would be to keep a member pointer to an object such as Camera.Target or UI.Subject that points to the player character but can be redirected to other objects (or set to NULL) when necessary.

If the player changes character, send an event to change the camera's target variable and the UI's subject. If you want to pan the camera, override the "target" behaviour and set it to a manual movement.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ +1 This is similar to what I use. I created an ITarget interface which just basically defines X/Y variables (my game is 2D). My Player class implements this interface and updates the values with their X/Y coordinates and then the Camera has a Target property of type ITarget. Each Update, the Camera checks if it has a Target and updates itself accordingly, otherwise it does something else (in my case, it's free and moves based on key presses, but you can do whatever you want). \$\endgroup\$ – Richard Marskell - Drackir Sep 13 '11 at 19:30
2
\$\begingroup\$

I find that the easiest way to do this is to simply not restrict myself to only having a single camera.

Instead, my game worlds are full of cameras, dozens or hundreds of them. Any potentially controllable character has a camera, any cutscene has a camera, often a single entity will have several different cameras for different player activities as well. (combat moves, idling, sprinting, etc). Each camera is given its target when it's created, and that target (as a general rule) remains constant for the lifetime of the camera.

The problem now becomes not "how does the camera know which character it's following", but "how does the renderer know which of the cameras in the scene it should actually be using for rendering right now". I use a camera manager class for that, which knows about all the cameras in the scene, and can blend from one to another, as instructed by events it receives from game logic.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Sounds a bit overkill? Could you not just define behaviour based on base types instead? (cutscene, head etc) \$\endgroup\$ – deceleratedcaviar Sep 14 '11 at 6:01
  • \$\begingroup\$ Don't get me wrong; the cameras do have standard behaviours. I'm not advocating separate implementations for every instance of a camera in the scene! It's just that having each potential camera exist as a separate instance in the scene is quite useful for blending, and for simplifying the number of types of camera events that need to be handled by the rest of the codebase. \$\endgroup\$ – Trevor Powell Sep 15 '11 at 1:55
0
\$\begingroup\$

Players are likely different enough from other objects or entities that they will have their own class. For many games it's perfectly legitimate to have one global player object that can be available throughout the engine and always represents the player, and any system that needs to know about the player can talk to that class. This can be cleaner and simpler than passing around a pointer everywhere.

If your game is multiplayer over a network, this can still make sense because there's a big difference between the local player and the remote ones. If you support local multiplayer with two controllers, then you'd need multiple player objects and concomitant pointer-passing.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.