An observer defines a one-to-many dependency between objects so that when one object updates, anything attached to that object updates (and reacts to it) too automatically
Allows a reduce in the level of complexity - easier to look at, saves time etc.
Can set an event that tells everything that happens (eg a player dies), this saves manual checking as anything that needs to know about the player dying will automatically know
The observed class is also known as the subject
example syntax:
observable subject;
subject.addObserver(observer); //to add an observer
Performance - be aware there is some overheard for iterating through with observers
However, instead of checking continuously, something can be made to run Only when it sees an event to counter that
When an event plays, the thread pauses and observers update functions
Add observers during compile to reduce lag during runtime
Component Pattern
Allows a single entity to span multiple domains (aka systems) without having to couple those domains
('Multiple domains' can refer to rendering, update, input etc)
Each domain can become a component
For example, a gameobject knows it has multiple components, but it doesn't have to know what they actually do
These components don't have to be coupled together
There is no need for class hierarchy when using composition
(for reference, class hierarchy is this kind of thing):
These allow for flexible creation of new classes
Usually enemy classes for example are very similar so instead of multiple sub-classes, type can be used
Each enemy has a breed which holds its health, damage, etc
Behaviour can be read from a text file if the breed is complex, this would save coding space but isn't really necessary
No comments:
Post a Comment