Capstone Postmortem: Evolve or Die

Capstone Postmortem: Evolve or Die

Evolve or Die

Game Summary:

Game App Icon

Title

Evolve or Die

Genre

Action / RPG

Platform(s)

Android

Revenue model

Interstitial ads periodically during menus

Development tools/Language

Unity3D / C# Scripting

Game audience

Ages 10 – 40

Primarily developed to allow the largest target audience however between the learning curve and reading requirements it kept the audience between a certain age range.

Team

Matt Fenderson – Programming and Design

Copyright/Reference - cite yourself

Matt Fenderson (2016). Evolve or Die [Mobile Application Software] Virginia

Backstory:

Sound Bite

Challenge your opponents with a fight to the death, win and be rewarded with experience to evolve.

Executive Summary

Co-op online multiplayer matches, play with others against AI in a fight to the death to win your rewards in which you can use to gain more power.  Play as a creature that can grow and change into much more, choose your path and determine your own destiny!  Each player can choose to follow a path that suits their play, these paths branch and allow their play to grow and change into much more.  While other games may pit you against your enemies, never have you done it in such a unique manor of evolutionary style!

Inspiration

Many RPG’s and Action games such as Diablo, but with a different play style, in what I like to call a “Leveler” where the fun comes from building upon your character and growing. 

Ideal

While many games play a single protagonist I was going for something slightly different in which you play as a morphing and evolving creature that while you have your main game player leveling it unlocks and allows your actual physical being to change, unlocking additional stats and “abilities”.  Hopefully as this game in itself evolves, additional special attacks can be associated with each creature to truly unlock special attacks that could have effect on gameplay to give more reason for choosing between which creature the player would want to be.  The original concept of the single attack method was developed to ease learning time and make playing on mobile platforms easier.

Demo Screencast:

Evolve or Die Screencast

The Critique: What went right (Please include screenshots where appropriate)

Design & Aesthetics

Terrain Development

While a lot of design issues arose while creating Evolve or Die, one of the things that did go right was the terrain development, initially I had thought to use a single layout and swap out some textures to keep resources low while making it look like you’re in a different place, however it did not have that effect, it was very clear that the arena was the same thing with different textures.  So I had to go back and look at this, which I am very happy for, above are a couple full views of the terrains that players can play in, while still requiring flat areas to be walkable having the 3D elevation and extra detail for each terrain really helps get a player immersed in the scenery.

Project Management

I utilized Sourcetree as a UI for committing my project to Underdog Repository.  This helped enable me to keep backups and be able to revert to solid builds in case of something going wrong.  One practice that I utilized was prior to “risky” development or changes, I would commit a current state of the project with comments of what I was about to attempt, this enabled me to have a specific launch point if that risky process did not pay off and I just wanted to go back to a solid state.

Development

The best thing that happened to this entire project was the requirement for a complex AI, I developed an editor tool that would become a layout for easily selecting maneuvers in certain situations that allowed for the aI to pick the best possible maneuver given the current state of the battle.  This process utilized intrinsic indicators, parameters that are inherent to the match, such as the player’s creature types, number of players and the AI creature type.  This was cross referenced with extrinsic behaviors, things that are currently happening to the match that change over time, such as is the player moving towards the AI, player’s current health and AI’s health.  With as little as 3 modifiers (3 intrinsic and 3 extrinsic) I would have up to 21 potential situations that the AI would be able to pick the best behavior.  In my current build there are 525 possible situations that the AI can analyze!  Additionally, I have created the tool to programmatically build the combinations to allow for an increase/decrease in parameters as needed so as not to have to hand create each of the possible lists.  Also, each of the maneuvers (the option that can be selected from) is created as an enum so as additional options are created they are stored in the option list to choose from.  Here is an example (part of it) of what the tool looks like in use:

So simple and easy to use yet powerful to allow the AI to deduce the best choice for the situation, furthermore keeping a very organized layout to allow making changes stress-free.  

Testing

Testing was conducted on a multitude of devices, including the Bluestacks emulator, the target device (NVIDIA Shield) and some various smart phones.  This helped to ensure that lag was limited and that no matter the screen resolution the UI and camera worked correctly given the various devices.  Additionally, profiling was conducted through ADB (Android Debug Bridge) connection from Unity3D to the Shield device to get more real time profile updates from the actual device.

Business Model/Plan

