-
Notifications
You must be signed in to change notification settings - Fork 9
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
Comments
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. |
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) |
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 |
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.
The text was updated successfully, but these errors were encountered: