#unconquered queries | Explore Tumblr Posts and Blogs

ejschwartz · 5 years

Text

BattleCry! Post Mortem

Full Sail University Mobile Gaming Thesis May 2019

BattleCry!

Genre: Casual PvP War Strategy Game Platforms: BattleCry! is available on iOS and Android mobile platform. iOS version 9 or greater for Apple products; such as phones and tablets. Android version 7.0 or greater for Android phones and tablets (Schwartz, 2019). Revenue: BattleCry! restricts players to a maximum of 5 games per player. Using the IAP feature built into Unity, players can purchase additional game slots at $0.99 for 1, $3.00 for 5, or unlimited for $9.99. These purchase items are anticipated to change before production to include Heirlooms (buffs usable across games) and Audio Skins (to allow players to manipulate how other players hear their battle cry). Tools/Language: BattleCry! is developed using Unity 2018.3.0f2 and .NET C# as the scripting backend. Audience: The primary demographic for this game is male ages 14+, representing the player type Killers (Schell, 2010, p. 110). The demographic also enjoys a casual playing experience since a move for any given match can be played out in under 3 minutes. Team: Nick Penny (Technical Advisor), Evan Schwartz (Designer, Developer, and Project Manager)

Backstory

Pitch “Hordes don’t summon themselves. Battle Cries do!”

Executive Summary Using the device voice recorder players will summon a Barbarian Hord with a battle cry. This horde will include ground units, mounted units, and ranged units. It determines the numbers of each unit by sound analysis based on the battle cry of the player. After assembling the horde, the player chooses which of his heroes he will risk leading that army to take a sector. Sectors have differing terrain types that some heroes are better at than others. All sectors, even unconquered sectors, have a standing defense garrison that must be overcome by the barbarian horde. After taking the sector, the remains of the horde settle in to become the garrison and make the sector productive. Production allows the barbarian to upgrade the heroes and sustain the growing empire. In this fast-paced winner takes all game of conquest, players use strategy, and a commanding voice, to annihilate their opponent (Schwartz, 2019).

Inspiration There were two distinct levels of inspiration for BattleCry! The first was a drive, more akin to hunger, to engage the player within a game in a way that provided a feeling of being apart of the game. Reflecting on my background in the Security Industry, the biometric security triangle involves something you have, something you know, and something you are. I recall this delivering a sense of power and safety. I wanted to deliver this same feeling of power to the player by allowing them to leverage something they “are” as a mechanic into a game. Most games require thought and dexterity to accel. But I wanted to deliver a more intimate experience between the player and their opponent. Key to this mechanic is the ability for the player to master it. With the limits of today’s technology, the only part of the player I could reasonably introduce into a game, give the player agency and the ability to master, was the use of their voice. In the stereotypical male, the target audience, there is something visceral about using his voice to dominate.

The second inspiration is the Barbarian character from Advanced Dungeons and Dragons game (Gygax, 1985). I still sit around the table with friends from 30 years ago and play. AD&D is quintessentially the most impactful game of my life. One of the Barbarian’s abilities included summoning a Barbarian Horde for a particular purpose. Barbarians wore skins, used wooden and stone items with minimal access to metal, and were generally primal. The Barbarians primitiveness fit well with the cathartic and primal nature of roaring into your phone, watching it manifest into victory!

Ideal Having the ability to hear my opponent’s battle cry gives me a connection to my opponent, I do not typically get from the game board. I can derive that my opponent is nervous or desperate by analyzing their moves; however, hearing the tremble and cracks in their battle cry seals the deal. As players create battle cries and see how they manifest armies, they will learn how to adjust their voice, modify their cry to maximize their summoning potential. Mastering the mechanic will lead to personal confidence because they are mastering something that they “are.” Ideally, this novel approach will generate interest in BattleCry! and making it successful.

Demo Screencast:

Link to BattleCry! final Screen Cast: https://youtu.be/a0SiXYH44bY

youtube

The Critique: What went right?

