Capstone Game Post Mortem: Wreckage

Capstone Game Post Mortem: Wreckage

 

Game Summary

Game App Icon

Title

Wreckage

Genre

Strategy Builder
Arcade style Shoot-em-up (SHMUP)
Hybrid

Platform

Android

Revenue model

Free-to-Play – Extra life for a token

Development tools/Language

Unity with MonoDevelop and C#
SourceTree – GIT repository management
Trello – mobile kanban-style task notes
Parse – cloud database services
Pixabay – public domain sprites

Game audience

25-50 year old American males

Team

Nick Penney – Design and code
Andrew Trahan – Music and sound effects
Pascal Duverger – Logo and character art

Copyright/Reference

Wreckage © 2015 Nick Penney

Backstory

Sound Bite

"In order to salvage, you must first destroy."

Executive Summary

Wreckage is an arcade style space shooter game, where you are battling against the creations of other players so you can steal their technology and use it to build your own mega boss. The game is a mash up of the shoot-em-up (SHMUP) and strategy builder genres of games. (Ikaruga meets Dungeon Keeper)

Unique selling points include the ability to build and upgrade your own boss character, fighting against player-created bosses, better controls than most mobile shoot-em-up games, and persistent ship upgrades for more comfortable casual play.

Inspiration

The inspiration for this game comes from many different disciplines and experiences, including other games I have played, movies I have watched, and books I enjoyed reading. I wanted to add a spin to the typical shoot-em-up game, which is salvage mining and construction. The bite size game-play of the mobile game experience lends itself well to this idea.

Capstone Game Scope

The development plan for this game was to complete 1/3 of the project during my capstone and have a playable demo to put in front of users. This was done so that I could gain valuable feedback and minimize financial risk. I was able to surpass this goal, getting almost halfway done, and still had time to implement many suggestions given through user feedback. This was largely because I found other people during testing, most of whom I had just met, volunteering their time to work on the project with me.

Ideal

The ideal for this project is to continue development past the capstone and publish. My team is the main driving force in this becoming a reality. If they continue to volunteer their time, I would happily continue working on it with them.

Demo Screen-cast

The Critique: What went right

Design & Aesthetics

The primary game mechanics work well for this game. The input mechanics work well, and people love the idea of touch-up pausing. The majority of work relating to final art was scheduled for post-capstone development, but we managed to get a good portion of it done ahead of schedule and put it into the game demo.

 

Project Management

This project was managed quite well. The time estimates were well considered and I was able to accomplish all my project goals on time. Having weekly milestones and screencasts due each week provided just the right amount of pressure to maintain sustainable progress without getting in the way. Using GIT for source control management was great and definitely saved the day on a number of occasions.

Development

Unity was a joy to work with. I really like working with the new GUI system that was added in the latest release of the product. The anchor system made working in different resolutions easy. I was also able to drop the parse.com module and other third party scripts into the editor with minimal effort.

Testing

The A/B testing we did in the testing class shed some light on the utility of post-deployment tweaks that were possible. This was even further enhanced for my application, because it is already largely cloud based. I got the idea to use a cloud based string table, which can be modified for usability without having to redeploy the application. I also store a good amount of object properties in the cloud so I can A/B test them and deploy appropriate tweaks for game balancing.

The Critique: What went wrong

Design & Aesthetics

Clearly conveying the purpose or message of the game without a lengthy diatribe is something a good number of games suffer from, and this one is no exception. Because the primary selling point of this game is divergent from the average SHMUP, users who picked up the game for the first time had no idea what the point of the guardian character was. I had implemented an in-game help system, but they largely ignored its existence and chose instead to forge ahead blindly. It was foolish of me to assume 25-50 year old American males would bother with directions when they didn’t know what to do.

Project Management

Defining deliverables for artists to produce is something I have never done before. The first few artists who agreed to work on the project with me were inexperienced and ended up drowning in too much creative freedom. It wasn’t until I had a conversation with an experienced artist later in the development cycle, that I realized this was largely my fault for not providing specific enough constraints to give them the push they needed to succeed.

