Capstone Game Post-mortem: Sensor Dev

Capstone Project Postmortem: Sensor Dev

Project Summary: A plugin for Unity3D to provide access to all sensors available on Android platforms.

Author

Jonathan Burnside

Title

Sensor Dev

Genre

Developer tool set

Platform(s)

Unity3D with Android as the platform target

Revenue model

The tool set will be sold on the Unity Asset store for $30.00.

Development tools/Language

SensorDev was developed using Android Studio and Unity3D development tools, and was programmed in both Java and C#.

Project audience

The intended audience for this project is game developers and designers wishing to add sensor support to their games and products that are not currently supported by Unity3D. These developers and designers may either not posses the skill sets needed to access these sensors, or may represent those that would rather purchase a tool set than develop, test and polish the functionality themselves.

Copyright/Reference

SensorDev © 2016 Jonathan Burnside

 

Backstory:

Sound Bite

Your players have sensors, now your games can too!

Executive Summary

With this pack you will be able to easily integrate and use all Android sensors, including those not supported by default in Unity. The tool set supports all standard Android API sensors as well as those provided by the hardware manufacturer of the device not defined by the Android API. The tool set also provides support for networking sensor values from an Android device to a build running in the Unity Editor, allowing the developer to quickly test and debug without having to constantly push new builds to a device.

Inspiration

Multiple courses in the MGMS program had developers use sensors for game-play elements. These tasks were extremely easy if the sensors that Unity provides were used, such as the accelerometer and gyro, but would be considerably more challenging if using a sensor that did not have default support. After researching how to access these sensors I found it would require multiple development platforms and languages to implement. I believes this additional complexity would reduce the average user of Unity3D's ability to access these sensors, indicating that a tool set providing this support would be a viable product to sell on the Unity Asset Store. 

Ideal

The original ideal version of my product would consist of two distinct parts, the tool set and an application that would demonstrate how these sensors can be used in a game setting. The tool set would provide sensor access in three forms: direct from Android, data converted to common use cases and Unity prefab objects that could simply be added to in the editor. The demonstration portion would consist of a 3D scene that would have used most of the sensors as part of game-play elements.

 

The Critique: What went right…

Android Studio

When I started this project Android Studio was still relatively new and not all developers had started using it in favor of other editors such as Eclipse. This made me concerned that Android Studio might be missing support that the project would require. I became particularly worried when I realized that Android Studio did not have a built in path for creating a JAR file (Java Archive (JAR) Files), which I planned to use as the package for my Unity plugin. This did not prove to be an issue as I was able to first provide support myself for creating the JAR file, then later discovered that Android Studio's built in package file system that creates AAR files also worked as a plugin for Unity (Create an Android Library).

Unity Asset Store art

The tile set package I purchased, titled "Village Interiors Kit", for creating the demonstration portions of the project worked wonderfully. It had assets for exactly what I had in mind. What I did not expect was that it would also come with a demonstration level that was already better than I could likely create myself. All I had to do with the assets was add a roof and some optimizations for mobile platforms.

The starting point in the SensorKeep scene, made from a purchased tile set from the Unity Asset Store.

Light Mapping and Occlusion Culling

Light Mapping and Occlusion Culling, while time consuming to calculate, adding these features to the scene I purchased was all that was needed to get a strong frame rate on the weakest mobile devices I had available.

A picture of the visualization of the Occlusion Culling system in Unity

Feature creep

During development I realized there was no simple means by which the actual values of the sensors could be debugged, at least not from Unity. Using Unity remote would give you the values for the sensors Unity supported by default, but my tool set would be running on the local development machine instead of the mobile device, so no sensor data was available. After speaking with my adviser, we agreed that support for debugging these sensors while running a build in the Unity Editor would be very useful, and my second month of development was spent implementing such a system. The resulting system uses Unity's server/client networking to pass sensor data from a device back to a build of the project running in the Unity Editor on the developers machine. This allows the developer to not only debug the sensor values being used, but also allows for much more development and testing to take place on the user's computer without pushing to a device. Pushing to a mobile device from Unity takes a fair amount of time