Design & Aesthetics The Game Design Document (GDD) was likely the most successful part of the planning. The document does a fantastic job of identifying RESTful services, hosted on Azure, with a SQL Backend making the development of the backend infrastructure a breeze. I required only minor filter changes of the stored procedures or services during development, demonstrating the robustness of the design. There were fewer than 2 or 3 tasks assigned to adjust the data layer or service layer throughout the build to facilitate functionality. The documentation was a huge success in planning. One of the identified risks at the beginning of this project was the inexperience I had with multi-player games on mobile devices. I had never developed a server infrastructure to allow players to take turns in a game, store persistent storage across devices (Android and iOS), or built the necessary services layer for a mobile game to work in this fashion. The strategy identified areas that would be force multipliers. I knew I would be a one-person show on this development and is responsible for the SQL Database, interface to the data, design of the database, the RESTful service layer, and the piping back and forth I needed to develop the simplest architecture possible.

The first thing I did was start at the Database. I created the concept of “first-class” columns and then Meta-data. A First-Class column is one I’m going to query on or need to index the table for querying. Meta-data was all the other facts necessary to drive the game. To minimize restructuring on the schema throughout the build I spent a lot of time on First-Class columns and then relegated the remainder to XML based columns that could easily grow, change, and modify without having to change the piping, service layer, or access logic. If I needed to track a new parameter, I added it to the XML body and stored it in the DB. Metadata was relevant to the Application layer, so all the Data Layer needed to know is how to store and retrieve it.

Designing the database in this fashion allowed agile changes to occur without major restructuring of any of the access services. Essentially, I can manage the entire game with only three tables and one utility table for analytics and triage.

The dbo.Error_Log table has become a standard addition to any project that involves data. Which is almost all of them. With the introduction of exception handling in stored procedures for SQL Server 2005, this simple construct reduces triage of data and access errors by 90%. I introduced this concept professionally 14 years ago and have never looked back.

The key to making this work is never directly accessing the table data. Using a Read/Write service architecture, all access to the database goes through Stored Procedures. There is much debate over the use of stored procedures. However, with limited resources applying the law of Demeter to data goes a long way for maintenance ability. The Service layer knows nothing of a table name or its associated columns. All the server layer knows are the stored procedures and the data they return.

Each stored procedure is either getting data or writing it. Using a read/write abstraction frees me to make any changes at the schema level, I wish without breaking any code. None of the code knows anything about the tables or their columns. Stored Procedures give me a programmable method to mitigate changes and simplify the process. The next hurdle is how to abstract the interface of the services to the prototype of a stored procedure. Passing parameters to a stored procedure are as bad as the code knowing about table names or columns. If you change the parameters, you then need to change the code that accesses the stored procedures. When you consider this, it is easy to see why most developers argue against using them. You’re shifting the problem from tables to stored procedures with minimal gain. My approach, however, is to solve this problem. Give every stored procedure the same prototype. XML saves the day here again.

Since the parameter is XML, it can contain anything that the stored procedure needs. Following this methodology means if one call needs to pass five parameters of data and another needs to pass 10, the @filterdata XML contains more data. But the calling program still only needs to pass one parameter, thus keeping the prototype of the procedure homogeneous. Inside the procedure, it opens up the XML, inspect it, and then behaves appropriately. The benefit of this strategy is minimizing the touching of code. Only the piece of code that passing the data and the stored procedure needs to change. None of the piping in between is touched. I call this “edge development.” This architecture dramatically simplifies the passing of data to and from the datastore.

Secondarily, this gives stored procedures a built-in version control. The passed parameters can include a version number, or the procedure can react based on the existence or absence of data. Thus, if a later calling method needed data sent differently, it passes in a different filter, and the procedure responds based on that filter request. It still handles previous calls the same way. So, the same procedure is servicing older and newer requests without breaking anything.

At the UI layer, the game serializes the object data into JSON and passes it to a RESTful service.

At the service layer, data is deserialized and then processed into an XML based filter data parameter and passed to the stored procedure.

The only thing the service layer needs to know about the procedure is its name that it accepts an @filterdata XML parameter and at a minimum, every procedure returns ErrCode and ErrMsg. Everything else is suspect and tentatively accessed.

While this sounds verbose, the result is a very agile, and maintenance means to access data and write data. As needs change, minimal code changes are required only at the endpoints allowing a one-person show to maximize their time and leverage this architecture as a force multiplier. Without this architecture in place, there is no way BattleCry! would be completable by a single person in 9 weeks of development.

