Unified Patterns for Realtime Interactive Simulation in Games
Total Page：16
File Type：pdf, Size：1020Kb
Unified Patterns for Realtime Interactive Simulation in Games and Digital Storytelling Dieter Schmalstieg Graz University of Technology Abstract—This paper discusses the state of the art in realtime interactive simulation patterns, which are essential in the development of game engines, digital storytelling, and many other graphical applications. We show how currently popular patterns have evolved from equivalent, or, at least, very similar concepts, and are deeply related. We show that game engines do not need to choose a particular pattern, but can easily combine all desired properties with little or no overhead. Realtime interactive simulations, such as simulation should be flexible in accommodating computer games or cosimulations,1 typically use new entities and new tasks. entities and tasks as their building blocks. A Contemporary game engines, such as Uni- game world or other graphical environment is ty3D, favor the entity/component/system (ECS) populated by entities such as creatures or treas- pattern,2 which makes it easy to extend enti- ures. Many entities coexist, over longer periods ties and tasks independently. ECS decouples of time, and the digital narrative emerges as a entities and tasks, which is often seen as a consequence of their simulated interactions. major advantage over traditional object-ori- The challenge from a programming point of view ented programming techniques. However, it is scalability: We want to make it convenient for does not support communication between the programmer to express the desired simula- 3 entity groups. Mercury has recently shown tion in terms of entities and tasks, and the how Unity3D can be extended with group com- munication based on dataflow, but Mercury still requires to know communication patterns in advance. Figure 1. Relationship of the architectures (blue boxes) discussed in this article. Arrows denote the addition of a particular concept. In this article, we compare several popular register its interest with many subjects, and a communication patterns and show how the com- subject can receive interest from many observ- bination of ECS with dynamic group communica- ers. Moreover, multiple observers can be tion unifies all previously proposed patterns arranged in sequence, allowing indirect notifica- into a coherent whole (Figure 1). tion, provided that events are automatically for- warded to the next observer in the chain. The resulting structure is a dataflow graph (or pipes- NOTIFICATION and-filters pattern),5 a directed graph with enti- In object-oriented languages, entity types are ties as nodes and subject-observer relationships typically derived from an abstract base class, as edges. while tasks are implemented as entity methods. A naive dataflow schedules nodes in depth- Direct method invocations implies that the invok- first order, as with direct method invocations. ing entity must frequently poll the invoked entity Alternatively, a more sophisticated scheduling to learn about any new information. Polling is can interpret the nodes as states in a state wasteful, if there are many entities or infrequent machine. Notification starts at a source node and changes. Moreover, the schedule in which tasks is propagated based on state machine rules (see are carried out is bound to the invocation Figure 2). For example, breadth-first scheduling sequence. We could inadvertently trigger a deep would require that all nodes with a shorter dis- sequence of method invocations, starving more tance to the source must be processed first, urgent tasks. before a given node may be processed. More com- Consequently, we replace polling with noti- plex rules can impose arbitrary topological order- fication: Entities communicate by passing mes- ing on the notifications. For example, one may sages about events that happened in the require that a node has events pending on some simulated world. In order to receive events, an or all of its incoming connections. Such a flexible observer entity registers itself with a subject scheduling can be implemented using a visitor pat- 4 entity to receive notifications. Notification sepa- tern,4 an iterator which traverses a graph accord- rates event creation and consumption. Notifica- ing to a rule set and delivers notifications by tions can be delivered in a different order than invoking a virtual function on each visited node. the one in which the corresponding events Dataflow has been used in many interactive were created. This freedom of reordering notifi- applications. Visualization or image processing cations enables the development of a large vari- pipelines can be set up as dataflow,6 represe- ety of scheduling strategies, suiting the needs of nting filters, transformations, and encodings as diverse flavors of simulation. nodes. Input processing in virtual and augm- ented reality is often specified as dataflow,7 to DATAFLOW stream input from multiple sensors through fil- The observer pattern makes it easy to control ters, fuse operations, and apply geometric notification propagation. A single observer can transformations. Figure 2. (Top) Augmented reality in a folklore museum. Left: The visitor retrieves the flat iron for finding out the initials of the bridal pair; Middle: The visitor heats the iron in the tailor’s oven. Right: The visitor learns about the “wedding rider” custom. (Bottom) Finite state machine expressing the application logic of the folklore museum experience. A scene graph,8 a common data structure for a publish/subscribe architecture:5 Entities pub- visualization and games, can be interpreted as a lish to a notification channel, while other entities special case of dataflow (see Figure 3). The subscribe to this channel. The subscription can visual representation of a scene naturally lends be determined by explicitly associating entities itself to a hierarchical representation, with with channels, but a more powerful scheme nodes representing scene objects (triangles, tex- determines subscription based on dynamic fil- tures, shaders, etc.) or geometric transforma- tering of attributes, such as proximity. An inter- tions. A visitor traverses the nodes of the scene mediary object, the broker, collects events and graph, accumulates a transformaton matrix and delivers notifications. The broker can implement calls a rendering method on each node. arbitrary scheduling strategies and even provide persistent storage. PUBLISH/SUBSCRIBE When the broker collects and buffers many Dataflow supports indirect notification, but events from many entities, temporal ordering still requires explicitly setting up the links of events becomes essential. Proper temporal between entities to send notifications between ordering requires that notifications for events entities. Setting up links for static relationships is are delivered in the half-order induced on the easy, but, if entities act autonomously, associa- events’ time-stamps. tions change in dynamic, unpredictable patterns. In such cases, we would like to specify enti- MODEL/VIEW/CONTROLLER ties to be notified by filtering attributes or speci- If event processing and rendering are cou- fying interests, rather than by enumerating pled together in the same loop, either one of entities directly. Instead of a visitor, we need the two tasks can become a bottleneck. Figure 3. Flow visualization around a space shuttle (left) is modeled as a hybrid of scene graph (middle) and a dataflow graph (right). Simulations should, therefore, incorporate a node to node during visitation, a conventional 9 decoupled simulation pattern that assigns sep- visitor cannot be used. Such a case requires 10 arate threads of control to concurrent tasks. double dispatch, the ability to vary both entity In a decoupled simulation, a broker may place and task dependent on the use case. There are its event queues in shared memory, accepting several ways how double dispatch can be events from entities belonging to one thread implemented: and notifying entities belonging to another thread. Provided we use a strictly asynchro- Multiple inheritance can support double dis- nous scheduling, where no return notifications patch to some degree, but can lead to compe- are required, each task may iterate over the tition among inherited implementations (“deadly diamond of death”). received notifications at its own pace, without blocking other tasks. Reflection can extract a method signature In a simple architecture, a main thread may from events and invoke a corresponding be responsible for brokering events, while other, method. Reflection can either be natively sup- secondary threads are spawned on demand for ported by the language (e.g., C#) or emulated compute-intensive activities and retire after they by parsing a textual event representation. have fulfilled their goal. In a more complex archi- Using reflection is generally considered too costly for processing large amounts of events. tecture, multiple threads may permanently tend to activities such as rendering, AI, animation, A signal/slot pattern can be used, which physics, and so on. allows registering methods of the notified The model/view/controller (MVC) pattern5 object to a particular signal (event). If the describes a common form of decoupled simula- programming language does not support a tion. The model is a common store for the enti- signal/slot construct, it can be implemented ties, while controller and view are tasks by using templates or building a table of func- tion pointers. observing of the model. The view is responsible for rendering, while the controller is responsible The VIGO (views/instruments/governors/obj-