External responsibilities and distractions

I can't say that I would suggest anyone try to complete a Master's degree while taking care of two children under the age of two and working a full-time job, but these distractions did have at least one positive effect on myself. They forced me to think through my development process more than I typically would. I tend to be somewhat of a brute force developer, preferring to have only a very sparse high level idea of what I am going to do and figuring out most of the details along the way. The benefit of this bottom up approach is that I do not spend time designing things that may ultimately not work out. The draw back is that the final results tend to be less modular and organized. While I am still no fan of doing a great deal of pre-production planning, spending so much time with my arms filled with children forced me to think through some tasks in greater detail than I would previously, and the result was that when I finally did get to sit down and code, things tended to work out a little better and go a little faster. While I still think that most traditional wisdom on pre-production would have you plan to a detail level that is almost guaranteed to not be what is ultimately developed, doing more planning than I have in the past likely improved my results on this project.

 

The Critique: What went wrong…

Networked Debugging system

While this system proved extremely useful once complete, and is one of the features that sets this tool set apart from similar tools, it also took quite a bit of development time. The system itself did not take long to implement to a base working level, but this feature broke many times as other portions of the tool set were developed or adjusted. When working, the system allowed for debugging of sensor data but I did not have great tools for debugging why those values might not be networked when the system broke. Due to this, I was left to debug based on asserts and log files, which are not as informative as an actual debugger.

Demonstration program 

I had many unplanned for issues with the demonstration portion of this project. Most of the ideas I had at the start of development on how to use the sensors in generic game-play systems did not pan out. I was also of the opinion that while I developed the demonstration portion more ideas on how to use sensors would be reached intuitively, this was not the case. There are quite a few different means by which these sensors can be used for games, but trying to put them all in one homogeneous system did not work out. 

The Raw Sensor data scene, while not very exciting, gives an example of how to use every sensor available on a device.

Step Counter & Step Detector

I intended to have an option for translating the player based on either the step counter or step detector sensors. Unfortunately, walking in place is not detected by these sensors. Actually walking around in the real world while staring at a non-AR scene would result in people bumping into things. The step counter and detector can be faked into believing the user is walking by shaking the device, but this made it impossible to see the screen, rendering it useless. I added on-screen virtual controls for translation instead.

Proximity Sensor

I had planned to use the proximity sensor as an indication that the player was about to try to touch something on screen. This could be used to slow down game play elements  which would make it easier to touch fast moving objects. I quickly realized that the on-screen controls used for translation in the Sensor Keep scene would cause the proximity sensor to always trigger. This general concept may work for a game designed with this in mind, but it was not going to work for my intended use.

Light Sensor

I intended to use the light sensor output to scale the brightness of the lighting in the scene. This technique worked fine on my development machine, but mobile devices required that I baked the lighting in order to get a decent frame rate. I then tried adjusting the size of the particle effects used to represent lights in the scene based on the light sensor. This worked in practice, but was rather subtle in its result. Since the effect was so subtle, when I had testers try the scene they never noticed that this was happening. I considered adding a tutorial like system that would tell the user what sensors were being used for what, but this felt like a bad path. It was after this sensor that I decided the general idea I had for having most of the sensors used in the same scene was not going to work out as I intended, requiring that I redesign or re-evaluate this portion of the program.

External Responsibilities and Distractions

Had I been able to consistently dedicate 40 hours a week to this project, it would have likely been further along after two months than it is today. Even being able to consistently get 20 hours in a week was well beyond what I was able to dedicate to this project most of the time. Luckily, while life did not allow me to sit at my PC and develop as often as I had hoped, it did allow time to think about the project which as mentioned improved my work rate when I was actually able to put time towards development.

Testing

