An Aspect-Oriented Approach to Video Game Commentary Chris Lewis

1.

INTRODUCTION

This paper describes a novel approach to implementing a commentary engine for a video game, utilizing aspect-oriented programming to monitor game events. A commentator can be thought of as a “cross-cutting concern”, requiring the monitoring of several different elements of a game’s architecture. Aspect-oriented programming (AOP) has been widely discussed in programming languages circles for many years now. The most famous implementation of aspect-oriented programming is arguably AspectJ [6], released in 2001. Despite being available for many years, aspect-oriented programming appears to not have reached wide market penetration, and there is little work assessing its impact. Forrester Research even warns that “aspect-oriented programming considered harmful” [12]. This paper is an investigation into maturity and applicability of AOP. It is applied to the novel area of commentary engines to better understand its strengths and weaknesses. As well as using AOP to create a commentator engine, I also will look at why AOP is not well-suited to the separation of concern in regards to data storage and retrieval, with an aborted attempt to craft a database aspect to store the statistics gathered by the commentator engine.

2.

RELATED WORK

Aspect-oriented programming was introduced by Kiczales et al. (1997) [7], but it was not until the release of AspectJ (2001) [6] that aspect-oriented programming took off. At the same time, case studies were beginning to appear, investigating whether AOP was working to aid software development. Murphy et al. (2001) noted that aspect-oriented programming required exposed join points, worked best when the aspect was narrow (has a well-defined effect) and unidirectional (aspect refers to the code, but not vice versa), and that aspects can be used to inject separate object-oriented structures into base code [10]. Papapetrou and Papadopou-

los (2004) was a later attempt at evaluating AOP versus object-oriented programming (OOP) in a “real setting” [11]. Papapetrou and Papadopoulos concluded their work found largely the same results as similar case studies. They found that the number of lines of code between the two were similar. Speed and stability were equal across the paradigms. However, AOP sped up development and produced cleaner, more modularized code. They used AOP to log execution or pause functionality, but did not attempt to inject data into the program. Investigations into aspect-oriented programming in the video game space have largely revolved around how the variability offered by aspects could be used to implement games on mobile devices, which have a large number of possible hardware configurations [8, 3]. These publications focus on using AOP to aid variability, rather than readability, by modularizing cross-cutting concerns. The Jiazzi project [9] is a tangential work designed to support AOP, rather than utilize it directly. Jiazzi uses a series of units, small amounts of program code that are linked together and can be used across different classes. McDirmid and Hsieh built a maze game to illustrate Jiazzi’s ability, using units to change the functionality of in-game objects without modifying the original source code.

3. METHODOLOGY 3.1 Tag Game I chose to implement a commentator for John Funge’s opensource Tag Game [4]. Tag Game is used as a teaching aid in Funge’s Game AI class taught at University of California, Santa Cruz. Tag Game consists of four Non-Player Character (NPC) “circles”, and one player circle. NPCs move around the game world, navigating past obstacles (white circles) and trying to avoid being tagged by the tagged character. When a character is tagged, the tagger becomes a normal evading NPC. The game has no time or score limit, and continues infinitely. Tag Game was chosen as it provides a fully-realized game, small enough to be easily understood and adapted, but large enough to properly illustrate various game AI concepts. It is the activities of the player and NPCs that provide the points of interest for the commentator engine. As the possible event space is constrained, it is straightforward to construct a commentator that can comment on all the actions in the game. Achieving full coverage of the game should

perform the same task. SpringPython is also limited in the hands-off approach that is prioritized by AOP. Whereas AspectJ is able to function without ever modifying the original code, SpringPython requires the editing of the original object instantiation in order to wrap the object, as shown in Listing 3.

3.3

Aspect design

3.3.1

Event monitoring

The commentator engine is a cross-cutting concern, as it is interested in events at multiple levels from multiple perspectives. It is easiest to visualize the commentator as being situated high above the game world, able to observe all that happens in the game. One can think of the commentator as being omnipresent, and thus there is no concept of “cheating” and observing something that it cannot (unlike if the output was supposed to be chatter from an NPC, for example).