Development

The Unity Editor WWW stack on OSX suffers from a flaw in decreasing timeout durations, which means that I need to restart the program any time I want to run my game more than once. This continues to be a source of endless frustration for me, and I have to rely on hardware or standalone apps whenever I need to do end-to-end testing.

MonoDevelop offered another hurdle for me, because I was using asynchronous threaded tasks to connect to cloud code. When debugging with MonoDevelop, it would freeze whenever it hit one of these task statements. For this reason, I was only able to attach the debugger after the login process was completed. This led me to rely heavily on caveman style debugging techniques to debug any issues with the cloud code, as the debugger was unable to be used.  A free third party Unity plug-in called Log Viewer helped with this.

Testing

Our academic schedule was such that testing was in month 3 of development and I found that bootstrapping unit testing onto an already developed game proved to be largely fruitless. There were only small portions of code that were testable, due to almost everything being already developed as a mono behavior and attached to a Unity game object. Luckily this won’t be the case for future students, because the program outline has already been revamped to incorporate the testing curriculum earlier.

Summary

 

The development of this project has been an enjoyable experience. I knew going into the project that there was only so much I could accomplish, due to my schedule being limited by work and family obligations, so I selected a project with appropriate scope. I picked something I was interested in and knew that I could accomplish, but offered significant technical challenges and learning opportunities. I was lucky to run into both an audio engineer and several artists during the course of testing my game, who volunteered to do some work to contribute. This was not part of the original plan, so I am excited that the game has improved as a result, and I am happy with what we were able to accomplish. 
 

References

Log Viewer. (2014). What you see in the editor console is what you get in the game screen. [Unity Plugin]. https://www.assetstore.unity3d.com/en/#!/content/12047

Parse. (n.d.). The complete mobile app platform. [Website]. https://parse.com

Penney, N. (2015). Wreckage. [Android Application].

Pixabay. (n.d.). Free high quality images you can use anywhere. [Website]. http://pixabay.com

SourceTree. (n.d.). A free Git & Mercurial client for Windows or Mac. [OSX Application]. http://www.sourcetreeapp.com/

Trello. (2014). Trello - Organize anything. [iOS Application]. Retrieved from https://itunes.apple.com/app/trello-organize-anything/id461504587

Unity. (n.d.) Unity – Game Engine. [OSX Application]. http://unity3d.com/unity/download

Capstone Game Post Mortem: Derwood the Dashing

Capstone Game Post Mortem: (Derwood the Dashing)

Game Summary: 

Author 

Dustin Bridgewater

Title

Derwood the Dashing

Genre

Infinite runner

Platform(s)

Android

Revenue model

Free to play. Initially intended to have microtransactions, but it would be inappropriate given the target audience.

Development tools/Language

Unity 2D engine with C# scripting. 

Game audience

The intended audience is for younger children but also appealing and challenging to everyone. I wanted to have the game be challenging but not overly so, especially for kids.

Team

Development Lead/Designer/Developer – Dustin Bridgewater

Artist – Matthew Glaister

Copyright/Reference

Derwood the Dashing ©2015 Dustin Bridgewater

Backstory:

Sound Bite

“They thought giraffes couldn’t run. They were wrong.”

Executive Summary

Derwood the Dashing is an infinite runner for all ages. In this game, players control Derwood as he patrols the ‘Animal Kingdom’, watching out for danger and running around as fast as he can. Players earn upgrades to help them out and can unlock costumes to really make Derwood stand out!

Inspiration

My main inspiration for this game is an older infinite runner called Canabalt. I played this game for hours and hours on end, and always thought it would be fun to create my own infinite runner style game.

Ideal

My ideal version of Derwood the Dashing would be a fully polished, tightly tuned game where players had the feeling of accomplishment and every failure could be their own, not a gimmicky or cheap death. Players could also choose from a wide range of upgrades to customize their game into a version that was uniquely their own.

The Critique: What went right…