Getting external sources to test the demonstration portion of my project has been very easy, and very helpful. On the other hand, I have not been successful in getting anyone with development experience to try out the tool set. I will not be comfortable releasing this product without some external sources testing the tool set portion of the project.

 

Summary:

At the completion of my time in the MGMS program there are still three main tasks I would like to complete, and test, before I would be comfortable releasing this tool set to be purchased on the asset store.

The demonstration portion of the project, as previously mentioned, did not turn out as planned. In hind sight, I do not believe the plan I had would even be the best course of action for this tool, mainly because a developer is more likely to want a simple light weight example than a larger hard to follow one. I am considering a few different paths that could be taken with the demo project, but the front running idea now is to just use what I have with a much smaller level for the Rotation Vector based character controller. The smaller level will reduce the file size as well as likely make it run more smoothly. While this will not demonstrate every feature of the tool set, the raw data scene already does provide a simple example of each sensor in use. Any benefit I would get from giving more complex or interesting examples for the remaining sensors is likely over-shadowed by the other two tasks left to complete.

In addition to the tool set giving the sensor data directly as reported from Unity, I planned to also give a slightly easier to use access system that put the data into more common use case formats. I planned to implement this feature as I was developing the more complex demonstration for the sensors to get a better feel for what the common use cases would be. As the complex demonstrations have been scrapped this task also did not get completed in full. Having more experience now though I believe the common use cases are going to be mostly just the raw data, or the raw data divided by the data range for most sensors. Providing a simpler coding interface to query these values directly should be very simple for most sensors. The one known exception to this will be the rotational sensors, like the Rotational Vector and Game Rotational Vector sensors, but having implemented a player controller prefab using these sensors, I have already determined what the more complex to implement common use case will be for these sensors.

The last thing the project needs is for the documentation to be completed. After speaking with my advisers and some other developers, having good documentation will likely be far better than having more in game examples of the sensors use. I am using Doxygen to automate the creation of the basic documentation, which will allow the end user to reference all the functionality of the system. In addition to the automated Doxygen documentation I will need to create tutorials of how to get started and how to use some of the more advanced features of the system, such as the networked debugging. The last aspect of documentation I want to implement are video tutorials, one demonstrating the capabilities of the system, one walking a user through the basics of getting started using the system and the last one showing how to use the networked debugging for a variety of use cases.

I believe these last few tasks should not take a huge effort, and with them the result will be better than what I had originally planned for the project. Some of the motivation for the project was lost when Google released a package for supporting their Cardboard platform with head tracking, to Unity, but I do believe the project is still viable and that it is worth finishing and releasing. The main competition for this product, GyroDroid, appears to still be getting sales but people are complaining about bugs and a lack of support. SensorDev is already a better tool set than GyroDroid as I provide access to a number of sensors that my competitor does not as well as a system for debugging. With a cheaper price, if I can finish the remaining tasks as well as provide a more bug-free, or at least supported, product I should be able to make some sales. Also, simply releasing the product will prove a number of abilities that could be beneficial to my future career.

 

References

Java Archive (JAR) Files. (n.d.). Retrieved July 22, 2016, from http://docs.oracle.com/javase/6/docs/technotes/guides/jar/index.html 

Create an Android Library. (n.d.). Retrieved July 22, 2016, from https://developer.android.com/studio/projects/android-library.html

Asset Store - Village Interiors Kit. (n.d.). Retrieved July 25, 2016, from https://www.assetstore.unity3d.com/en/#!/content/17033

Asset Store - GyroDroid. (n.d.). Retrieved July 22, 2016, from https://www.assetstore.unity3d.com/en/#!/content/1701 

Doxygen: Main Page. (n.d.). Retrieved July 22, 2016, from http://www.stack.nl/~dimitri/doxygen/

Motion Sensors. (n.d.). Retrieved July 22, 2016, from https://developer.android.com/guide/topics/sensors/sensors_motion.html#sensors-motion-rotate 

Capstone Game Post Mortem: Robomancer

Game Summary: A turn-based tactics game aboard an abandoned space station