Project Management The use of Full Sail’s Underdog site facilitated the management of the project allowing efficient translation of the GDD into actionable tasks and having the ability to visualize the GANTT chart allowed for time management and negotiation around change management. Due to the size of the project and limited resources, breaking the project up into manageable milestones and then working those milestones to completion is singularly the most impactful attribute of BattleCry!’s success. After each milestone, a reflection period and collection of backlog items occurred to ensure that the project was targeting the primary goal and that planned functionality produced the desired result. In some cases, feedback from the milestone demanded changes that spilled over into the following milestone. Ultimately, I categorized backlog into two sections: Immediate and Delayed. I needed to address Immediate backlog in the following milestone. So, having the ability to input the tasks, assign an effort, and ensure there was enough bandwidth in the given week to deliver the milestone could not have occurred without the management portal on Underdog. Delayed backlog remained in a milestone named “Backlog” and would be pulled into a weekly sprint milestone as bandwidth allowed. Organizing the milestones in a foundational contingent hierarchy ensured that minimal refactoring was required. I dedicated the first three milestones to architecture, backend services, and utilities. Spending a third of the project on work-items with no observable progress can affect morale. However, my experience has proven time and again, that investing the time up front into these critical pieces streamline the rest of the production schedule. Risks were easy to see and manage throughout the build allowing stakeholders to assess exactly where the project is heading and how best to mitigate issues to ensure success.

Development

With the architecture of the SQL Server and RESTful services decided, the next decision was how to host BattleCry! Where in the cloud would BattleCry!’s backend live? My experience with the Microsoft stack of technologies made Azure™ the obvious choice.

I needed an App Service and a SQL Server hosted in the accessible cloud. Setting up the Azure account was straight forward. But, learning how to configure the Azure firewall services, set up a SQL Server, and then provision a GIT repository for deploying the App Service took some training and tooling up to get done. One of the obstacles with Azure SQL was the loss of the SQL Agent. The SQL Agent is a scheduler that will execute stored procedures or execute SQL Code on schedule. Having a scheduler was critical to service some of the maintenance and clean-up items for BattleCry!. After some research, Azure provided an answer. They call it the Scheduler Service, but essentially it will execute an App Service (RESTful End Point) at a given time each day. Using this service, I created a general use Daily-Maintenance Endpoint that called a single spDailyMaintenance stored procedure at a specific time each day. Based on the criteria (filter data) passed, this maintenance procedure would perform specific clean-up tasks such as clearing out inactive games, abandoned games, stale player’s turns, etc.

With the Azure Scheduler in place, I had all the infrastructure in place I needed to support BattleCry! Across multiple devices and players. Deployment of changes to the App Service is as simple as pushing code into a GIT repository. Being a programmer usually means I have, at best, a secondary mastery of infrastructure, servers, and networking. Azure made setting these services up and making them readily available a breeze. Without this BattleCry! would never have gotten off the ground. It would have stalled at Milestone 1.

With the architecture and infrastructure in place, it was time to start developing the game The GDD made development almost apodictic. Unity is very intuitive and easy to use, making the layout of the scenes a matter of doing it. Building an application with minimal risks and unknowns is pleasurable.

Going into this, the number one development risk, however, was the Battle Cry mechanic itself. One of the key requirements is that the battle cry provides a means to the player for mastery. To meet this requirement means that given a similar battle cry, the player should expect similar results. Developing a visual debugger to see how the recorded audio wave for the BattleCry is processed was key to developing this consistency.

One piece of the visual debugger was the output panel showing the results from the battle cry. In figure 13, we see that out of 24000 samples; Infantry scored 2632 summoned units. The result of the FFT value for sample 281 of the first 8000 samples of the audio recording is the value dictating this result. Selecting the Infantry segment of the audio wave, the Inspector shows the details.

From the property inspector, we can toggle on the audio wave data as well as the FFT wave data to compare the results.

When we show only the FFT data, we can see a spike at approximately the 281st location.

To confirm the results, we can expand the FFT Data from the property inspector to see the raw data at location 281.

If we run the Battle Cry formula on the value which is [FFT Sample] * 1000 * 20, we get 0.1316096 * 1000 = 131.6096. Taking 131.6096 * 20 = 2632.192 or the calculated interger amount of 2632 Infantry Units summoned.

Having the ability to validate the player’s battle cry results I was able to tweak the formula to ensure that as the player saw the results of the battle cry played back to them, they could begin to perfect and master their technique.

When I introduced this visual aid to the game, players immediately began mastering their battle cry techniques and went from summoning small hordes to terrifying hordes of conquest!