Current Derwood

Design & Aesthetics

I set out to make this game simple to play, and have a clean overall art style. I view this as being a great success as it’s simply one button to control the entire game (tap anywhere on the screen) and the art looks very bright and consistent. I also wanted to have a clean UI that looked professional and was easy to get around.

The art and sound was a bit difficult, but after finding some royalty free tracks and also creating my own sound effects, the sound design would also be considered a success.

Project Management

I set week long goals and set them up in enough bite sized chunks that development went along smoothly. I felt accomplished because of the smaller goals I set each week, and it was a real treat to see how far I had come in each development sprint.

First Concept Art

Development

The code was setup to be very object based and nothing should have been jumbled together where it shouldn’t be. This made programming super simple especially in the later stages of development since I knew exactly where I needed to go to change something, and it only needed to be changed in one spot.

The piece of code I am most proud of is the random terrain spawn script. I looked online and looked at multiple algorithms, and then pieced them together in my own creation. This makes for a really random layout of terrain, but everything was spaced and pieced together perfectly.

Testing

I had a very big testing group that were eager to help me out, though a couple things truly helped me: my younger cousins and my wife’s cousin who is in the game industry.

My cousins really gave me the best raw feedback since they are both in the target age (one 8 the other 10). It really made me smile when I saw them fighting over my phone to try and beat the score of the other, goofy giraffes truly have a certain appeal to the younger audience.

I was also able to get great critical feedback with Bryanna, my wife’s cousin. She works in the game industry at Volition and warned me that she wouldn’t give me false feedback and would be completely honest. This honesty helped shape a lot of the later development of the game, changing Derwood from a flat and boring runner to really dynamic game. I love getting real feedback and this was invaluable.

Business Model/Plan

I am absolutely happy with this being a completely free game. While microtransactions would be a good revenue, I don’t feel right having real money transactions in a kids’ game. Yes I had purchases in the development stage, but this was truly to test my technical merit, and on full release these are being taken out. I never aimed to make money with this, just obtain great experience.

The Critique: What went wrong…

First 'major' playable prototype

Design & Aesthetics

I have learned that balancing a game is one of the more difficult aspects to accomplish. The majority of development time has been dedicated for finding a good balance of skill while minimizing luck with a random system, and that turned out to be a very difficult task.  What ended up happening was a mix of precrafted levels mixed with random terrain generation to ease players into the game while also providing challenges at later stages of the game

Back to work! In game enemy.

Project Management

The main problem I had with project management was just juggling a busy schedule and trying to get out the best product I could. I admit I thought that I could get a lot more done in the time given to me, but thanks to both life and programming issues what I do have done, while I’m proud of, pales in comparison to what I planned to have done.

Another issue was getting the art assets in on time. My artist was full on ready to do all of the art, but because of work piling onto him, we didn’t get in the art as soon as we could, and not as many animations. I can’t fault him, because Matt did a fantastic job with the art he did do for Derwood, I still laugh at seeing a giraffe with a knight helmet on.

Development

Going into this project, I wanted a fun, fair, and engaging infinite runner. I knew that I had to have random elements in the game, and because of giraffe height, I was a bit limited in coming up with obstacles. It’s quite the goofy object to work around! The randomized terrain was the first thing into the code, and it was a literal random number generator deciding what prefab to put down, and making sure if was out of the camera view. Previous distance was taken in from the last platform placed so everything would meld together nicely, creating gaps when needed and long stretches of flat terrain as well.

The problem with this is was mentioned in the design section: balance. Balancing the game is still ongoing and will continue on for as long as I support the game. This was truly the main development problem, and it’s been a great learning experience. I’ve gained so much game design experience from all of the trial and error needed to test what a balanced game looks like.

Testing

The main problem I had with testing was getting people to test it in person. Most of my testing was done over Skype, and I would have liked to have more face to face testing.

Business Model/Plan

The original business plan was free with microtransactions, and this was working perfectly. However I always felt like it was wrong since this was intended for a younger audience. After some feedback, I happily got rid of the microtransactions and it is now a fully free game.