Author

Joshua Fox

Title

Robomancer

Genre

Turn-based tactics

Platform(s)

Android, eventually iOS and Windows

Revenue model

The game will be released as a free demo, with the first few levels included. Players wishing to play the full game can purchase the full version for $4.99.

Development tools/Language

Robomancer was created using Unity and C#, with art assets created in Maya and Photoshop.

Game audience

The target audience for this game is fans of other titles in this genre, such as Final Fantasy Tactics, XCOM, Fire Emblem, etc.

Copyright/Reference

Robomancer © 2015 Joshua Fox

Backstory

Sound Bite

One man's junk is another man's robotic army.

Executive Summary

Robomancer is a top-down, turn-based, tactical RPG set on a space station discovered by the main character. The hero finds the station is full of powered-down robots, and using his technical know-how he powers up a few and explores the station with them. The game features tactical battles in which positioning is key: the main character is more vulnerable than his robotic allies, but he also must stay close to them in order to direct them around the battlefield.

Inspiration

Science fiction stories have always fascinated me, especially those involving space stations--Star Trek: Deep Space Nine is one of my all-time favorite shows. Combine this with my love of tactics games, and you have Robomancer. I wanted to create a game that included the same feeling of danger and tension as the XCOM series as well as a diverse cast of characters and abilities like Final Fantasy Tactics into something uniquely my own.

Ideal

The initial vision for the capstone project was to create a slice of the eventual game. During the design process I included far more elements that I could implement in the capstone time frame alone; this was done in to create a cohesive design. Since the goal was to create a small slice of the overall design, for the most part I was successful. I would have liked to have had more visual content in the game in the form of character models and animations, as it would have added a lot more variety for the player. From a technical perspective, however, I think I achieved what I set out to do. Going forward most of the effort will be spent on creating additional content, though there still are some systems which were not in the capstone project that need to be implemented as well.

Gameplay Screencast

The Critique: What went right…

Unity

Unity is a powerful engine with a lot of capabilities. It is very easy to pick up and get started, though it is not without its own challenges when trying to something complex. Using Unity gave me a good start on my project, as all of the core systems for any game (a renderer, level editor, etc) are already in place.

Unity's Asset Store

Early on in the project I found some content packages in the asset store that allowed me to fill out a large portion of my game's assets (at least for the prototyping/capstone process), so I could focus on making those assets do something interesting. The asset store has a lot of good content which can provide solutions to common problems, as well as act as a learning tool in some cases.

Grid System

One of the first big systems that I wrote for Robomancer was the grid system. All unit actions and AI behaviors revolve around this system--finding units in range, determining a valid movement path, etc. Though I added to this and tweaked it a bit as the project progressed, by and large I got this system right from the beginning. A few extra bits of functionality here and there in the planning stages made later features which utilized the grid much easier to implement.

The 3D level on the right, and its grid representation on the left

Lightmapping

Unity's lightmapping system allows for light detail to be calculated and then "baked" into textures called lightmaps. These textures are then rendered on top of the static geometry at run-time, in lieu of using real-time lighting . As a result, the final rendering cost for an object using this method is much less than it would be using a more realistic, dynamic lighting model. Using these lightmaps, I was able to achieve a great deal of visual quality while still maintaining a high level of performance.

Another useful element to go along with lightmaps is what Unity refers to as Light Probes. Light Probes allow a moving object (such as the characters in the game) to look up information about the baked lighting, and change the colors of the objects based on their position in the level. What this means is that dynamic objects are affected by the lightmap information to give the impression of a detailed and dynamic lighting model. The result is not entirely realistic, but just hinting at a bit of realism can make a huge difference.

Light Probes hinting at realistic lighting

The Critique: What went wrong…

Unity