Testing The user testing was the main facet of development that I looked forward to conducting. Testing occurred about every three weeks, or ever three sprints. Each time setup testing, I included a player that had never seen the game before as well as players who had previously seen it. I wanted to get first look feedback as well as confirmation that I resolved backlog items. On first looks, players struggled to log into the game and create an account. By the end of the nine-week sprint, I had resolved all issues except two: Game Management and Combat. I could resolve both issues with a little training. From there, the players were off and going. But, that isn’t good enough. Players need an intuitive interface that helps them understand how to play or to figure It out — having run out of ideas on how to make these concepts more intuitive; It was the Usability Testing sessions the had the breakthrough.

Two surveys were used to collect data the Play Experience Scale (PES) and the NASA TLX survey to test workload.

The freedom score was low, demonstrating that players felt like they couldn’t do what they wanted to do, but they wanted to play based on the play-direct, no-extrinsic, and autotelic-focus scores.

For the NASA TLX score, the following results fortified the same feeling.

Players ultimately were frustrated by not knowing what to do and further by not being able to do what they wanted. During this test, I was able to see, for the first time, what the players were struggling to do. They wanted to play their game after they created it, and when playing, they wanted the information at their fingertips. They didn’t want to have complex gestures or have to search for what to do on the screen. The usability testing led to the most significant breakthrough in the game, which, when implemented, should make the game extremely intuitive and easy to play.

Audio The sounds effects and music for BattleCry! are sparse and explicit. The clicking sounds for activating buttons is audio feedback that the player is interacting with the screen. The background music is jovial and sets the mood well for an ancient war theater. The dropping of coins elicits the purchase of items. The fighting sounds of yelling and clashing swords sets the perfect tone for either the horns of victory or lonely echoing crows of defeat. This minimalist approach to audio was intentional and effective to highlight the one sounds that ties this game together: The Battle Cry.

As you play BattleCry! the audio mechanics fade into the background keeping the start of the show front and center in the player’s mind, their opponent’s or their battle cry. Throughout the game, this audio is accessible and available to the players. By design is meant to be the prominent audio effect. BattleCry! achieves this expertly by minimizing the need for other audio effects.

Swipe: https://1drv.ms/u/s!AjsWFZEVKvrPhK004kxPW3vxfRzXnA

Background: https://1drv.ms/u/s!AjsWFZEVKvrPhK03Y_Fy_aPzjogvmw

Horns of Victory: https://1drv.ms/u/s!AjsWFZEVKvrPhK06lwvpCBA5L3OcDg

Button Click: https://1drv.ms/u/s!AjsWFZEVKvrPhK02u97svGFqFrSbTQ

Crows of Defeat: https://1drv.ms/u/s!AjsWFZEVKvrPhK07t2LNglkeS8OZrg

Battle Sounds: https://1drv.ms/u/s!AjsWFZEVKvrPhLwsBg7Ar1xYj1D-rA

Attack Hits: https://1drv.ms/u/s!AjsWFZEVKvrPhLwrIyL3FK0QMDqfsg

The Critique: What went wrong?

Design & Aesthetics When you review the design document, there was enough documentation around game mechanics and basic play to allow development to proceed with minimal risk. LucidChart™ provided nice prototype layouts to test design ideas streamlining the assembly of the UI for the project. However, I did not catch many of the learning curve issues experienced by the players within the design document or the prototypes. Not catching these design flaws was frustrating and costly to the project. The problem is that the prototype designs were coupled too closely to the mechanics of the game and not tested independently. A payer that knows how to play, the UI is obvious. Someone who has no idea what the game is about, the UI is confusing. If I had an opportunity to do it over again, I would have carved out the UI screens and presented a user with the paper prototypes to assess how intuitive the actions of play would be. Taking this step would have caught the negative user experience of creating a game and then having to wait for a player to join it. It might have been easier to catch interaction issues with the map by watching players interacting with the paper prototype. By asking them, “Looking at the map, how would you go about telling the application that you want to attack a hex?” It is likely that testers would have selected the hex they wanted to attack first, exposing a flaw in the current design early enough to do something about it. The LucidChart™ screens directed the player in what to do, skewing my results. Ultimately, this is a novice error on my part. By linking the prototype sheets together to create linked-sheets for a pseudo-working prototype, I inadvertently led the playtester on how to interact with the prototype. So, while LucidChart™ facilitate this issue, the truth is my inexperience with this process caused it.