Summary:

Overall I’m very happy with how the game has turned out. I wanted a simple yet fun game that was easy to pick up and play and truly feel like it belongs on a mobile platform, not just a game trying to fit on mobile.  Going back I would have cut down the expectations and focused less on extra things such as character upgrades and truly build a fully balanced terrain randomizer.  As it stands now, I feel the game has come a long way and I am proud to call it my first full game.

References

Bridgewater, D. (2015). Derwood the Dashing [Mobile Game]



EDIT
Screencast here

Capstone Game Post Mortem: White Hat: Decode

Capstone Game Post Mortem: White Hat: Decode

Game Summary

Author

Steven Smith

Title

White Hat: Decode

Genre

Action / Adventure

Platform(s)

Android, iOS, Playstation Vita (with Gear VR and Cardboard support where applicable)

Revenue model

Core game will be free on Android and $0.99 on iPhone, with PSN pricing pending. Available map for $0.99, 10-second one-time extension for $0.99, packs of extensions at 5 for $4.99 and 10 for $9.99

Development tools/Language

Unity 3D, C#, Objective-C, Javascript, C++, Java, C++, Oculus mobile SDK, Durovis SDK

Game audience

Targets males and females 16 - 40, typically with a history in playing RPG games or an interest in new mobile hardware.

Team

Solo project

Copyright/Reference

Copyright 2014 LoungeKatt / Steve Smith

 

Backstory:

Sound Bite

Have you ever wondered what your computer dreams about while it sleeps?

Executive Summary

Enter the BetaCorp server and attempt to collect data as a member of the White Hats or Virals. Race against the clock or against friends on this and other supported platforms. Each team is trying to gather up as much data as possible, whether for protection or for profit. It is up to you which side you will choose to join in the battle to control the server databases.

Inspiration

This game was inspired by many of the innovative role playing games that provide high quality graphics and immersive navigation systems. Games, such as Persona 4, with pause menus that are animated and appear to be just as much a part of the game as game play. Games, such as Ragnarok Odyssey, that facilitate levels and multiplayer by using "physics" lobbies and buildings instead of GUI content. 

Ideal

The purpose of this project was to develop a game that would be comparable to a console release, while still being optimized for mobile platforms.

 

The Critique: What went right…

Design & Aesthetics

The music was an accidental discovery when searching for another sound, but has really brought the game together. This is a testament to the idea of not simply settling on the first thing you see or hear and not, at least, exploring alternatives to be sure.

The graphics, on the other hand, were fully planned from the start. While it was hard to fully map the depth of the intended design in the early documentation, it has come together in much the way it was planned. The characters appear detailed, while still maintaining the cartoon aspects that were desired. The start screen ties into the game, even with the requirement that a very specific Durovis logo is displayed when using their SDK. The HUD and environments maintain a Steampunk theme that is given cartoon undertones through the use of a more advanced version of the tony shaders included with the character set.

Project Management

The project management went well in terms of local timelines, schedules, etc. It is hard to find any flaw in project management when the documented items were complete in light of rearranged submissions. This shows that enough flexibility was provided in the plan and that adjustments could be made quickly.

Development

Choosing to use local code over existing templates that sounded similar to desired functionality allowed the flexibility to design the code for a specific situation or reuse it as a generic API itself, either later in this game or even in another project. It is extremely useful to have gone through the process of creating an API to better understand how they function. In future projects, there may not be time and resources to allow for choosing to generate the API in-house. Having done so in the past, it will be much easier to evaluate the uses and limits of an external API when one needs to be obtained.

Testing

The benefit of having pre-existing connections with various hardware manufacturers and developers is that there is equipment available for testing and any feedback is useful and concise. This shows the benefit of networking when developing a game. It will prove extremely useful to have a few opinions that are not based on observation alone. Those with experience using the same tools and processes can often provide much greater insight as to possible causes or alternate diagnostics. This both improves and accelerates the process.

Business Model/Plan

Having the purchases available from the early beta stages is a definite advantage. Having seen the results when apps attempt to retrofit purchase items or add items that do not fit into another upgrade, this would have been a serious failure if incomplete. It is important to ensure that primary components will fit into the overall product. Given the adjustments that were required to support the basic functionality of the necessary IAB library, it has proven that prioritizing features is vital to protect expected results, such as revenue.

Other

Unity was fairly easy to learn and taking the time to learn how to translate JavaScript to C# and back made for a humungous advantage when designing this game. Most developers that reference code examples use JavaScript, but the ambiguous nature makes a fully integrated control design unstable. This same ambiguity allows a camera script to function much more effectively. This is one example of when being able to switch back and forth between the two and integrate them into each other was almost required for success.

 

The Critique: What went wrong…

Design & Aesthetics

I do not feel there were any significant issues with the design beyond the limitations presented by the mobile platform. The characters used in this project come with the warning that while being compatible with mobile, they require careful consideration of available resources. The need to monitor resources became a very tedious aspect of attempting to provide high quality graphics.

Project Management

The plan was under a lot of scrutiny. The size of the plan made it appear as though time was insufficient for completion. Often times, the project suffered for this speculation. It was difficult to add features and generated an unnecessary amount of documentation to justify removing features, as not to give the impression it was a result of insufficient time or resources.

The introduction was an unplanned feature. This could be considered a design flaw, but it is less flawed than unimpressive. The stationary terminal output was an afterthought that fit into the theme well and provided a means to fill in a lot of backstory, but does not fit into the personification used for most of the game.

Development

Attempting to integrate the entire VR design for the Gear VR after the capstone presentation was already prepared corrupted some of the existing code. The Cardboard portion was completed and was fully tested with the standard game, but attempting to demonstrate the Gear VR support led to issues that could have been avoided had the SDK been available earlier in the development process.

Testing

This game was thoroughly tested, but not every aspect was verified against the different play styles of varying users. The original camera had the possibility of becoming blocked when turning corners tightly. This was not something that was fully tested and did not appear to be an issue. After attempting to perform “non-standard” navigation, such as turning back in the middle of rounding a corner, this issue became far more noticeable.

Business Model/Plan

The business model is not something that I feel is set in stone. I believe the map is an effective item, but I am skeptical about the time bonuses. I feel I may have to revisit this in the future by replacing these items with additional costumes or other items planned for “standard” updates.

Other

While feedback started out strong, it felt as though it became an afterthought when the project grew closer to completion. This is not something that went wrong with the project as much as it is something that required spending more time seeking out external evaluations that were intended to be part of the established process.

 

Summary:

This game far surpassed my own “unrealistic” goals. While the original written plans already appeared to be more than what is possible in the given time frame, they were only a portion of what I believed would be possible. The core of the game was used for documentation, but did not account for the progress made with virtual reality support, flexibility of the level design to add replay value, or nearly functional multiplayer mode as anything more than future plans. All of these goals have been completed and the game functions well enough for presentation at a public level. I plan to complete the one-year plan within six months.

 

References

Atlus. (2008). Shin Megami Tensei: Persona 4 [Playstation Game].

Game Arts. (2012). Ragnarok Odyssey Ace [Playstation Game].

LoungeKatt. (2014). White Hat: Decode [Android App].

Unity. (2014). Steampunk: Industrial Revolution. Retrieved from https://www.assetstore.unity3d.com/en/#!/content/17446

Unity. (2014). Blade NPC Special Pack. Retrieved from https://www.assetstore.unity3d.com/en/#!/content/9184

Unity. (2014). Sword Girl #1. Retrieved from https://www.assetstore.unity3d.com/en/#!/content/15103

Unity. (2014). Villager A Girl NPC. Retrieved from https://www.assetstore.unity3d.com/en/#!/content/5542

Unity. (2014). Medieval Toon House. Retrieved from https://www.assetstore.unity3d.com/en/#!/content/16674