A Programming Model for Boss Encounters in 2D Action Games
Total Page：16
File Type：pdf, Size：1020Kb
Experimental AI in Games: Papers from the AIIDE Workshop AAAI Technical Report WS-16-22 A Programming Model for Boss Encounters in 2D Action Games Kristin Siu,1 Eric Butler,2 and Alexander Zook1 1School of Interactive Computing, Georgia Institute of Technology 2Department of Computer Science & Engineering, University of Washington fkasiu, [email protected]; [email protected] Abstract space. While the methods for generation and objective func- tions can all be complex, the representation of a 2D grid- Boss fights are a memorable and climatic point of many based level is clear. games. In this work we present a programming model for defining boss experiences in 2D action games. The However, with bosses, a representation suitable for gener- domain we focus on is characterized by real-time move- ation is non-obvious. Traditionally bosses are implemented ment through a continuous space in which the player in general-purpose programming languages as they involve and opposing boss damage each other through phys- complex, state-based, and usually reactive behaviors. To ical collisions, and player and boss behavior is gov- generate these boss experiences we need a representation erned primarily by finite state machines. Our program- for bosses that is sufficiently expressive to capture the parts ming model consists of primitive systems such as kine- of the design space we care about while being limited and matic physics to store object state and detect collisions structured enough to make generation tractable. paired with finite state machines to define behavior. We In this paper, we present a programming model for repre- describe our model and demonstrate its expressiveness senting boss experiences similar to classic 2D action games. with examples of three classic boss fights from games in The Legend of Zelda, Castlevania, and Sonic the Hedge- Boss experiences are scenarios where a player interacts with hog. Our future goals include procedural generation of a boss object that has patterned behavior; scenarios end boss encounters, and we report on the research chal- based on termination criteria. Boss objects are physics ob- lenges involved in achieving this goal. jects enabling collisions—spanning roaming entities in the world (Moldorm in The Legend of Zelda) to massive set pieces (Sigma in MegaMan X). Behaviors govern the pat- Introduction terned movements and actions of bosses, and termination Whether it is the first test of a player’s skill or the climatic, criteria govern when the experience ends (potentially in suc- final battle, boss fights are some of the most memorable mo- cess or failure for the player). ments in games. Compared to encounters with normal ene- Our programming model uses finite state machines to mies, boss fights are intended to challenge the player, often describe behavior paired with component-based systems acting as gatekeepers for the player’s progression through to represent game state and perform calculations such as the game. These encounters are used to ensure players have physics and hit points. This model is an important step attained sufficient skill or completed the requirements nec- towards generating boss experiences in this design space. essary to progress further. When players overcome bosses, The scope of this programming model is currently limited to they are awarded in-game rewards, progress, and achieve- specifying physical locations and controlling behavior. As- ment, not to mention a sense of accomplishment. pects such as graphics and sound design, while important to We are interested in procedurally generating boss experi- boss design, are beyond the scope of this work. ences similar to the boss encounters in classic 2D action or To demonstrate the expressiveness of the model, we built adventure games such as The Legend of Zelda series. These a prototype that allows for the implementation of playable encounters are characterized by combat based around colli- boss experiences. We describe three classic boss fights we sions with an enemy hitbox in a 2D plane using real-time replicated in it: Moldorm from The Legend of Zelda, Drac- motion in continuous space. ula from Castlevania, and Dr. Eggman from Sonic the All content generation methods, at a broad level, reduce to Hedgehog. In the future we plan to explore techniques to searching a space of design possibilities (Shaker, Togelius, automatically generate bosses using our model. and Nelson 2015). For example, 2D level generation of- ten is modeled as searching a space of possible assignments Related Work of tiles in a discretized 2D grid world, where the search is Our programming model defines both the physical structure guided by features such as how the player moves through the and behavior of a boss. Several researchers have gener- Copyright c 2016, Association for the Advancement of Artificial ated in-game entity structures including ship hulls (Liapis, Intelligence (www.aaai.org). All rights reserved. Yannakakis, and Togelius 2011), flower shapes (Risi et al. 86 and more restricted, focusing on finite state machines as the primary update mechanism. Domain From ambient interactions to odious overlords, the space of boss experiences varies widely across games and genres. Here we focus on boss experiences in classic 2D action and adventure games. Classic 2D boss designs often use a 2D top-down camera perspective (e.g., The Legend of Zelda se- ries and Gradius) or a side-scrolling perspective (e.g., Castl- evania, MegaMan, and Sonic the Hedgehog). The combat in these games is characterized by real-time movement in continuous space, with attacks primarily based on collisions with a static or moving foe. Figure 1: The Moldorm boss from A Link to the Past Boss experiences in these games share many structures. A player avatar operates in a 2D environment with an oppos- ing entity (or entities)—the boss. Both the player avatar and the boss entity are given a range of 2D movement and a set 2012), and ship weapon patterns (Hastings, Guha, and Stan- of combat mechanics that each can use against each other. ley 2009). By contrast, our programming model targets a These combat mechanics are frequently (but not always) im- broad class of 2D entities and allows for connected parts plemented through the use of hit boxes and attack boxes: the with independently governed behaviors (though we do not boss uses its body or projectiles to try to hit the player and yet generate entities). cause damage, while the player tries to use its attacks to hit Several languages have been developed to facilitate au- certain weak points in the boss and cause damage. thoring behaviors for different domains. Examples include Classic 2D bosses act based on state-based scripted be- Fac¸ade’s A Behavior Language (Mateas and Stern 2002) haviors to follow patterns and change in reaction to the for agent responses to players, the Versu storytelling plat- player’s performance. For example, a boss may begin us- form’s1 (Evans and Short 2014) social model of small-group ing new attacks after a player has successfully lowered its interactions, and Prom Week’s “social physics” model (Mc- health parameter to a particular threshold. These behav- Coy et al. 2014) for characters’ personal and social traits and iors follow patterns akin to finite state machines, with the events. By contrast, our model primarily models movement- boss transitioning through phases or attack patterns during based behaviors with simplified patterns that are amenable the fight. Finite state machines are a typical representation to generation rather than purely human scripting. Osborn et used in implementations of bosses in this domain (Milling- al. (2015) formally model combat in games in terms of op- ton and Funge 2009). The experience ends when the player erational logics (Mateas and Wardrip-Fruin 2009), but not overcomes (or succumbs to) the boss in some way, such as at the level of a programming model. Instead, we target the reducing a health parameter to zero or surviving for a set specific entities in combat, rather than the scenario and sys- amount of time. We capture common facets of 2D boss de- tems encompassing combat as a whole. sign in our modeling language for describing bosses. Game description languages encompass the broader class of representations used to specify the entities, behaviors, and termination criteria associated with classes of games. Ex- Model Description amples include turn-based competitive games in The Stan- We now describe our programming model for bosses. Our ford Game Description Language (Love et al. 2008), puz- model combines finite state machines to govern behavior zle games in Puzzlescript2, and adversarial board games with component-based systems such as physics and health. in the EGGG (Orwant 2000) and Ludi (Browne and Maire These systems expose primitive properties of the player, 2010). By contrast, our programming model targets a space boss, and any other objects in the experience. A kinemat- of real-time, continuous behaviors. The Video Game De- ics physics system exposes information about physical prop- scription Language (VGDL) (Schaul 2013) was developed erties and geometry. A health system exposes information to model arcade-style 2D games like Frogger, Space In- about boss vulnerabilities, and provides update routines such vaders, and Pacman. Unlike the VGDL our programming as collision detection. model supports complex patterns of entity behavior and fa- Boss behavior is defined by a set of state machines, which cilitates the creation of component-based composite entities. we refer to as behavior graphs, whose actions modify the Casanova (Maggiore et al. 2012) is a DSL for game pro- state of the primitives (e.g., controlling the velocity of an gramming that allows for straightforward expression of up- object) with transitions conditioned on the state of the prim- date/draw loops and declarative rules, and supports efficient itives (e.g., reacting to a collision with the player).