Figure 1: A screenshot of Tag Game. NPCs in this version have been colored so that they are distinct from one another. ensure that the commentator can be treated as a representative implementation, showing AOPs applicability to larger games. Tag Game is available in C++ and Python. Python was chosen as the development platform in order to accelerate development time, and allow me to gain some familiarity with the popular PyGame [1] framework.

3.2

Aspect-oriented programming tools

Unlike Java’s AspectJ, Python does not have a widely used, popular aspect-oriented module. Evaluating which module to use proved difficult, with little commentary on the web as to the strengths and weaknesses of each module. I eventually chose to use SpringPython [2], a port of the Spring Framework for Java. I consider the Spring Framework to be mature, as Amazon.com lists over 15 separate books dedicated to the subject at the time of writing. With such a heritage, I believed that SpringPython’s aspect-oriented module would also prove to be stable. SpringPython’s AOP implementation differs from AspectJ by only providing the ability to wrap entire methods, and all calls move through a central “invocation method.” It is up to the user to perform a switch statement inside the invocation method to decide which method was called, and what to do with it. Methods are also wrapped entirely; you cannot explicitly specify execution before or after a method. The method that has been wrapped is then executed at the discretion of the aspect. This can simulate execution before or after a method. While neither issue reduces the power of SpringPython, the readability of code is significantly worsened, as illustrated in Listing 1 vs Listing 2, which both

The commentator is wrapped around both the game state object, and each character object. The game state object maintains a list of obstacles, a list of characters, who is currently tagged and other statistics at the game-wide level. The AI for each character is not allowed to directly query the game state, and must instead build up its own perception of the game world. However, the commentator has no such limitations, and so observes both changes to the game world and changes to the characters themselves. It is not possible to just wrap around the game state, leaving the characters untouched. While the game state stores a list of references to every character in the game, it is not possible to request SpringPython to fire an invocation when events occur in non-wrapped objects, so it would not be possible to observe changes to the characters themselves as they happen. One could monitor the method that updates each frame method in the game state, but there would be a large overhead in calling the wrapper object so frequently. The wrapper object would also need to maintain its own copies of past states in order to ascertain that something has changed. For this domain, the number of events that need to be observed to create a useful commentator is small. It would be interesting to watch: • Tags* • Speed* • Time to tag* • Time avoiding tag • Time tagged • Near misses * indicates monitoring implemented in the final product

Listing 1: AspectJ vs. SpringPython readability. This is SpringPython. def i n v o k e ( s e l f , i n v o c a t i o n ) : c a l l e d m e t h o d = i n v o c a t i o n . method name arguments = i n v o c a t i o n . a r g s i f c a l l e d m e t h o d == ”setTagged ” : % Do something ... % Execute t h e wrapped method r e s u l t s = invocation . proceed ( ) return r e s u l t s

Listing 2: AspectJ vs. SpringPython readability. This is AspectJ. a f t e r ( C h a r a c t e r c ) : t a r g e t ( c ) && e x e c u t i o n ( void setTagged ( ) ) { # Do something ... }

The important distinction between these events is which object knows enough about the event. Tags are monitored by the game state wrapper, as the game state arguments to setTagged have both the tagger and the tagged character in them, reducing probing to access the necessary data. This is simpler than probing a character, and maintaining state in the aspect as to who was tagged last.

4.

That said, the aspect is required to maintain many state variables in order to make interesting conclusions as to what is happening in the game. Timers, for example, require new class variables to save the starting times.

4.1

3.3.2

Persistent storage

The commentator engine was designed to store statistics across multiple play sessions, with the aim to build a “personality” for each NPC. The commentator could then retrieve these statistics and use them to comment on, say, the average speed of the NPC, or whether the NPC tends to tag back more often than others. Working with persistent storage appears to not be a necessary aspect of the commentator’s function; it simply has to output relevant comments (via printed statements or a text-to-speech engine) as the game runs. Whether statistics it harvests are saved looks to be a code tangling issue, as does retrieval of those statistics for comments. If those statistics aren’t available, the commentator should be able to continue functioning regardless. With this in mind, a separate singleton aspect was designed to save the statistics being collected into a database. The database stores information like the average speed, as well as the number of samples taken in order to correctly weight future calculations, who tagged who, how long it took to make the tag, and so on. As the aspect is a singleton, the database connection isn’t accidentally made twice.

EVALUATION

In the introduction, I mentioned that this project takes a wide-ranging look at what is possible with aspect-orientation and why take up has been slow. In this section, I will list the benefits and weaknesses experienced using AOP to implement the design listed in Section 3, citing examples from the finished commentator product.

Level of Maturity

My first forays into aspect-oriented programming using SpringPython involved wrapping the Character objects, illustrated in Listing 4. Despite the simplicity, and in my mind, intuitiveness, of this statement, SpringPython failed to properly wrap this code, instead forwarding method calls to the wrong objects. Because the aspect-orientation served to mask the underlying object, it was very difficult from the programmer’s point-ofview to understand that this was what was happening. It was only by contacting the original author of SpringPython was it identified that it was not working correctly when calling intercepted methods inside intercepted methods (as seen in line 2 of the code). Fortunately, this was fixed in an expedient fashion. Later on in the development of the commentator, I attempted to wrap the commentator aspect in the database aspect, which also failed. While this functionality makes intuitive sense, in practice it was outside of the design scope of the SpringPython AOP module, and the author did not plan any new work to implement this feature. AspectJ does have the ability to apply advice to an aspect, so this is not a unknown feature as part of AOP. One can derive two possible conclusions from this experience of having seemingly basic functionality not working in

Listing 3: Wrapping an object in SpringPython. % Original c a l l GameState g s = GameState ( ) % Wrapped c a l l t o monitor t h e setTagged ( ) method p o i n t c u t A d v i s o r = RegexpMethodPointcutAdvisor ( \ a d v i c e = [ s e l f . g a m e s t a t e a d v i s o r ] , p a t t e r n s = [ ” . ∗ setTagged . ∗ ” ] ) GameState g s = ProxyFactoryObject ( t a r g e t = GameState ( ) , i n t e r c e p t o r s = p o i n t c u t A d v i s o r )

Listing 4: Wrapping the Character object. c = ProxyFactoryComponent ( t a r g e t = C h a r a c t e r ( C i r c l e ( C o n s t a n t s . r a d i u s ) , b r a i n ) , \ i n t e r c e p t o r s = tagAdvisor ) c . s e t P o s i t i o n ( vec . randomVec1 ( g s . worldDim , c . g e t P o s i t i o n ( ) , tmp ) )

a popular Python module: • that people are not using the aspect-orientation, and shallow bugs that have somehow missed the developers are not being spotted. • that the developers themselves are not using the aspectorientation, so not spotting shallow bugs. This seems likely, as some of the deficiencies identified with the syntax in Section 3.2 may well have been rectified if the developer wished to “scratch the itch.” • that people have attempted to use the module, found it to not work, and not reported bugs to the developer. These are not mutually exclusive and any one of them bodes ill for the take up of aspect-oriented programming outside of Java. In particular, if people are having initial bad experiences, it is likely that they will not return, and their perception of aspect-orientated programming across all platforms may be tarnished. With all that said, once the original problem was solved, I have found the SpringPython module functional and useful. I imagine that wrapping an aspect with another aspect is an esoteric piece of functionality, and it is understandable that the developer does not wish to work on it. SpringPython is relatively new (beginning in December 2006) and takes into account many other areas of functionality. It will be up to the Python aspect-oriented community to produce a product that goes someway to being as strong as the powerhouse that is AspectJ.

4.2 4.2.1

Adding features Commentator

The commentator aspect is actually not far removed from a cross-cutting logger. The aspect monitors various events, retrieves data about those events, stores the data, then formulates some output based on the event. I was expecting that this similarity should show significant gains over a traditional design, and this proved to be the case. Instead of code muddied by calls to a commentator, the original code

was able to be left untouched (bar the object wrapping required by SpringPython). It is perhaps surprising, when such easy gains are offered, that uptake from developers has been slow. I would speculate that cross-cutting areas such as logging are seen as necessary evils, rather than part of program design, and so are not given the scrutiny they require during the design phase of the project. With proper use of functions, plenty of join points are offered that will allow observation of much of the program’s execution. With aspects working so well in this area, I find it almost unimaginable to undertake a larger project without employing a logging aspect to provide insight into how the program is executing, without obstructing the readability of the core logic.

4.2.2

Database

Throughout my experiences with aspect-oriented programming, it has been hard to shake the feeling that aspectorientation is little more than the observer design pattern [5] repackaged into a different syntax. I embarked on this project hoping that there would be some element of aspectorientation that I wasn’t seeing; some form of useful functionality where I could take the “separation of concerns” to a new level. My hope was to create objects that were entirely agnostic as to other features layered on top of them. This functionality would be implemented in a plug-in style, but without the need for explicit hooks to be created (delegation, for example, requires explicit hooks). I intended to write the commentary engine, and then write a database aspect that wrapped around it, storing and retrieving statistics, with the commentary engine code remaining untouched. While leaving the code untouched would not be possible with SpringPython under any circumstances (as all objects have to be wrapped at the time of instantiation in the base code), this might be possible in other AOP implementations. The agnostic commentator would be an example of a syntactical elegance so far removed from the observer pattern that one could feel that there were significant benefits in AOP, outside of alleviating cross-cutting concerns.

While the database aspect proved difficult to unworkable due to the wrapping of an aspect problem described in Section 4.1, thought experiments proved that actually, such an implementation is also undesirable. It is relatively simple to construct an aspect that observes statistics. The only design decision to make is if a certain feature is not available in the base code (such as the current speed of a character, which is not implemented in Tag Game), is whether to modify the original code to begin calculating this feature, or to have the aspect start building a concept of the state in order to save the data. It is the retrieval of data that causes the biggest difficulty, and it is here that I was looking for hidden benefits in aspect-oriented programming. The problem posed is actually achievable as long as enough method calls are made in order to provide a suitable injection point. If the commentator had a local list variable of possible lines to say, there would be no ability to inject the new possible comments. As the commentator makes a method call to request a line to say, a join point is offered, allowing the aspect to return a different commentary line instead. This could actually be seen as a development aid; if there is something you wish to monitor from an aspect that your program doesn’t provide a join point for, it is probably an indication that your program does not use enough functions. However, injecting code in this manner is abstracting functionality in such a way that the code readability is severely reduced, masking the actual execution of the program. Modifying the program state outside of the base code logic, unless to alleviating code tangling, appears to be little more than language-sanctioned code hacking. There doesn’t seem to be any benefit over the observer pattern, apart from saving one or two lines of code explicitly defining when observers can execute. This is a text saving which you might well lose again by commenting that aspects wrap around this section of code! However, this is not a scalable approach. Once the issue involved becomes a cross-cutting concern, where code is littered with references to notification objects that perform the same function, there is a readability and elegance benefit to separating this functionality out into an aspect in order to remove the code tangling. The only functionality that aspects provide that the observer pattern doesn’t is the ability to begin execution of the method at will. I believe that there are a small subset of problems that will benefit from this, but, for me, these problems seem to be the same subset of code tangling problems already heard about, such as logging and security.

5.

SUMMARY

It is surprising how closely my personal evaluation of aspectoriented programming aligns with the findings of Murphy et al. [10]. My attempts to inject functionality into the code required making sure that there were sufficient join points. However, I would expand their definition of unidirectional (aspect code refers to the base code but not vice versa) to include whether the base code would be improved through the addition of referring to functionality, rather than encapsulated in an aspect. While the database aspect I attempted did not require the commentator to refer to the database, the

base code became far more readable once it did. However, the commentator’s monitoring of the program was a narrow and unidirectional cross-cutting concern, and it is here where the benefits of aspect-oriented programming became clear. Aspects have a use when the software requirements extend above and beyond what object-orientated programming allows. Problems such as code tangling cannot be solved by OOP, and aspects provide a stable and functional solution. However, aspects should be considered an extra tool to support traditional object-oriented programming, not a replacement. I remain unconvinced that aspects should be utilized to provide variability in place of a well-defined plugin architecture. The solutions provided by OOP, such as implementation of interfaces or the observer pattern, are functional and readable. It is once the features required become cross-cutting concerns that the power and elegance of aspect-oriented programming become known, significantly increasing the readability of code. It cannot be overstated how the removal of code tangling throughout a project creates an otherwise unachievable level of code elegance. It is here that aspect-oriented programming shines.

6.

FUTURE WORK

Aspect-oriented programming has yet to be fully studied in the video game space itself. Even in Tag Game, Funge and I discussed how rendering to screen may be a cross-cutting concern that could be abstracted from the main game code. Game mechanics themselves may well have cross-cutting concerns, such as those identified in Jiazzi. There remains great scope to investigate the benefits that aspects could bring to video game design.

7.

REFERENCES

[1] pygame - python game development [online, cited 2008-11-30]. Available from World Wide Web: http://www.pygame.org. [2] Spring python. Available from World Wide Web: http://springpython.webfactional.com/ [cited 2008-11-30]. [3] Vander Alves, Matos, Leonardo Cole, Paulo Borba, and Geber Ramalho. Extracting and evolving mobile games product lines. pages 70–81. 2005. Available from World Wide Web: http://dx.doi.org/10.1007/11554844 8. [4] John Funge. Artificial intelligence (ai) for computer games [online, cited 2008-11-30]. Available from World Wide Web: http://ai4games.sourceforge.net/codedownload.html. [5] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns. Addison-Wesley Professional, January 1995. [6] Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, and William Griswold. An overview of AspectJ. pages 327–354. 2001. Available from World Wide Web: http://dx.doi.org/10.1007/3-540-45337-7 18. [7] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina V. Lopes, Jean-Marc Loingtier, and John Irwin. Aspect-oriented programming. In European Conference on Object-Oriented

Programming, June 1997. [8] Uir´ a Kulesza, Vander Alves, Alessandro Garcia, Carlos de Lucena, and Paulo Borba. Improving extensibility of object-oriented frameworks with aspect-oriented programming. pages 231–245. 2006. Available from World Wide Web: http://dx.doi.org/10.1007/11763864 17. [9] Sean Mcdirmid and Wilson C. Hsieh. Aspect-oriented programming with jiazzi. In AOSD ’03: Proceedings of the 2nd international conference on Aspect-oriented software development, pages 70–79, New York, NY, USA, 2003. ACM Press. Available from World Wide Web: http://dx.doi.org/10.1145/643603.643611. [10] Gail C. Murphy, Robert J. Walker, Elisa L. A. Baniassad, Martin P. Robillard, Albert Lai, and Mik A. Kersten. Does aspect-oriented programming work? Communications of the ACM, 44(10):75–77, 2001. Available from World Wide Web: http://dx.doi.org/10.1145/383845.383862. [11] Odysseas Papapetrou and George A. Papadopoulos. Aspect oriented programming for a component-based real life application: a case study. In SAC ’04: Proceedings of the 2004 ACM symposium on Applied computing, pages 1554–1558, New York, NY, USA, 2004. ACM. Available from World Wide Web: http://dx.doi.org/10.1145/967900.968210. [12] Carl Zetie. Aspect-oriented programming considered harmful. Technical report, Forrester, April 2005.