dxv2k / SE102-intro-game-development

Course assignments and the final project will be a complete Super Mario 3
24 stars 9 forks source link

Design Pattern #2

Open dxv2k opened 4 years ago

dxv2k commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

image

dxv2k commented 4 years ago

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.