I could easily have removed the notes and linking on the page before presenting to a tester to observe the same results paper would produce. The test delivered on computer, it was too natural for the player to fish around the interface to see where their cursor changed to find the correct place to click. When I do this again, I will not link these sheets. I will treat it more like a paper prototype, and as the player interacts with it, I will remove and display screens based on what the player selects. Looking back at how much time and energy was spent trying to resolve the “Create Game” and “Battle Mechanic” issue, the investment would have been well worth it finding this during the design. I’m now faced with two to three weeks of re-development to fix this. Having caught this in prototyping, I could have experimented and resolved it in two or three days.

Leveraging a new technology that will work as a force multiplier is always worth investigating. However, I’ve learned to weigh the anticipated gains against the actual efficiency of a tool the team knows and has a successful process using. The deception I caused to myself using LucidChart™ was so convincing that the flaw went unaddressed for several milestones.

With the failure to catch two critical design flaws in the game during the planning phase, the game creation process and combat movement plagued the project throughout development.

The design for BattleCry! was to create a New Game with a battle cry. After creating a new game, it is in the Pending Games list. The pending list is where your games wait for other players to join. The Open Games list were games other players have started that were available for you to join The Active games are games currently being played. The entire concept of starting a game and waiting for someone to join it was foreign to players. They were baffled by it and couldn’t understand why they couldn’t play the game they had created. With each test, cycle, players had to be lead through this process. Ultimately, the decision is to rip this out and allow games to start immediately with a random or direct assignment to players. If the player doesn’t take their turns or rejects the game, the player can create a new one and try for another player. The objective here is that the player is immediately in the game making their first move.

The other major obstacle was combat. My wife has a saying, “Exactly the same, but opposite.” Until this project, I’ve always felt that comment was nonsensical. To most of her friends, it makes perfect sense. To me, you’re telling me it is exactly like something, but nothing like it at all. It’s the opposite of that thing. Well, after this project, I’ve had some tall-apologizing to do. The combat sequence I designed needed to be exactly the same but opposite. I can’t begin to tell you how much it pains me to say that. During combat, I asked the player to select the hex they were attacking from, then the hex they wanted to attack. Every tester wanted to select the hex they wanted to attack first. Selecting the hex they wanted to attack is one of those things that you know is correct because of how obvious the answer is once you see it.

The other major issue with the combat system is that the command to attack is at the bottom left of the screen, while the player’s focus is on the map on the hex they want to attack! Honestly, this is just bad UX design. I wish I had an excuse or brilliant explanation for why the commands are at the bottom of the screen, but I don’t. After the Usability Testing exercise it was obvious what to do; spoon feed the player through the combat sequence using dialogs and allow the player to do what they naturally want to do; which is select the hex with which they want to engage.

While this sounds simple, which is why I know it is the right answer, it will take two to three weeks to redesign this workflow for combat. In the end, it’ll be worth it. But I should have caught this during the design phase. On my next project, I’m going to elongate the design process and add additional prototype testing to the schedule. The investment at that point is well worth it.

Figure 12 does a fantastic job of showing off the aesthetics and artwork of the game. Aesthetically I feel the game met its objective. However, artistically, it needs an expert touch. I am compelled to list it as “what went wrong” only because I am not satisfied with it. I knew in the beginning that my limitations on the artistic side of things would be a risk and noted them in the GDD as such. While this isn’t a surprise, I would be remiss if I didn’t speak to it. The attention to graphics was intentional and meant to be “square” to establish hard demarcation in the layout. I suspect an artist would be able to create a more organic feel using the cool earthly colors and wood-like and primitive materials.

Project Management There were times I almost lost hope during the development. My work schedule went from predictable to the extreme. I found myself transitioning from a 25% travel to more than 75% travel in a very short period. Adapting to this new condition was challenging. None of my contingency plans for the internet were viable since I never knew where I was going to be from week to week. One week I would be in Mexico where the internet was spotty at best and the next in Boston. A week home then two weeks in the UK and Ireland. I had decided early to use the MacBook Pro from my Undergraduates as a Windows laptop and preserve my MacBook Pro from the master’s program as a MacOS laptop for iOS development.

