• Abstract and Figures
• Public Full-text

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

Load more

  7

Copy Link