In creation of Evolve or Die I relied on assets I developed, creative commons assets (freesound.org) and free assets from the Unity Asset store.  This kept costs down to nothing and allowed for quickly implementing design and layouts of environments.  Additionally I utilized the Google Admob package for Unity, which has no cost and simply requires an account (also free), to be associated with the Unity Game.  Utilizing the Google Play Game Services I was required to purchase the Developer License in order to enable cloud save and multiplayer which had a cost of $25 (Good for life).

The Critique: What went wrong (Please include screenshots where appropriate)

Design & Aesthetics

One of the largest design flaws in Evolve or Die are some of the feedback loops not entirely providing appropriate reactions to player’s inputs.  For example, as player’s level up and unlock new creature evolutions there isn’t any feedback as to this happening, a player would need to intrinsically know to check what level they are and look at the evolution tree to see any new creatures available.  In the future this could be fixed by providing animation screens of the new creatures being unlocked as well as level up notifications to show a player that something important has happened.  Ultimately I have found that my major weakness in game development is design, having this knowledge will really help in my progress as a game developer and I can focus on this weakness while relying on my strengths to push through and make myself better.

Project Management

While focused on development only, there were a lot of design related issues that could have been looked at, unfortunately due to time management and the development tasks already assigned this got pushed out of the picture. 

Development

While developing the AI Selection matrix there was some tricky issues happening that caused a lot of extra time to be wasted because the problem was not readily apparent.  The AI Selection Matrix utilized a 2D array [,] that associated the maneuver enum assigned by the user.  Unfortunately, unknown during the initial development these 2D arrays are not serialized, which means that as soon as the game was played the array was initialized and cleared out.  Once seeing this I wrote to the player prefs each of the array positions index of the enum, again unfortunately not thinking about where player prefs are written once the game is built for android the editor player prefs are not saved nor do they go with the android build.  As this happened later after testing I did not upfront realize there were any issues as the AI was still attacking the player (although it only used the default charge attack) but I had no reason to believe it was going through selecting any other choice.  Luckily, I had eventually decided to set all choices to hit and run and play on android to see how it looked, at that point only seeing the AI charge I had the realization that player prefs is specific to the device.  In order to overcome the base problem of the 2D array not being serialized I essentially took it and wrote it into a single array (row * column) which allowed Unity to serialize it and save my changes.

Testing

User testing was a huge boon for me, I was not able to get my primary audience to test my game periodically as the majority of people who were available to test my game were not of the standard type that would play it.  I had two ends of the spectrum age wise yet neither primarily plays this type of game, and those that were in the middle age spectrum were not really gamers.  While it did help to provide some inherent user interface problems having the actual feedback from a gamer that likes this type of game was not readily available.  An open public alpha testing may have helped however getting appropriate feedback in a consistent standardized form would have been a problem and would have caused a lot more time to just decipher the feedback that was provided.

Business Model/Plan

The interstitial ads cause a lot of grief for players, it takes them out of the game and forces them to focus on something else.  Also, getting the right amount of ads between menus seemed to cause issues as well, having more ads of course means more money however to many ads will drop your players interest.  I may go back and look at this and may look at doing banner ads during gameplay and only interstitial between the main game and menu (plus on game exit / open).  This will help to keep the player playing during normal times and only as they are in-between playing and changing settings do they get interrupted.

Summary:

I have learned a lot through this whole process, my strengths and weaknesses, and by determining these I hope to be able to focus my attention and improve upon both.  Identifying my weakness in design has really helped open my eyes to what it is and how it really benefits a game to being fun.  As I am primarily a developer/programmer I tend to focus more on getting things to work and function, seeing how giving some focus to design can really turn a well-functioning oiled machine into a fun playing game can help to keep a player interested and wanting to play.  I’ve always seen it as if the game is laggy and functions poorly that will quickly turn players off, but additionally without some kind of focus on feedback for the player it really doesn’t matter how many bells and whistles are running in the background if the player doesn’t care to stick around to find them. 

References

Atwood, J. (2007, 07 04). Game Development Postmortems. Retrieved from Coding Horror: http://blog.codinghorror.com/game-development-postmortems/

Bevilacqua, F. (2013, 10 24). Finite-State Machines: Theory and Implementation. Retrieved from envatotuts: http://gamedevelopment.tutsplus.com/tutorials/finite-state-machines-theory-and-implementation--gamedev-11867

Fenderson, M. (2016, 03 19). Evolve or Die. [Mobile Application Software]. Virginia.

freesound. (2016, 03 19). Retrieved from freesound.org: http://www.freesound.org/