All of this travel meant I was traveling with two full MacBook Pro laptops, both my Work Laptops (MS Surface), 5 Tablets and all the cables, mice, and accessories necessary to pull it all together. My backpack weighed 66 pounds as carryon luggage for my flights. Packing and unpacking the equipment, getting it through security, trying to work on a plane, and making do with whatever internet the hotel could provide put the project at risk more than any other challenge. During the program, the company I worked for was bought out by another company, and I thought, at one point, I would be without a job. Instead, I ended up landing a key executive position that demanded 50 to 60 hours a week. I was already putting in 30 to 40 hours a week at school. This grueling schedule has taken a toll on my health. I’ve been sicker in the last few months than most of my life. In the end, however, the struggle was worth it. One of the key objectives, personal objectives, for me, was to make sure that I had enough knowledge and time to start my own independent gaming company after graduation. I had tried several times to start a small business and work a full-time job in the past and ended up putting less than part-time effort into the endeavor. As you can imagine, they failed. After graduation, if nothing else, I’ve proved to myself, my family, and my investors that I have what it takes to put the effort in to make my company successful. I have tested my grit in ways I didn’t think I had the strength to overcome. Emerging out the end of this experience, I am confident I can deliver on anything I set my mind to accomplish.

I’m a 10X’er (Cardone, 2011) and have followed Cardone’s teachings for years now. Time and again, I find myself on the brink of being overwhelmed. Each time, I have found a way to overcome. When it comes to investors money and the time away from my family, I may not have the luxury of being so cavalier. But, it was important to test myself to the point of the break, if for no other reason, than to prove to myself I could do it. Dialing back the scope of the project would likely have reduced risk and still met the requirements of the program. However, that isn’t me.

Development

My background is more traditional; component-based coding is a new concept to me. One of the things I still need to do is some housecleaning on the code. I’m not suggesting that I have broken or buggy code, but from a maintenance standpoint, some of the component-based modules, such as the “GameController” are massive. It needs to be broken down into more discrete code segments for easier maintenance and reusability.

The List codebase could use a good object-oriented review. Each list is so similar there must be ways to manage this code for reusability across the list interfaces hierarchically. Early during development, each list was kept separate, expecting unique code segments to manifest during discovery. However, they ended up similar enough that a parent class could house most of the common code with inheritance and extending the class for the child classes to cover the unique parts. Again, for maintainability, this code will be refactored and structured more compassionately, making it easier to make changes to all lists with minimal code modifications. The lesson here is to have faith in fundamentals. I let the fear of the unknown go against my better judgment, which ultimately, is going to cost me the time I shouldn’t have to spend cleaning up the code.

Testing

During the first User Testing session, the number of things that went wrong was numerous. While the intent was to get user feedback on the design, I tripped over the different types of devices that my testers had. Getting the application loaded across Android and iOS devices took up more time than It should have. On subsequent tests, I made sure to have my deployments ready to go in advance of the test. Another critical oversight was making sure that everyone’s volume was turned up since BattleCry! depended so heavily upon sound. During my first test, I was targeting a younger audience and underestimated how much being recorded affected their responses. On subsequent sessions, I found spending some time up front with the camera lower to my chest, out of site, and away from my face, helped to get a more realistic response from testers. After the recorded session, on the first test, the testers were far more open and provided much more actionable feedback. Realizing that the recording was skewing results, this led me to evolve a non-recorded followup review of the game to record their reactions and thoughts. Below is the recording of the first sessions. The recording is very early in the development of BattleCry! and highlights the confusion around creating an account and creating of games.

https://youtu.be/HxeRyI5HXNc

youtube

References

Cardone, G. (2011). The ten X rule: The only difference between success and failure. Hoboken, NJ: Wiley.

Gygax, G. (1985). Unearthed Arcana: A compendium of new ideas and new discoveries for AD & D game campaigns ... Lake Geneva, WI: TSR.

Hart, S. G. & Staveland, L. E. (1988) Development of NASA-TLX (Task Load Index): Results of empirical and theoretical research. In P. A. Hancock and N. Meshkati (Eds.) Human Mental Workload. Amsterdam: North Holland Press.

Online Diagram Software & Visual Solution. (n.d.). Retrieved January 5, 2019, from https://www.lucidchart.com/

Pavlas, D., Jentsch, F., Salas, E., Fiore, S., & Sims, V. (2012). The play experience scale: development and validation of a measure of play. Human Factors: The Journal of the Human Factors and Ergonomics Society. 54(214). DOI: 10.1177/0018720811434513

Schell, J. (2010). The art of game design: A book of lenses. Amsterdam: Elsevier.

Schwartz, E. (2019). BattleCry! [Mobile application software].

Schwartz, E. (2019). BattleCry!, Artistic Critique Document. Unpublished work, Full Sail University.

0 notes