Entertainment Computing 3 (2012) 19–25
Contents lists available at SciVerse ScienceDirect
Entertainment Computing
journal homepage: ees.elsevier.com/entcom
Join token: A language mechanism for programming interactive games ⇑ Taketoshi Nishimori , Yasushi Kuno
Graduate School of Business Sciences, University of Tsukuba, Tokyo, 3-29-1 Otsuka, Bunkyo-ku, Tokyo 112-0012, Japan article info abstract
Article history: In the video game software industry, scripting languages have been used to alleviate the complexity of Received 15 August 2010 game development. Much of this complexity resides in managing game characters’ multiple concurrent Revised 4 September 2011 activities. However, current scripting languages seem to lack support for interactions among multiple Accepted 20 September 2011 concurrent activities in a state-dependent manner. To overcome this problem, we propose a mechanism Available online 29 September 2011 called ‘‘join token’’ in which the states of game characters can be expressed as tokens and interactions can be described as handlers involving multiple tokens. For the purpose of evaluation, we have developed a Keywords: game scripting language called ‘‘Mogemoge’’, and we have written several sample games in this language. Video game In this paper, we explain the join token, the design/implementation of Mogemoge, and its evaluation Programming language Scripting language through a sample game. Ó 2011 International Federation for Information Processing Published by Elsevier B.V. All rights reserved.
1. Introduction tion such as ‘‘wait’’ and ‘‘signal’’ operations is required. It is difficult to achieve conditional synchronization of these operations in gen- Recently, efforts required to develop commercial video games eral-purpose programming languages. have significantly increased. This is because the platforms for such Currently, some scripting languages address part of these prob- games (PCs or game consoles such as Xbox or PlayStation) are lems. Stackless Python [1], for instance, supports microthreads that becoming more powerful i.e., game programs are becoming larger make it feasible to assign a dedicated thread to each game charac- and more complex than ever before. ter. In addition, Stackless Python simplifies the description of mul- One method to deal with this problem is to use game-oriented tiple concurrent activities by each character but does not address scripting languages. Scripting languages enable more abstract and the description problem of interaction among the characters. Unre- compact descriptions in general, which lead to more concise and alScript [2] supports concurrent objects called ‘‘actors’’ as well as comprehensive code. Game-oriented scripting languages can addi- their states. (The methods annotated with state names are called tionally be equipped with language mechanisms that are specifi- only in the corresponding states.) By mapping game characters to cally suitable for game descriptions, thus relieving the burden on actors and their states to actor states, natural description becomes game programmers. possible. However, UnrealScript does not address the difficulty One of the domains in which such language mechanisms are arising from conditional synchronization. desirable is the interaction between multiple game characters, as Many game-oriented scripting languages are used these days, is often observed in action games. From game players’ viewpoint, such as GameMonkeyScript [3], AngelScript [4], and Squirrel [5]. many game characters act concurrently with complex interactions In these languages, although various approaches are used to ad- among them, often depending on their states. For example, in dress the problems associated with multiple concurrent activities many shooting games, multiple missiles concurrently move on or object states, no outstanding approach to the problem of the game screen. When these missiles ‘‘hit’’ various objects, the interaction among multiple concurrent activities has yet been resulting effects differ depending on the type of objects and their found. states such as whether they have a shield. In this paper, we propose a new language mechanism called It is generally accepted that concurrent programming in gen- ‘‘join token’’ that coordinates multiple state-dependent concurrent eral-purpose programming languages is difficult and error prone. activities required for a game description. To assess the effective- In particular, when interaction among concurrent activities is ness of this mechanism, we also design and implement an experi- dependent on the state of each activity, conditional synchroniza- mental game-oriented scripting language called ‘‘Mogemoge’’ that incorporates the join token as a built-in synchronization mecha- nism. For the purpose of evaluation, we describe several sample ⇑ Corresponding author. games using Mogemoge. E-mail addresses: [email protected] (T. Nishimori), [email protected] (Y. Kuno). Description of concurrent activities has been the target of active URL: http://www.gssm.otsuka.tsukuba.ac.jp (Y. Kuno). research for some time, and computational models such as Petri
1875-9521/$ - see front matter Ó 2011 International Federation for Information Processing Published by Elsevier B.V. All rights reserved. doi:10.1016/j.entcom.2011.09.001 20 T. Nishimori, Y. Kuno / Entertainment Computing 3 (2012) 19–25 nets [6,7] have been proposed and extensively studied. However, To summarize the discussion, our objective is to retain the merit mapping between those theoretical models and practical program- of object orientation (natural description), while avoiding the ming languages is not always straightforward (we provide addi- problems associated with the coding of interactions. This is the tional note on Petri nets in Section 5). second prerequisite. The concept of join token is based on join-calculus [8] and Linda [9,10]. Join-calculus models the coordination of multiple concur- rent tasks, while Linda models the decoupling of the message sen- 2.1.3. The idea behind join token der and receiver. As far as we know, several programming The idea of join token is derived directly from the above prereq- languages are based on one of these concepts, but no language uisites. First, phase separation can be realized by a pool in which has combined them both. In our opinion, coordination and decou- ‘‘tokens’’ are accumulated. In the ‘‘update all characters’’ phase, pling are equally beneficial in clearly describing game logic. Hence, every status that needs to be handled later is converted into tokens we investigate a method of combining coordination and and placed into the pool. Then, in the ‘‘handle event’’ phase, these decoupling. tokens are matched with event handlers and are acted upon. This The structure of this paper is as follows. In Section 2, we explain clear separation eases the difficulty that programmers encounter the idea behind and the design of the join token. In Section 3,we by controlling complex timing problems within games. provide an overview of the Mogemoge language and discuss its Second, interaction handling can be realized by ‘‘join’’ handlers, implementation. In Section 4, we describe a sample game using whereby multiple tokens within the pool are collected and handled Mogemoge and discuss the effectiveness of the join token. In Sec- in a joint activity. This design solves the problem associated with tion 5, we present a discussion, and finally we conclude our study the imbalanced nature of object orientation as noted above be- in Section 6. cause handlers are independent of objects. In summary, the basic idea behind the join token can be repre- 2. Join token: idea and design sented as accumulating tokens in a pool and using ‘‘join’’ handlers that collect multiple tokens and act upon them. The concrete de- 2.1. Prerequisite and idea of join token sign behind the join token is explained below.
As described above, a join token is a language mechanism that is specifically targeted to describing multiple concurrent and state- 2.2. Basic design of join token dependent activities that are often seen in action games. First, we describe the basic prerequisites for interactive game programs. As described above, a join token is a mechanism designed We then address the idea behind our join token. around tokens in a pool and join handlers acting upon those to- kens. The concrete design of the mechanism is as follows (Fig. 1): 2.1.1. Prerequisite 1: phase separation Many video game programs have a main loop consisting of an Each object participating in an interaction expresses its willing- ‘‘update all characters’’ phase and a ‘‘handle events caused by pre- ness to participate by generating a ‘‘token’’. A token with a list of vious update’’ phase. In the former phase, the status of each char- parameters specified in the code is then associated with such an acter is updated according to a small advance in the current time. object. During this period, some events such as the collision of characters Tokens are generated when methods execute ‘‘throw state- may occur. In the latter phase, the events are handled and their ef- ments’’, and the generated tokens are automatically placed into fects are recorded for processing in the next update phase. the global ‘‘token pool’’. This phase separation is not built into the general-purpose An interaction (multiple object action) is described as a ‘‘join programming languages that are used to program games, and statement’’ that defines a ‘‘join handler’’ (hereafter, ‘‘handler’’). has to be programmed by hand. We believe that building phase A handler specifies the set of tokens that participate in the separation into the language will simplify programmers’ task by interaction, the optional conditions, and the body statements making the situation clearer. Hence this is the first prerequisite. that are executed when the interaction occurs. Interactions are started when a special ‘‘ignition’’ statement is 2.1.2. Prerequisite 2: adopting object orientation executed in the program. This statement corresponds to the Because the entities that must be handled within the programs ‘‘handle event’’ phase noted above, and is expected to be used can naturally be mapped to objects, many of today’s game-script- in the main loop. When the ignition statement is executed, ing languages are based on object orientation. In general, this ap- the token pool sequentially scans the list of defined handlers, proach eases program description. and tries to select the tokens that match the handler. In object orientation, behaviors (actions) are described as meth- When all the token specifications of the handler are matched ods attached to one of these objects. Methods are implemented as with the existing tokens and the handler’s associated condition subroutines and are called from other methods (or from the main is true, if specified, the handler ‘‘fires’’ and the body of the han- 1 routine). However, the above design differs significantly from dler is executed. Within the body, each token’s associated interactions in game programs, in the following manner. objects and parameters are available. The tokens that participate in a firing are removed from the token pool unless otherwise Interactions in games are associated with two or more charac- specified. ters, while methods are attached to a single object. Interactions are initiated when some conditions (over the asso- A major benefit of the above design is that handlers are inde- ciated characters) are met, while methods are invoked from pendent of all objects and are associated with the global token some other method (under the control of the object that con- pool. The separation of object interactions (handlers) and each ob- tains the method). ject’s behavior (methods) greatly simplifies the structure of game The initiation of interactions is controlled by the states of each scripts, as shown in subsequent sections. associated character, while method invocations are controlled solely by the calling object. 1 A handler body is executed atomically, with no interleaving with other code. T. Nishimori, Y. Kuno / Entertainment Computing 3 (2012) 19–25 21
Fig. 1. Idea of join token.
2.3. Further details of join token mechanism
Because the join token is targeted to game description, its event ordering should be strictly defined and should be controllable by a programmer. Therefore, a list of handlers is scanned in the order of their def- inition (source program order), and each handler consumes as many tokens as possible when it is scanned, with matching being performed in the order described in the corresponding join state- ment. Token matching is also performed strictly as per the ordering with an older token in the pool being considered earlier. Note that a handler can fire multiple times when sufficient tokens exist and conditions permit. The tokens generated within the method invoked by the han- dler bodies can be processed by other handlers later in the scan- ning order. Tokens are identified according to their names and originating object. Therefore, if an object throws tokens with the same name twice and the first token is not consumed, the second token re- places the first one. The number of arguments may vary among these tokens. Alternatively, an object can withdraw a token with the ‘‘dispose’’ statement, which removes the token from the token Fig. 2. Simplified syntax of Mogemoge. pool. In the following section, we describe the overall design of the the object-orientated feature, other basic features, join token feature, Mogemoge language. We then show actual examples of the token and current implementation. control statements explained above. 3.2. Object orientation 3. Design and implementation of the Mogemoge language In Mogemoge, an object is created by an object constructor. The following code creates a bank account object and assigns this ob- 3.1. Design policy ject to the global variable named Account:
As described above, Mogemoge is an experimental game-script- Account=object{ ing language equipped with the join token. The purpose of devel- v=0; oping such a language is to evaluate the usefulness and deposit=method(n){v=v+n;}; descriptive potential of the join token. Therefore, Mogemoge is de- withdraw=method(n){ signed to be a minimal, compact and simple programming lan- v=v-n; guage, except for the part executing the join token. if(v<0){v=0;}# funny, but only an example... To develop this language, we used prototype-based object ori- }; entation similar to that used in JavaScript, Self [11] and Dolittle get=method(){result v;}; [12] because it can lead to compact language definition. In the }; same manner, we incorporated minimal functionalities in Moge- moge, namely, object definition/creation, method definition/invo- Within the object definition, variable assignments define and cation and action description through executable statements. initialize the object’s instance variables. Note that the methods Fig. 2 shows the simplified syntax of Mogemoge in extended are also ordinary values and are stored in instance variables. Backus-Naur-Form (BNF).2 In the following subsections, we describe A‘‘new’’ operator creates an object through copying: a=new Account; 2 We have omitted unimportant details. ‘‘[A]’’ indicates optional A,‘‘A ÁÁÁ’’ indicates In the above code, the ‘‘new’’ operator creates a new object and repetition of A,‘‘A,...’’ indicates comma separated list of A. then copies all of the properties, including the variables and their 22 T. Nishimori, Y. Kuno / Entertainment Computing 3 (2012) 19–25 values from the Account object. The resulting object is assigned to join r1.tok1(a, b) r2.tok2(c, d){ variable ‘‘a’’. print ‘‘a+c="+(a+c); To invoke methods on an object, the dot notation is used: print ‘‘b+d="+(b+d); a.deposit(100); }; a.withdraw(50); print ‘‘outstanding:"+a.get(); In the above example, the handler fires when both tokens tok1 and tok2 are in the token pool. The term r1.tok1(a, b) indicates The special operation ‘‘print’’ outputs a string value to stan- that the handler matches tok1 and extracts two arguments; when dard output; ‘‘+’’ acts as a string concatenation operator when the number of actual arguments exceeds two, extra values are dis- one of its operands is a string, and it converts other objects to carded whereas if the number of arguments is less than two, nil strings, if necessary. values are used for the missing values. When the handler is in- voked, a and b represent the corresponding argument values for 3.3. Other basic features the matched token, and r1 represents the object that throws the matched token. The term r2.tok2(c,d) can be interpreted like- Mogemoge has four types of values: numeric, string, object and wise. When the body of the handler is being executed, the matched method. Note that a method is an ordinary first-class value. Each values can be used. value has appropriate operations and a literal (or constructor). The tokens matched against a handler are removed from the pool An assignment stores a value with the specified variable. When by default, but when a token specifier is prefixed with the symbol the variable does not exist, it is created anew.3 A‘‘my’’ modifier ‘‘Ã’’, the token is retained in the pool. An example is shown below: forces the creation of local variables for a surrounding scope, similar join r1.tok1(a)Ãr2.tok2(b){...} to Perl. In the following code, within the foo method, a is 1 and b is Note that the tokens remaining in the pool can be consumed by 2, but outside foo, a is 5 and b is 3: another handler, defined in the code below, or can remain in the pool until the next ignition. a=5;b=3; Join handlers may optionally be guarded by Boolean expres- foo=method(){ sions that are introduced by a where clause. In the following exam- my a=1;my b=2; ple, the handler is invoked only when the arguments of the two result method(){ tokens are identical: print ‘‘a="+a; print ‘‘b="+b; join r1.tok1(a) r2.tok2(b) }; where a==b {...}; }; Apart from join statements, the existence of a token can be A‘‘result’’ statement specifies the return value of the method. verified by an exist operator, as shown in the following example: Therefore, the foo method returns an anonymous method object. if (exist tok) {...} Method invocation is denoted with parentheses. For example, m=foo();m();Mogemoge also has the following features, 3.5. Implementation which are described in the http://www.nisnis.jp/mogemoge/moge- moge-lang.html. We implemented Mogemoge with Java and the SableCC [13] compiler-compiler framework. The lexical and syntactic definition C#-like delegation. (about 160 lines of code) is translated by SableCC to Java code, Composition (compose objects and create a new object). which implements a lexical analyzer and a parser. The parser then Injection (modify an object by adding variables). generates an abstract syntax tree (AST) from the source program. Extraction (modify an object by deleting variables). Our interpreter inherits from the tree walking code (also generated by SableCC) and executes the program actions while traversing the 3.4. Join token features tree. The total size of the Mogemoge interpreter is approximately 2400 lines of code, including Java and SableCC definitions. We explain the join token feature below. A throw statement The token pool, tokens, and join handlers are ordinary data adds a token to the global token pool e.g.: structures implemented in Java. When an ignition statement is executed, the list of defined join handlers is sequentially searched throw tok1(1, 2); for matched tokens in the pool. When a sufficient token for the throw tok2(30, 40); handler is found, the where clause is executed (if any). Then, if throw tok3("hello"); the condition is satisfied, the handler body is executed. Note that In the above example, the first throw statement throws a token the where clause and handler bodies are represented as AST data named tok1 with the arguments (1,2) into the token pool. The structures and are stored within the handler object. other two statements can be interpreted likewise. The current algorithm for the token handler match uses a sim- In contrast to the throw statement, a dispose statement re- ple linear search. So far, this algorithm has not caused any perfor- moves a token from the token pool. The following statement re- mance problems with approximately 100 handlers and 1000 moves tok1, which is thrown by the object executing the tokens. If necessary, we can implement additional index data method code: structures to speed up the search. dispose tok1; In the following section, we show a sample game described in A join statement defines a handler. The following is an exam- Mogemoge. ple of a handler definition: 4. A sample game in Mogemoge
3 Such a design may not be appropriate for a production environment. However, we are designing an experimental scripting language, and many existing script languages To evaluate the descriptiveness of the join token, we built a have a similar design. sample shooting game application (Fig. 3) in Mogemoge. T. Nishimori, Y. Kuno / Entertainment Computing 3 (2012) 19–25 23
R3. A ship can shoot missiles to damage other ships. R4. By receiving power food, a ship becomes ‘‘unbeatable’’ for a certain period of time. R5. An unbeatable ship can damage other ships by colliding with them. R6. An unbeatable ship can destroy missiles. R7. Ships that incur a certain amount of damage in a single shot are destroyed. R8. When a ship accumulates a certain amount of collective damage by means of several shots, it is destroyed.
These rules are classified into two categories: rules that specify relationships between game characters (R2, R3, R4, R5, R6) and rules that do not (R1, R7, R8). Nonrelationship rules (R1, R7, R8) can naturally be implemented as ordinary methods associated with corresponding objects. However, the use of ordinary methods to implement the relationship rules (R2, R3, R4, R5, R6) requires complicated coding, because two or more objects participate in the interaction. In this case, our join token is beneficial. Fig. 4 shows a skeleton implementation of the above rules in Mogemoge (details are omitted for clarity). Variables x, y, and dir hold the geometry information of the ships. To identify the Fig. 3. Screenshot of the sample game. shooter of a shot, every ship has its own unique ID, which is stored In this shooting game, ships (arrowheads) try to conquer each in id. In addition, all shots also record their shooters’ ID in id. other. The ships can shoot missiles (short line segments) to damage The method ‘‘update’’ implements the main action and is exe- other ships or can pick power foods (small squares). A player can cuted once from the main method (not shown here) for every ani- control his ship with a keyboard. Enemies are controlled by the mation frame. The method ‘‘tt is_collide’’ checks for collision with program. The player’s aim in the game is to destroy all the enemies. other ships. The method ‘‘damage’’ damages the ship. Initially, The game rules are summarized as follows: ‘‘init’’ is invoked and a normal token is thrown by every ship. When ‘‘make_unbeatable’’ is invoked, the normal token is re- R1. Ships are controlled by either a player or the program. moved and the unbeatable token is thrown. This action repre- R2. Ships must not overlap each other. sents a change in the status for the ship. Note that normal and unbeatable tokens describe the status of a ship. The ‘‘init’’ method initializes a ship’s status as normal. In the ‘‘update’’ method, the ‘‘exist’’ operator is used to test whether the ship is unbeatable. If it is, the remaining time is de- creased and the status is changed to normal when this time expires. The method ‘‘make_unbeatable’’ describes that change of the status from normal to unbeatable.
Fig. 4. Source code for ship object. Fig. 5. Source code for game rule implementation. 24 T. Nishimori, Y. Kuno / Entertainment Computing 3 (2012) 19–25
Now, let us consider our five relationship rules (R2, R3, R4, R5, Based on our experiences in writing example games in Moge- R6). Rule R2 concerns ships having normal status. Rule R3 handles moge, we found that the join token was effective in describing ships and missiles. Rule R4 handles ships and power foods. Rule R5 interaction among multiple activities. This efficacy was, in part, handles a normal-status ship and an unbeatable-status ship. Rule attributable to the separation of token emission (expressing oppor- R6 concerns a missile and an unbeatable-status ship. tunity for interaction in the future) and handler execution (actual Fig. 5 is the skeleton code that implements these rules. In this interaction) in time and place, as in Linda. It was also partially sample, tokens are used as the status of the game characters. attributable to symmetric and automatic joining through handlers, For example, the handler for R3 renders the following descrip- as in join calculus. Therefore, the combination of Linda and join- tion: If a normal-status ship and a missile collide and the ship is calculus models appears to be quite successful. not a shooter of the missile, then the ship is damaged by the mis- sile and the missile is destroyed. Note that when the token speci- 5.2. Game scripting vs parallel computing fication on the handler is not prefixed by Ã, the corresponding token is removed from the token pool. Because the join token is based on generic parallel computing The relationship rules are concisely expressed. Fig. 5 directly models, it is natural to consider this concept as a basis for parallel and declaratively represents the rule described above. There are computation. However, as stated in the introduction section, our no codes to iterate the character list or to combine characters be- aim was to develop a natural and comprehensive game description, cause token matching is automatically performed by the token and hence our join token was designed as such. pool. For example, our current implementation uses a slow tree inter- preter, but this setup is sufficient in handling up to several hundred 5. Discussion characters. In interactive games, screen updating and event han- dling occurs approximately at a 20 frame/s rate (50 ms duration In this section, we discuss the relationship between our join to- for one cycle). This is an extremely long period considering current ken model and existing computational models. We then explore CPU speed. It is true that high-end game programs are computa- several remaining issues, such as the distinction between game tion intensive, but such computations are mostly needed in high- scripting and general parallel computation, the exposure of object resolution 3D graphics in which processing is completely separate states as tokens, and garbage collection of tokens. processes from game control. Aside from the above arguments, it is also true that join token may be useful as a general-purpose parallel computational frame- 5.1. Relationship with existing computational models work. This is yet another research topic that we may pursue in the future. As noted above, the idea of join token is based on two compu- tational models, join-calculus [8] and Linda [9,10]: there are also apparent similarities with Petri nets [6,7]. 5.3. What the tokens represent In Petri nets, computing activities are modeled with tokens that are placed within a directed graph. This graph contains alternating Some controversy over what the tokens in our model represent ‘‘places’’ and ‘‘transitions’’. A token in a particular place is dupli- might exist. For example, in the sample game, the unbeatability of cated when multiple arcs are drawn from that place. When multi- a ship is exposed as a corresponding token. This tendency may ap- ple arcs encounter a transition, the transition ‘‘fires’’ only when pear as loss of data abstraction. every originating places for those arcs has a token (join semantics). However, accessing unbeatability from outside of an object is A token is then sent through each of the arcs originating from the absolutely necessary to implement the game logic. In our view, to- transition. Although Petri nets are a powerful model, it is theoret- kens represent ‘‘states of game characters that are visible from out- ical and abstract. As a result, it is difficult to adopt this model in ac- side’’. In traditional object orientation, such states need to be tual (game) programming languages. exposed through getter methods. This implementation is obscure In Linda, concurrent activities emit ‘‘tuples’’ to the global ‘‘tuple because what constitutes a state and what does not is only implic- space’’ and / or withdraw tokens from there. Tuples are identified itly stated. Therefore, in this respect, we believe our model has with their names and can convey additional data with associated merit. arguments. The Linda model is attractive in that the emission Moreover, note that the exposure of unbeatability is completely and withdrawal of tuples are separated in both space (distribution) controlled by the methods belonging to the corresponding ship ob- and time (concurrency), thereby making the code easier to ject. The local representation of unbeatability (in the form of in- interpret. Moreover, data races are naturally avoided because a tu- stance variables) can be changed if required without affecting the ple and its associated data are atomically withdrawn from the token interface, indicating that data abstraction is preserved. tuple space when they are handled by one of the activities. Linda’s tuple space has been implemented in various programming lan- 5.4. Garbage collection of tokens guages, such as in Java’s JavaSpaces [14] or Ruby’s Rinda [15]. In join-calculus, the joining of multiple activities is explicitly Currently, garbage collection of tokens remaining in the pool is designated in a symmetric manner (as is the case in our model’s not performed. In our current implementation, tokens represent join handlers). This symmetric joining has attracted many pro- characters within the game (with associated states). Hence pro- gramming language researchers. Several programming languages, grammers are responsible for determining which tokens should such as JoCaml [16], Polyphonic C# [17] and Join Java [18] were be present in the pool and explicitly disposing unnecessary ones. developed based on join-calculus. However, token garbage collection can be implemented in the In summary, join-calculus provides a mechanism for symmetri- following manner. Garbage collection of objects in Mogemoge is cal synchronization of multiple activities in a comprehensive similar to that in the other languages, and tokens associated with manner, but it is mainly concerned with control synchronization. garbage-collected objects can be automatically withdrawn from Linda provides data/state exchange among concurrent activities the pool. in a convenient manner, but its style is not symmetric. Our join to- One basic assumption of the above scheme is that object refer- ken combines the strengths of both models. ences remaining only in the pool (through tokens) are redundant T. Nishimori, Y. Kuno / Entertainment Computing 3 (2012) 19–25 25 and unimportant. We should accumulate more experiences with [3] M. Riek, G. Douglas, GameMonkeyScript. Available from: