Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Pattern #2

Open
dxv2k opened this issue Oct 21, 2020 · 4 comments
Open

Design Pattern #2

dxv2k opened this issue Oct 21, 2020 · 4 comments

Comments

@dxv2k
Copy link
Owner

dxv2k commented Oct 21, 2020

If you have a player state that needs to persist between different Scenes (such as player health or power-ups), then you may want to keep a list of players outside of the Scene, and just let the Scene borrow them as needed.

The diagram doesn't include any indication of what's in charge of drawing things. Presumably the actors draw themselves? but it doesn't point to the DX9 API part in any way

If you have Actor-driven sounds (such as sounds when the player jumps, lands, or attacks, or when an Enemy dies), then your Sound output system should probably not be so separate from the Enemies and Player. Also, there's no reason for SceneManager to know about the Sound stuff. In my engine, Sound is a bunch of static functions that are called by Components that handle sound.

Are Enemies and the Player fundamentally different enough to warrant being entirely separate? They both require collision, animation, and sounds. You could have a single Actor class, and the difference between the player and enemies is that Enemies' behavior is driven by a simple AI while the Player's behavior is driven by player inputs.

image

@dxv2k
Copy link
Owner Author

dxv2k commented Oct 21, 2020

Think about how input and drawing propagates through your engine. Input: the game window registers some input, and then needs to pass it down to the current scene through the SceneManager, and the Scene passes it down to the Player entity. Input probably can't be a part of SceneManager, because input comes from the game window, which probably belongs to the Game, not the SceneManager.
Drawing is similar - the Game decides where the game is to be drawn (probably the window, or perhaps some intermediate render texture), and passes that into the current scene, and the scene draws its Map, which draws the MapObject and then the Enemies and Player. The camera determines where on the screen everything is drawn.

@dxv2k
Copy link
Owner Author

dxv2k commented Oct 21, 2020

You need an explicit SceneManager. "Manager"s are rarely useful in practice. All the work it does can probably be done by the Game and the Scenes - the Game just needs to keep track of which scene is currently active, and to change the active scene when asked (e.g. if the player goes to the next map, or opens a menu)

@dxv2k
Copy link
Owner Author

dxv2k commented Oct 21, 2020

image

@dxv2k
Copy link
Owner Author

dxv2k commented Oct 22, 2020

Different Components communicate with each other using Events (different ones from the events the window emits for inputs, but the same idea). So for example, whena physics component detects that the player landed on the ground, it'll emit an event. The actor's Sound Component listens for that event and plays the "landed" sound when it happens. Animations can be updated similarly. The event system works using a Subject-Observer pattern, where Subjects emit events and Observers listen for them. A single object may be both a subject and an observer (e.g. an Animation Component might be an Observer reacting to physics events, while being the Subject of a Sound Component that reacts to new animations starting by playing sounds). Info on this pattern: http://gameprogrammingpatterns.com/observer.html
Different scenes also communicate with each other and other objects using this same system. The menus, for example, mostly just emit events, and it's the observing game or scene that does the actual work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant