Eggopolypse: A Roguelike Turn-Based Tactical Fighting Video Game

Matthew Ottomano Alex Williams Middlebury College Middlebury College Astoria, NY Greenwich, CT [email protected] [email protected]

ABSTRACT and The Darkest Dungeon.Each contributes something new We had no experience with game design or development. to the genre unlike the game we eventually created, but each Given that we have grown up playing video games, we took inspired us in some way. an interest in learning about the development process. We We built the game in the Unity engine. Unity is perfect also wanted to create a game up to par with the industry for our needs because of its large free library of textures standard. We decided to create a Roguelike game. Roguelike given our lack of artistry. It also meets the industry stan- games are defined by two aspects: permanent death and dard mentioned earlier, as many large game development random levels. Roguelike games are modeled after Rogue, companies use Unity to build their games. On top of Unity, a primitive dungeon crawler from 1980. Its introduction of we used the ORK framework to assist with the level design those two aspects mentioned spawned a new genre of game. and battle system. We were inspired by three particular Roguelike games: Slay Our finished game is Eggopolypse. The player controls the Spire, Wizard of Legend, and The Darkest Dungeon. Jason Grant, our professor, who has to navigate Middlebury Each one has a unique play style and twist to the genre. College after a horrific accident transforms all the students After recognizing what has already been done and realizing and faculty into eggs. However, some eggs believe that their that a card based battle system would be too complex, we new form is better and try to stop him. Jason commands set out to build a turn-based Roguelike that uses minion an army of students who fight for his cause to transform combat on a two-dimensional board. everyone back. Each student has equipment that boosts By the end of the semester, we built a fully functional their status values and can attack in battle. Students can be Roguelike game, complete with grid battles, minion com- one of two classes: physical fighter or magical fighter. They bat, items, and a storyline. The player is our professor, can wield different weapons and unlock different abilities Jason Grant, who enters a horrific Middlebury where all the that are better or worse based on their class. students and faculty have been turned into eggs. He must Upon finishing the semester, our game met all of our goals. command an army of his students willing to fight against We created a turn-based Roguelike game with a grid-based some eggs who believe they are better off that way. Each battle system and different classes for our playable charac- student, or minion, has a certain level of health, mana, crit- ters. Even though our game was not on the same caliber ical strike chance, etc. They can either be a physical melee as other games we have played, we understand that as two fighter or a ranged magical fighter. They can wear armor undergraduate computer science students, we cannot create and trinkets each with different perks, and can also equip games on the same level as large game development com- different weapons allowing access to different attacks. With panies, especially when we had no artistic or development more time, we would have improved the user interface during experience. battle and when recruiting new minions. We also would have created more levels, a final boss, and a third class for the 2. PROBLEM STATEMENT minions. We were unfortunately overwhelmed by Unity?s Our game focuses on creating a Roguelike turn-based role- complexity during the first part of the semester. playing game using a tactical grid-like combat system. These elements combine a series of elements in games that devel- Keywords opers have made in the past. The challenge was being able to mix these elements that have not been mixed before into CS701; LATEX; Roguelike; Video Game a game that runs well and is aesthetically pleasing to the gamer to provide an enjoyable gaming experience. 1. INTRODUCTION Pulling from games like Slay the Spire and Rogue, we Our biggest problem at the start of our project was our in- needed to put familiar elements that we as gamers under- experience with game development. We set out to learn how stand very well, and translate them into what we know using to develop a game with professional standards. Our original an unfamiliar API, Unity. Marrying our expectations with idea was to build a Roguelike Deckbuilder game, but after what we could realistically learn in the span of twelve weeks seeing what other Roguelikes have been made and testing proved difficult which was part of the problem. After weeks our own abilities, we decided to build a grid-based minion of trying to create something in our minds, we decided to combat system instead. The other Roguelikes we looked at take another approach. were the original Rogue, Slay the Spire, Wizard of Legend, We decided to forget our ideas for the time-being and simply learn the different tools that Unity has and what can you play as an egg. prove useful for a video game in general. Thus, instead of This sums up how the second approach to creating a game trying to fit Unity to the game in our minds, we tried to fit worked; learning about the tools we have and then framing the game in our minds to the limitations of our knowledge the game we have in mind with the limitations of those tools. of Unity. Using this method, we were able to make more This process proved to be difficult, yet more effective than progress learning Unity rather than just learning what we trying to dive right into the game we wrote on paper. wanted to know about Unity. This proved to be a successful tactic which led to our discovery of the ORK Framework. 3. RELATED WORK The ORK Framework is a tool designed for making Role- Playing Games. It has packages that proved useful for mak- The first Roguelike game is unsurprisingly Rogue(1980). ing our grid-based combat system, both in creating the grid Also known as Rogue: Exploring the Dungeons of Doom, and also managing the logic that is connected with the move- it was inspired by text based adventure games. Its creators ment in the grid. The Framework also had pretty useful pre- Michael Toy and Glenn Wichman wanted to incorporate pro- fabrications with already written animations. Animation is cedural level generation to this adventuring genre. Thus, an element of gaming that we didn’t realize was so complex Rogue was born, a dungeon crawler with procedural level and we soon learned that big gaming companies like Blizzard generation and permanent death. and Epic have dedicated teams strictly for animation while We have played a number of Roguelikes in preparation the developers of the logic are part of a whole other team. for our game and in general growing up. These are: Dark- This is just one of our realizations of the many components est Dungeon(2016), Wizard of Legend (2017), and Slay the that go into building a game. Spire (2017). All of these games were influential in our de- The other part we had to tackle was creating object- cision process while building our game. oriented code that served to create the fun stuff in our Slay the Spire is a turn-based, deck-building Roguelike, game such as the armor, weapons, abilities and miscella- and is the game that pushed us to want to build a Rogue- neous items. We soon realized that these items mean noth- like over another genre of game. We also started our de- ing without status values for the actual characters in our velopment with the idea that our game would use cards as game i.e. the health, mana, critical chance, and more. So a combat mechanism. Slay the Spire sends the player up a we decided to work on creating status values for the enemies towering dungeon with a starting deck of cards that they use and player. to attack enemies and block them. However, Slay the Spire After the status values, we decided to return to the ar- is relatively simple since there is no movement involved, thus mor, weapons, abilities and miscellaneous items. We de- we decided to use a grid-based battle system. cided to create a few of these so that the player can add a Wizard of Legend is a real-time, run-and-gun Roguelike. customizability element to the game. This was just ordinary The player plays as a wizard undergoing trials, and enters object-oriented code. the trials with a set of abilities they can use to damage Next, we decided to work on the interactions between enemies. As a run-and-gun, the player has complete control players and enemies when in combat. We had to implement over where the character can go and must react quickly to certain rules and formulas for different abilities while also the enemies. The real-time nature of the game makes it very checking to see if such ability was possible given the amount difficult, and so we decided to make our game turn based to of mana or energy one had. The other element of interac- allow players of any age group to enjoy the game. tions we dealt with, central to our game, was the movement. Darkest Dungeon is similar to Slay the Spire in that there We needed to make sure that abilities were also checked re- is no movement during battle, but instead of using cards, the garding where the player or enemy was at the time since we player controls four minions, each with their own class and implemented both ranged and melee abilities. abilities. Any character that dies stays dead, so although the Another core element of the game dealt with the devel- player cannot die, his underlings still experience permanent opment of the players and enemies as the game progressed. death. Using the ORK Framework, we developed functions that achieved the kind of curvature that we wanted abilities to 4. METHODS transform under, whether that was linear of exponential. For example, for leveling up, we chose to use an exponential 4.1 Deciding on an Engine function since leveling up at higher levels should we harder The first step in developing a game is deciding which en- than leveling up at lower levels. gine to use. There are a variety of engines to choose from, We also used the ORK Framework’s package for creating each with their own strengths and weaknesses. We even- player controlled minions to help fill the grid in our com- tually narrowed down our list to three: JMonkeyEngine, bat system. Using these minions, we chose to distinguish LibGDX, and Unity. After reading many online forum post- them by creating different sorts of classes such as melee and ings to understand each engine, we learned that Java devel- ranged. We also started to develop a supporter class which opment could potentially lead to slower development. JMon- would heal other minions, but this proved to lead to unfair key, which uses Java, turned out to have too many com- battles so we took it out of the game. plaints that it was too slow. LibGDX did not suffer from this Linking these scripts to animations within the game was problem, as it is more barebones than JMonkey. LibGDX trivial using the ORK Framework’s prefabrications and con- is the engine that Slay the Spire uses, and therefore we had sisted mostly of creating the triggers for when we want cer- more experience with its performance first hand. That said, tain animations from the player or enemy to occur. Among the barebones nature of the engine is also a curse given our these prefabrications came the terrain, avatars, and items small experience with game development. Thus, we decided which proved to make the game feel more realistic, even if on Unity, which scripts in C#, a language very similar to Java syntactically. Unity was a great engine for us to use for a few reasons. The first is that Unity has a large library of free skins and textures for us to use. Given that we have no experience with graphic design, this feature was key in our develop- ment. Secondly, Unity pairs all the underlying code to each visual object. This allowed us to see how our game looked during development itself, allowing for rapid cycle of devel- opment and play testing. Lastly, Unity is a popular engine among large development companies. For example, Unity was used to build Hearthstone: Heroes of Warcraft (2014), Kerbal Space Program(2011), and Assassin?s Creed Iden- tity(2014). Therefore, understanding Unity is an important skill to market ourselves to game development companies. 4.2 Developing with Unity and ORK Unity has a steep learning curve. We began by learning the scripting language: C#. C# is very similar to Java, and so after easily cruising through an online tutorial we moved on to the free tutorials Unity has to learn about its Figure 1: The Combat System in Action editor. The simplest one is a Roll-a-Ball game. Here we learned more about navigating the Unity editor, creating assets and scripts, and prefabrications which are key to de- on a square and the minion will animate walking to that veloping efficiently. We followed that tutorial by completing square. their more challenging 2D Roguelike tutorial. After complet- The combat system also takes into account the spatial ele- ing the two-dimensional tutorial, we decided to implement ment of logic within a fight such as checking to see if a player our game in three dimensions. Two-dimensional games in is too far or too close for an attack. We also connected this Unity require sprite art, and given our lacking artistic tal- system to the system we created for interactions between ent, sprite art seemed intractable. Three-dimensional games the player minions and enemies. use textures instead, which require no artistic talent to use This was done with the aid of the ORK Framework which effectively. allowed us to create the logic for movement easily with the Once we had sufficiently learned Unity, much of the time scripts for our original fighting (interactions) system. in our semester had run out. It was necessary that we add another layer to our tech stack on top of the engine. So, we 5.2 Status Values decided to use a framework to speed up our development. An integral part of any fighting game is the characteristics We found the ORK Framework. ORK comes with built in such as health, mana, critical strike chance, and more. These prefabrications, specifically tiles to use in our battle scenes values indicate the current status of the player and influences and spawn points. ORK also comes with an event script the fighting of said players. that was key in stringing along the logical flow of our game. Two of the most important status values implemented But the most important aspect that ORK aided with was were health and mana which dictate the survivability of a the animations. It implements an animation system called minion. Along with these came things like experience for Legacy, and many of their prefabrications come with anima- leveling up, defense and magical defense for countering or tions already tied to the asset. ORK saved our development dodging attacks, critical chance for how likely a minion is to process and allowed us to create our game without reinvent- achieve critical damage and more. These status values help ing the wheel. govern how all the fights in the game go because they are the true indicators of how strong a minion truly is. These 5. RESULTS can simply be thought of as statistics for a player’s minions. From our procedure, we obtained a fully-functional Rogue- like turn-based video game. We were able to include the 5.3 Development and Classes elements we wanted such as a grid-like combat system that Another very important part of our video game was mak- incorporated a spatial element to fighting, status values, de- ing sure that the game is distinguished and changes enough velopment and classes, abilities, armor, weapons and mis- to make the game meaningful and interesting for the player. cellaneous items, a player-controlled minion system, and in- We achieved this goal through the use of development for teractions of players and enemies within combat. the minions within the game and classes of minions to dis- tinguish them from each other. 5.1 Grid-like Combat System The classes we decided to use for the minions are ranged We were able to create the grid-like combat system that and melee. We developed a third called supporter, but de- we set out to make in the beginning. Our grid composes cided not to include it in the game due to its complexity different squares as markers for where a player can be as well within the combat system. The ranged class of minions spe- as colors that indicate what squares are available to move cializes in ranged attacks in fights while the melee class spe- to. Red indicates that a player’s minion cannot move their cializes in melee attacks. These two classes were given their and green indicates the opposite. We also implemented the own set of abilities from the abilities we created. We used movement of the grid where a player can seamlessly click the ORK Framework to help organize the minions into each class and to randomly assign classes to minions in the be- ginning of the game. Development for the player was a little more difficult. One of the largest questions we had was how much development is too much development while also wondering how much was too little. We needed to create an optimal way for sta- tus values to change as the player progresses through the game. We could have been lazy and made development lin- ear, however, this is not how real games like this are created. Instead we did some research and digging and came upon one of the features of the ORK Framework. The ORK Framework plots curves associated with functions such as the logarithmic function and exponential function. This function can then be triggered at any time we program it to Figure 2: Viewing a potential Minion be. For example, when a minion reaches a certain threshold to level up, this serves as a trigger for the function which 5.6 Interactions Between Players and Enemies then calculates the appropriate status values for the next level. We decided to use different functions for different sta- The last piece of our game are the scripts that govern the tus values including the exponential function for leveling up interactions between player minions and enemies. Without since it should only get more difficult to level up as one gets interactions, the fight within the combat system wouldn’t to higher levels. exist; status values must change in accordance of set rules. We created the effects of the abilities on enemies and play- 5.4 Abilities, Armor, Weapons and Miscella- ers during combat by scripting the triggers that lead to such neous Items change as well as the change itself. For example if an ability causes a minion’s health to drop by a certain number, the An exciting part of the game was being able to create the current number has to be changed. Along with this, the new fun stuff such as abilities, armor, weapons and miscellaneous number then has to be checked to see if it is below zero in items. This is where we were able to really showcase what which case the minion is now dead and unplayable. This is we were thinking creatively, although most of the creativity only for health. There are a number of other restrictions we falls into the scripts themselves since we are did not focus had to create to ensure that status values worked the way on the animations of the game. they were supposed to such as checking a player’s mana be- We decided that these objects were an integral part to fore using an ability or passing the current critical chance player customizability in the sense that it gives a player mo- value into a formula to calculate whether a certain attack tivation to continue playing the game. These items and would hit critical damage or not. abilities were adjusted appropriately to account for different levels in the game. There’s also an easter egg with one of the items, but we’ll let you figure that out. 6. DISCUSSION On the technical side, this aspect was nothing more than object-oriented code and defining different sorts of objects 6.1 Our Expectations that served as these items and abilities. Overall, our game was a success. We implemented the goals that we had set out to achieve at the beginning of 5.5 Player-Controlled Minion System the semester. We have a working game with a grid-based The player-controlled minion system within our game is battle system, items, and minion combat. Our minions wield probably one of the biggest pivots in our game that aligned items that boost their performance, and there are a few very well with one of the original ideas. In the beginning, we different items that can be used. We were able to create a were thinking of creating a Roguelike turn-based card game, game that combined elements from other games in a new however, we scrapped the cards when we realized that there and interesting way for gamers. was no real need for them (and animating cards is difficult). That said, there was so much that we wanted to achieve Instead, when we were making the grid-based combat sys- when we set out which we were unable to accomplish. We tem, we realized that there was a lot of empty space with also spent most of our semester learning the basic and ad- only one player which made the tactical sense of it obsolete. vanced building blocks within the Unity engine. This took While diving into the ORK Framework, we discovered that away valuable time from building the game that we envi- one of the key features is a player-controlled minion system. sioned at the start of the semester. We have mentioned that In hopes of filling the board, we decided to try the package our expectations going into the project were rather lofty. out and after putting more than one player on the board, Large teams at larger companies built most of the games we we decided that it worked better than the last way. have played, so our expectations were unfortunately higher Therefore, we decided to use this feature and began script- than what was actually tractable. Similarly, many of these ing the classes for different minions. We also were able to games have teams dedicated to creating animations for their create a stored allocation system in which players are able games. ORK?s animations helped us with this, but we did to monitor and customize their army of minions, much like not have the autonomy that we would have liked. cards in a deck. This is one of the biggest victories for us. We were able to incorporate the idea of collection through- 6.2 Future Work out gameplay by minions instead of cards thereby introduc- There are still a few ways we would like to improve our ing a new element to the strategic nature of the game. game. The first most glaring issue is the current user inter- face during battles which we realized during our live demo. We needed to explain where to click to perform certain ac- tions to the players. This is not ideal, so future work would include improving the size of the UI bar during battle as well as reducing the number of empty buttons. We originally cre- ated the bar to account for numerous different abilities that could be used by the same minion. We would also like to improve upon the number of levels and a larger storyline to accompany it. Right now, the levels are contained within one scene. This lack of content is solely because of a lack of time. If learning Unity had taken less of a chunk of our semester, we would have included more levels and a final boss. Lastly, we would like to work on the support class of minions and see how we could fit it into the combat system.

7. REFERENCES

The Darkest Dungeon. OS X version , Red Hook Studios. 2017.

ORK Framework. Version 2.24.0. 2019.

Slay the Spire. OS X version , MegaCrit games. 2019.

Rogue . Wichman , 1980.

Unity. Tutorials. Unity, https://unity3d.com/learn/tutorials. 2019.

Wizard of Legend. OS X version , Contingent99. 2019.