This was my first large project using Unity. Prior to this, my experience was limited to a tutorial here or there, and often those only covered the basics of the editor: dragging a GameObject onto a script variable, creating a Prefab, and so on. Creating Robomancer has been a crash course in how to use Unity on a deeper level, and I had to learn as I went along. Unity is a very flexible engine, and someone using it can accomplish virtually any task in a variety of ways. Unfortunately this is a double-edged sword, as some ways are better than others, with no real guidelines as to which is which for someone not completely familiar with the engine (e.g. me).

This is not the fault of Unity; the engine is there to support the developer's project, not structure it for them. This project forced me to develop some more organizational skills, something I often struggle with. Knowing what I know now, there are some things I would have structured differently from the beginning, and some things that I will rewrite once I resume work on the project.

Asset Store Content

Not all asset store content is created equally. The assets that I used for the bulk of the environments had issues with baking lightmaps, and I spent a fair amount of time attempting to debug the problem. Eventually, I discovered there was a problem with the way that Unity was importing the assets, and that it was a known issue with the version of Unity I used for the project (which was 5.2.1). A Unity developer had mentioned in a forum post I came across that the bug was fixed in a newer version of Unity, but I was reluctant to update in the middle of a project because that can be a risky thing to do. I found a workaround eventually, but the time spent trying to resolve those issues could have been spent elsewhere.

Lightmapping artifact from an Asset Store mesh

Incomplete Planning

There is the expression which says someone "Can't see the forest for the trees." It implies a person is missing out on the big picture because they are focused on the smaller details. I often have the opposite problem, in which I can't see the trees for the forest. I see the big picture, but the small (and often critical) details are overlooked. Early on in the project, I overlooked some of these details when planning some unit abilities, and the visual aspects of these abilities (unit models, animations, etc) were not planned. The features were implemented, but during usability tests everyone playing the game was confused about what was happening--understandable, given the lack of visual cues. Better planning at the beginning stages could have alleviated this.

Tutorial

