I have begun approaching the area of Design Patterns in coding to understand how to utilise game design in live performance making, as a further progression of research up to this point, about which you can read in this blog.
I have come to realise, through a literary review of some design patterns, that even with the preexisting prototype work I have developed, there is a level of code happening within the relationship between performer, immersant and system.
In approaching design patterns in coding I have looked at Gamma, E, Helm, R, Johnson, R and Vlissides, J (1994). Design Patterns: Elements of Reusable Object-Oriented Software . Boston: Pearson Education. This text is considered by many the key source to use when analysing how we may use design patterns in software engineering. It is of note that the text does not refer specifically to digital game design, however due to game engines utilising the main coding language explored, C++, we can see value in exploring the insights these design patterns offer to us when coding in game engines or real spaces.
As stated, the design patterns were originally intended for use in game engine software, however on reflection before this, we could identify a way in which the current prototype already utilises a design pattern in an unconventional way.
The intent of the observer design pattern is as follows:
‘Define a one-to-many dependency between objects so that when one object changes state, all its dependants are notified and updated automatically.’ Gamma, E, Helm, R, Johnson, R and Vlissides, J (1994). Design Patterns: Elements of Reusable Object-Oriented Software . Boston: Pearson Education. p293.
The premise of this pattern, therefore, is relatively simple. An automated response to the changing state of an object within the code. In the prototype developed to this point, the immersant is the object on which other elements are dependent. The immersant is monitored and their changing state affects the coded script, as well as other mediated elements.
The immersant is therefore the ‘subject’, as described ‘knows its observers. Any number of Observer objects may observe a subject. Provides an interface for attaching and detaching Observer objects’. Gamma, E, Helm, R, Johnson, R and Vlissides, J (1994). Design Patterns: Elements of Reusable Object-Oriented Software . Boston: Pearson Education. p925. We can see from this, then, that any number of performers could be observers in this instance. We need not concern the idea of interface as a means for attaching observers, as we will explore.
Observer, conversely, ‘defines an updating interface for objects that should be notified of changes in a subject’ Gamma, E, Helm, R, Johnson, R and Vlissides, J (1994). Design Patterns: Elements of Reusable Object-Oriented Software . Boston: Pearson Education. p295. This could be understood as the monitoring of the subject (immersant) by the performer in the developed prototype.
There are also ConcreteSubject and ConcreteObserver objects which are utilised for automation. For example the ConcreteSubject object sends a notification to observers when changes occur in the subject. However in the example of the prototype used this has been interpreted differently, as the ConcreteSubject object could be seen as being like the use of the camera for monitoring of the immersant. This in turn informs the ConcreteObserver, which in the case of the prototype is also the performer. The ConcreteObserver ‘stores a state which should stay consistent with the subject’s.’ Gamma, E, Helm, R, Johnson, R and Vlissides, J (1994). Design Patterns: Elements of Reusable Object-Oriented Software . Boston: Pearson Education. p295. thus meaning that the performer is acting in this role as well as that of the Observer object, and regulates the coded script as well as other elements under the manipulation of the performer. This then, shows us that even on an unconscious level, a design pattern has been utilised to monitor and change elements in response to the immersant. Equally, the performer becomes two coded elements in one to accommodate the lack of automation, however this could be pursued in future projects.
In the next post, we will explore how the code for such an observer pattern is formed, and consider it reference for how the performer interprets information from the immersant.