I created the tutorial as my first level, and this ended being perhaps the worst decision I made on the project. First, I had no way of scripting level sequences or events (and didn't have time to create one), so every step of the tutorial had to be hand-crafted. I had to rip apart some existing functionality in order to be able to essentially pause in the middle of something and check to make sure players performed the correct action for that part of the tutorial.

This was all very tedious, but the real problem is that other game features were being implemented or tweaked after they were created for the tutorial. If I changed the way a system worked, I would have to make sure that the tutorial version of the system was modified as well. I made numerous tweaks and adjustments to the game after the tutorial was created, so I had to rework it over and over again. Going forward, I would save the tutorial until the very end, once I was certain the game and its features were finalized.

Summary

Overall I am very happy with my capstone project. I think the design is solid, and the implementation so far is good, given the tight time constraints during the last few months. Going forward there are some areas that need a bit of work, and there are still some missing systems and features, but this was only ever meant to be a slice of the final product. There are three big areas that I will be focusing on in the months leading up to this being released as a finished product.

Systems Redesign

Knowing what I know now about Unity, there are some things I would like to go back and change. How certain classes interact with each other, how GameObjects can be created dynamically, these types of things can be improved to make it easier to integrate into other systems later on.

Level Encounters

Currently the levels in the game play out as just an arena for the two teams to shoot at each other. Long-term, I would like to have levels play out as individual scenarios, with goals or objectives for the player along the way. This will make the game feel more like a progression through the levels (and the space station in which they are located), which is one of the overall goals for the game.

Asset Creation

The placeholder assets I used for this game were fantastic overall, but they are just that, placeholders. The main character needs to be created from scratch, as do many other units and the environments themselves. Having never created much content for a mobile game before now, I look forward to the challenge of creating interesting art assets that will run well on a mobile platform.

Publish

I plan on releasing Robomancer in mid- to late-2016. I would like for it to be completely finished by then, but if only the first few levels (i.e. the demo) are complete, I will still be releasing it then, with additional content to come out later as an update.

References

Fox, J. (2016). Robomancer [Android video game]. Oviedo, FL.

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/

Capstone Postmortem : Pixel Perfect

Pixel Perfect

Game Summary:

Game App Icon:

Title

Pixel Perfect

Genre

Platforming / Speed Running

Platform

Andriod

Revenue model

Inlaid ads between level loads

Development tools/Language

Unity5 C#

Game audience

Gamers age 25-35

Speed runners who engage in head to head competition for ranking on leaderboards. Female gamers may enjoy the trope free character design but are not being specifically targeted.

Team

Shawn Farris - Programming & Art

Music - Credit in game

Copyright/Reference 

Shawn Farris. (2016). Pixel Perfect [Mobile Video Game] Virginia : Shawn Farris

Backstory:

Sound Bite

Nothing is impossible but are you skilled enough?

Executive Summary

Pixel Perfect is a 2d platformer that synthesizes the core gameplay mechanics of what makes platformers popular and builds around the basics without additional frill. Players interact with simple controls to navigate increasingly difficult worlds and mechanics that will remind players of the “nintendo” hard style of play. Pixel Perfect also challenges standard tropes in gaming by having a strong female player character and approaching the entire genre with a satirical lens.

Inspiration

Pixel Perfect was inspired by my love of Metroid-Vania style games, platformers, and the blue bomber Megaman.

Capstone Game Scope

Ideal

The ideal behind Pixel Perfect was to create a powerful platformer that strips away some of the frill that has been added to platformers over the years. I wanted to approach the game from the point of view of creating a strong but mute female character that players could identify with through her body language and manifestation of her emotions. I also wanted to play with the trope of the navigational or tutorial character being a force for good for the player and being trust worthy.

Demo Screencast:

https://www.youtube.com/watch?v=TxsJZ1gE6uI

Final Screen Cast:

https://www.youtube.com/watch?v=xHY7y4-A9Rs

The Critique: What went right

Design & Aesthetics

Pixie's Emotions

A great deal of effort and iterative design was put into creating Pixie's emotions so that she would be understandable in both her "Emoticon" and her body language. Initially I designed her emotions and then sent out surveys to focus groups to get feedback. After changes were made based of user feedback I then had a serious of GTM with experts to refine her emotions even further. 

 

All of these efforts paid off a great deal. In the end Pixie became a very strong character who stood on her own and conveyed emotions clearly. Most testers felt a strong identification with Pixie and clearly understood the emotions she was trying to convey.

Design and Mood

Doing iterative design to levels and lighting enabled me as the developer to convey a mood to the game that came across clearly to the players. It is a powerful moment when the player first enters the first level after the tutorial and the tutorial wizard "reveals the devastation a great evil has caused. This light sprite effect adds a great deal of mood to the game and elevates the game above the standard pixel art game style. 

UI

 

Design approached to try to impart story narrative even in menus and world maps.
Iconology underwent focus group and expert surveys.
Layout underwent multiple testing for control and layout.
What was hard to make work? Button layout and redundant notifications.

Project Management

Use of sourcetree and GIT enabled me to get into good habits of frequent updates with detailed descriptions. Strong version control practices are an important habit for any developer working with a company. Because of these strong version control practices no portion of code or art work was lost during the development process. I was able to work from several locations seamlessly on the overall game.

Development

Pixel Perfect uses the native code of the Unity engine efficiently and extends existing classes to be able to create effects such as the sprite lighting effects. Because of the engines fast prototyping and publishing abilities I was able to bug test quickly. Initially having multiple levels of difficultly and a speed run tracker/leaderboard were wish list items in development but because of the agile development method and smartly handled milestones I was ahead on development and able to put these wish list items into game.

Testing

Testing surveys provided a good deal of feedback from my focus group. I learned the important value of quantitative vs qualitative data. Being able to glean more information beyond 1-10 from a player is really important for getting good feedback. For this reason I will lean more towards talk-aloud testing in the future as it proved very helpful in the Pixel Perfect development process. Doing multiple test phases allowed for iterative design and changes to the game. During the development process I broke down individual sections of the game for testing which provided more focused feedback.

Business Model/Plan

I learned a great deal about what Pixel Perfect lacked and needed in order to be ready for a kickstarter to get the total game off the ground. I was able to discuss with experts in kickstarting games the process they took and what players expect in terms of incentives. I also got really good feedback when discussing with Full Sail staff various pricing methods and distribution options for Pixel Perfect. 

The Critique: What went wrong 

Design & Aesthetics

Creating all of the pixel art myself became time consuming. Because of the iterative design process required to create Pixie's emotions I ended up generating her sprites by hand several times. In the end I had begun to wish that I had created Pixie as a 3d model for faster rigging and changes to her animations. I could not have for seen this as a developer at the start of the game development though.

The limited scope of the vertical slice caused the narrative of Pixel Perfect to be crunched. The tutorial level especially feels very meaty with text that would have ordinarily been spread over several levels. Some elements with in the game were pushed in to earlier levels as they are important to the narrative and had to be shown in a vertical slice for player motivation to be shown. For example the player is meant to save a jar full of animals after every boss fight so they have to overcome the hurdle of several levels and then a boss to save these animals. However since bosses were not included in the vertical slice animals were placed at the end of the Dark Forest to show player motivation. Players commented however this placement felt like it had a lack of obstacle to overcome, which I agree with.

Development

Bugs existed in the early launch of Unity 5 that I as a developer had to wait for the next version of the engine to fix. 

As I coded the game I started to create a large script that handled all of the events with in each level. This became burdensome when it came time to make changes to timing or parts of each event. Had I coded more smartly I would have made code for each of these mini events so that if I need to make changes to one event I was only tweaking the timing and code of that one event. It became a pain to shift 50 events to fit one new event in.

I was unable to create a procedural generated dungeon which was part of original idea but was scrapped for the vertical slice.

I was also unable to get online leaderboards in the game. This was another wishlist item but I would have liked players to be able to compare themselves to other players even in the vertical slice.

Testing

Doing distance testing with the facility across two different types of devices had it's downfalls. While the staff was very helpful in attempting to take screen shots or videos of the bugs they were encountering I was often unable to fix a bug until I was personally able to replicate it. A more robust bug reporting system would have been helpful. Also being in person for this testing so I could have watched bugs as they happened would have helped. 

Business Model/Plan

I learned that Pixel Perfect needs more levels then the vertical slice and some kind of incentives such as lance texture changes in order to get a kickstarter funding. This is not necessarily something that went wrong in the capstone but a lesson in what more I need moving forward.

Other

Summary:

Pixel Perfect is:
Design driven game
Visually strong game
Compelling narrative
Unique platforming mechanics
Strong mute character that players relate to
Polished vertical slice
Multiple levels of difficulty
Built in speed running mechanics

References:

Shawn Farris. (2016). Pixel Perfect [Mobile Video Game] Virginia: Shawn Farris

Thompson, S., Walsh, T., Evans, E., & Evans, D. (2014, December 31). Postmortem: Pinball-RPG hybrid Rollers of the Realm. Retrieved February 11, 2016, from http://www.gamasutra.com/view/feature/233340/postmortem_pinballrpg_hybrid_.php

Harvey, C. (2013, September 23). Postmortem: DrinkBox Studios' Guacamelee! Retrieved February 11, 2016, from http://www.gamasutra.com/view/feature/200658/postmortem_drinkbox_studios_.php

WINTHER, Helle. Body Contact and Body Language: Moments of Personal Development and Social and Cultural Learning Processes in Movement Psychology and Education. Forum Qualitative Sozialforschung / Forum: Qualitative Social Research, [S.l.], v. 9, n. 2, may. 2008. ISSN 1438-5627. Available at: <http://www.qualitative-research.net/index.php/fqs/article/view/414>. Date accessed: 12 Feb. 2016.
Mehrabian, A. (1971). Silent messages. Belmont, CA: Wadsworth Publishing