Capstone Game Post Mortem: Gold Jump

Capstone Game Post Mortem: Gold Jump

 Game Summary:

Author

Michael Bugglin

Title

Gold Jump

Genre

2D Puzzle Platformer

Platform(s)

Android

Revenue Model

The game is free-to-play; primary monetization will come from the in-app store.

Development Tools/Language

The game was developed using C# in Unity 5.0 (Unity Technologies, 2015). Custom artwork not obtained from external sources were created using Paintbrush (Soggy Waffles, 2010). Sound effects that needed to be shortened were modified using Online MP3 Cutter (123apps, 2015). Internal and external databases were implemented using EasySQLite and Parse APIs, respectively (FreCre, 2015; Parse, n.d.). The in-app store was created using the Soomla API (Dakar, 2015).

Game Audience

The main target audience is young adults (18+) and older, mainly those who play games on a regular basis. In particular, the game is targeted towards Diamond players (Hiwiller, 2011, p. 1).

Team

Michael Bugglin designed and developed the game as well as creating several icons.
Ian Thorpe created all artwork for the main characters.

Copyright/Reference

Gold Jump © 2015 Michael Bugglin

Bugglin, M. (2015). Gold Jump [Android game]. Hainesport, NJ: Michael Bugglin.

Demonstration Screencast

Backstory:

Sound Bite

“Will you jump high in the sky, or be bold for the gold?”

Executive Summary

Collecting treasures, including coins, is not the same in Gold Jump as it is in any other game, especially platformers. Too much gold will weigh you down excessively, so you will have to figure out how to get the gold to the end through some clever use of the environment. This platformer and puzzle hybrid genre will give you something to boast about to your friends if you manage to survive to the end, because you must watch out for many hazards, including bottomless pits and turrets that shoot fire!

Inspiration

The main game was primarily inspired by Commander Keen. I remembered how difficult it was to control your jumping height, and, subsequently, how difficult it was to get some of the more sinister teddy bear locations (id Software, 1990). From there, I had an idea where players had some freedom in altering their jumping capabilities, and that is where the coin mechanic originated. The level editor aspect was not inspired by Little Big Planet (Media Molecule, 2008), but by Everybody Edits instead. In Everybody Edits, a select few in a level are given editing privileges while everyone else observes (NouEE, spambler, & sepehr, 2015). Pieces of this gameplay can be seen in Gold Jump's level editor, even if all intended aspects did not make it into the current version.

Ideal

For the main game, players would have been able to share their successes in the game via app requests on Facebook (Facebook SDK, 2015). In addition, players would have their fastest completion times saved in leaderboards, so they could compare their best times with their friends' (Wilkinson, 2014). The ideal level editor would have allowed for up to four collaborators in one server along with many observers and the ability to chat with everyone in the room.

Gold Jump icon

The Critique: What went right…

Design & Aesthetics

Example of standard gameplay

 A majority of the necessary assets were available right from the beginning. Only a few assets, most notably icons, needed to be obtained during development, allowing a greater focus on coding. The game mechanics did not need to undergo any balancing changes. In other words, coins, crates, balloons, etc. function exactly as they were planned in the original design documents.

Project Management

Choosing to build the project with Unity had to be the best decision. Even if I had the money to afford working with Unreal (Epic Games, 2015), I would have known absolutely nothing about the engine. In addition, Cocos2d's rubbery fixes would not have worked for making a platformer (Chukong Technologies, 2014), and I would have had to use additional time to create my own engine. I knew enough about Unity to get the main game mechanics working quickly, and the engine worked well with allowing fixed movements and jumping heights.

Development

The music cross-fading mechanic worked well from the very beginning. It turned out to be not as much of a challenge as I originally thought once I discovered it can be done by playing multiple audio sources simultaneously. The internal database also worked properly at the start, and very few issues were encountered as the database was merged with the level storage system. Storing and retrieving external database entries also worked seamlessly for the most part.

Testing

User testing was widely successful in uncovering numerous issues with the game. Test sessions were able to be performed in scenarios where the game would actually be played. Player feedback was also instantaneous. Optimizations through the use of the profiler were also highly successful in improving the speed of the game.

Business Model/Plan

The project was very cost-effective. The only items purchased were the internal database plugin and several graphic packs. Including the in-app store was also a good choice as it removes the need to have annoying ads strewn throughout the game. The store also allows players to skip levels if they want by buying coins in place of finding them. It also allows players to create and share more custom levels at once with their friends, which should encourage said friends to do the same and make a good source of revenue.

In-app store

Other

Assets were relatively quick to find. OpenGameArt.org provided the majority of the graphics needed for the project (Kelsey, n.d.), and the Westar Music database was the source for almost all of the game's music and sound effects (Westar Music, 2014).

 

The Critique: What went wrong…

Design & Aesthetics

Some game mechanics were created that did not work with Unity's physics engine and did not add value to gameplay, like the coin grouping mechanic. Several of the levels had balancing issues on multiple occasions, most notably the now level 13. UI controls were frequently unresponsive due to order of operations and inefficiencies in the code.

Project Management

Bugs kept piling up, and sprint tasking kept getting pushed back to the point that features had to be cut, including chat windows, outfits, and idle poses. Networking was a problem to setup, and the new Unity networking system was not out at the time the project was started, which could have potentially avoided the many problems I encountered.

Development

The player's attempt at picking up the crate did not work out.

 The class diagram was poorly designed from the very beginning, resulting in a code architecture that needed to be modified after every sprint. Facebook app requests were cut due to the plugin failing to work without any visible errors and poor documentation of the plugin (Facebook SDK, 2015). The Google Play leaderboards plugin suffered a similar problem where authentication kept failing without any errors (Wilkinson, 2014). Networking desynchronization was common in the early level editor system due to missing information not saved to the server. The physics engine kept causing objects to stick to each other. The worst offender is crates, which would sometimes not rise at all when lifted by the player, or shoot into the sky instead.

Testing

The multithreading nature of Parse (n.d.) made debugging more difficult due to MonoDevelop's horrible debugger, and errors were not getting caught, either. I was never able to debug through the actual device due to unknown issues with connecting the debugger to the tablet. I was limited in how many devices I could use to test due to the standalone version not running at all; as a result, I had to reduce the number of players on a single server to two. While user testing was mostly successful, not everyone who participated was from the target audience due to communication issues with intended testers and time constraints.

Business Model/Plan

The original business plan resulted in issues with breaking even due to misunderstanding how to implement the marketing strategy. The misunderstandings also resulted in the marketing budget being more spread out than it should have been, which would not have been a good strategy.

Other

I knew very little about how Unity worked when starting this project. This resulted in the aforementioned bad class diagram as well as issues researching solutions to problems. In particular, an issue with pixelated characters plagued for the longest time, because I knew nothing about mip-mapping. This would have helped me solve the issue faster.

 

Example of the corrupt mip-map causing pixelation in the character art

Summary:

While the main game mostly matched the expectations I had hoped for, the same cannot be said about the level editor. The lack of chat windows and observers prevents the level editor from being the originally-planned social experience. Because I hope to get a job soon, the time I will have to spend on the project will be very limited. With balancing and networking fixes that still need to be done as well as the missing chat window and outfit feature, it may take me at least a year before the game is ready for release.

I believe I learned much about Unity through the course of developing this project, which will help me to make better games right from the start. I also learned to make sure that the designs I create should be tested to be feasible before proceeding with development. Otherwise, I could end up having the same problems I had with this project where the architecture changed every sprint. If I had the opportunity to redo the project, I would definitely rewrite the class diagram from scratch, so it can actually account for all the nuances I now know about Unity.

The high point of the project was the user testing. The quick feedback and the number of bugs discovered made refining the game much easier. The low point was definitely the enormous amount of bugs that kept cropping up. I ended up going from having two free sprints reserved for bug fixes to having to cut several features from the game. Regardless, I do hope to eventually release the game once it is ready. In fact, I would like to expand the game after release with more game mechanics to try out.

 

References

123apps. (2015). Online MP3 Cutter. Retrieved from http://mp3cut.net/

Bugglin, M. (2015). Gold Jump [Android game]. Hainesport, NJ: Michael Bugglin.

Chukong Technologies. (2014). Cocos2d-x (Version 3.3) [Software framework]. Available from http://www.cocos2d-x.org

Dakar, R. (2015). unity3d-store (Version 1.7.15) [Library]. Available from https://github.com/soomla/unity3d-store

Epic Games. (2015). Unreal Engine (Version 4) [IDE]. Available from https://www.unrealengine.com/what-is-unreal-engine-4

Facebook SDK for Unity (Version 6.2.1) [API]. (2015). Available from https://developers.facebook.com/docs/unity

FreCre. (2015). EasySQLite (Version 1.1) [Plugin]. Available from https://www.assetstore.unity3d.com/en/#!/content/26888

Hiwiller, Z. (2011). Player Types [Portable document format]. Retrieved from https://assethub.fso.fullsail.edu/assethub/Hiwiller_Player_Types_b85dca6e-c18f-4294-b8c6- 17472fa75ae6.pdf

id Software. (1990). Commander Keen in Invasion of the Vorticons [DOS game]. Apogee Software. Available from http://store.steampowered.com/app/9180

Kelsey, B. (n.d.). OpenGameArt.Org. Retrieved from http://opengameart.org

Media Molecule. (2008). Little Big Planet [Playstation 3 game]. Sony Computer Entertainment. Available from http://www.amazon.com/LittleBigPlanet-Playstation-3/dp/B001IVXI7C

[NouEE], [spambler], & [sepehr]. (2015). Everybody Edits [Flash game]. Kongregate. Retrieved from www.kongregate.com/games/NouEE/everybody-edits

Parse. (n.d.). Parse Unity SDK (Version 1.4.0) [API]. Available from https://parse.com/docs/downloads/

Soggy Waffles. (2010). Paintbrush (Version 2.1.1) [Software]. Available from http://downloads.sourceforge.net/paintbrush/Paintbrush-2.1.1.zip

Unity Technologies. (2015). Unity (Version 5.0.0f4 Personal) [IDE]. Available from http://unity3d.com/get-unity/download/archive

Westar Music. (2014). Westar Music. Retrieved from http://westarmusic.sourceaudio.com/#!albums

Wilkinson, C. (2014). Google Play Games plugin for Unity (Commit 92386ca225) [API]. Available from https://github.com/playgameservices/play-games-plugin-for-unity

Capstone Game Postmortem: Scoundrel Squirrels

Game Summary:

Game App Icon

Title

Scoundrel Squirrels

Genre

Casual RPG

Platform(s)

Android

Revenue Model

Scoundrel Squirrels will initially be released as free to play, supported by interstitial ads.

Development Tools/Language

Scoundrel Squirrels was developed using the Untiy 3D and MonoDevelop, using the C# programming language. Advertisements are provided by the Unity Ads API. Multiplayer and social features will be implemented with the Combu API. Artwork was created using Inkscape and GIMP. Audio files were created and edited using Audacity.

Game Audience

The intended audience for this game is casual game players who would enjoy quick adventures but enjoy the aspect of developing a character over time. This game would appeal to younger and older players who enjoy silly experiences. I would estimate that it would appeal particularly to girls and women, but not exclusively so.  This game would have the most appeal for achievers and explorers, as described by Bartle (1996). I do not anticipate that this game would appeal to killers

Team

Tim Bradrick: game, artwork, and many sound files.

Additional sound files were acquired from Internet download.

Demonstration Screencast

Copyright/Reference

Scoundrel Squirrels is copyright Timothy J. Bradrick / FungiMuncher Interactive.

Bradrick, T. (2015). Scoundrel Squirrels [Android game]. Dublin, OH, USA: FungiMuncher Interactive.

Backstory:

Sound Bite

You’re a squirrel. Be a scoundrel! Accept the challenge and dominate in your dapper derby!

Executive Summary

In Scoundrel Squirrels, you role-play a daring squirrel adventurer. You can explore the world causing mayhem, taking on the challenge of wild adventures. When the chaos is done, relax to your tree-high home to enjoy your winnings and try out new outfits to show off in your next adventure.

Inspiration

I have always been an avid player of role playing games, both table-top and video games. However, I know the genre can be intimidating or overwhelming for many people. So I started wondering if a more casual take on it could be successful. Additionally, I wanted to explore something other than the typical science fiction/fantasy themes. The idea of using squirrels as a theme literally came to me when I was driving to work one day, and saw a squirrel crossing the street on a telephone wire. I thought was rather adventuresome, and my mind just started taking off from there.

Capstone Scope

The game as presented for the capstone requirements is a subset of the overall game I hope to further develop. The capstone game includes three primary features: dressing up your squirrel, exploring an area of the game world, and a race against the clock.

The dress-up features include being able to choose your squirrel model, its attributes and clothing it wears. There are fifteen unique articles of clothing, with some variations for attribute boosts. There is also a store and a prize box to get additional clothing. The exploration area includes random placement of objects and three different types of non-player characters. This area required the development of character controls, animations and sound effects. There is also a mini-game within the environment. The race area adds character jumping and climbing. A timer is implemented, as well as a set of awards based on one’s performance in the race. And of course, all of these features include a tutorial system to guide the player, and a means to save the squirrel for later play.

Ideal

There were many features I had to trim back from the initial planning stages. I had several additional adventure area ideas, which need to be postponed until later. I also wanted to implement multiplayer functions, with the ability to message other players asynchronously. I had hoped this would help facilitate the players making wagers on competitive races. There are also many ideas for an in-app store which were not implemented. All of these are still hopes of mine to implement in the future.

The Critique: What went right…

Design & Aesthetics

For the most part, I liked much of the art that I created for the game. This is a personal interest of mine, and it’s reassuring that, given time, I can do a decent job. I especially like the fruit and doughnut objects in the game. Overall, I like the cartoon like feel of the game.

I am happy with many of the mechanics in the game. I like how the dress-up aspects developed, though there is certainly a lot of areas in which this could be expanded. In the adventure area, I like how the jumping and climbing perform, and how the player and non-player characters interact. Sometimes, there are some wild or silly results of all the actions, and this fits the theme of the game.

Screenshot of a knocked out character

Project Management

I really enjoyed working in Unity. I found most of the development process to be very intuitive, and in some instances, rather elegant in how solutions can be implemented. I enjoyed the process of working in an agile framework, and the sub-division of tasks into sprints. These processes provided a quick response to evaluate progress, and the ability to change things early if needed.  The early planning was also a great aide when things didn’t go as planned, which happened a few times. I was able to refer back to the plan, and evaluate what to do in the future based on my previously determined priorities.

Another aspect of the project management that I appreciated was the bug and feature database. This helped outline the various parts which needed work, and provided a convenient point of reference between myself and my instructors.

Development

Early in the project, I know my development process was sloppy and haphazard. However, as I learned more about Untiy, and reacquainted myself with good programming techniques, things improved and became more elegant. Towards the end of the process, I was more easily able to create code which was more flexible and adaptive. This is most evident with the system I developed for presenting the tutorials. The same system is used for all of the scenes, and it is very easy to make changes.

Testing

The usability testing I performed throughout the project was invaluable. The players provided some very useful insights, and brought a variety of experiences when making suggestions. I consider this type of testing to be essential for my future efforts. The other players see or don’t see so many things differently than me. Related to this, another event that was very valuable at the very beginning of the project was the focus group. This provided some very interesting ideas to launch the project.

An early character model from a user.

Business Model/Plan

I am planning the initial release of Scoundrel Squirrels to be free-to-play, supported by interstitial ads, and perhaps a very simple in-app store. For a first time effort, I believe it’s important to get something “out there” quickly, without sacrificing quality. This will begin the process of getting my name, company and efforts known to others. In the future, I am hoping to expand upon the game, including additional adventures, multiplayer features, and a more developed in-app store. I also hope to eventually release the game for iOS and Windows Phone.

The Critique: What went wrong…

Design & Aesthetics

Regarding the artwork, I know all of it is not where I want it to be. The main issue with this is the time available. For example, the bushes in the game are very detailed, while the leafy parts of the trees are extremely low in detail. I would like to bring both of these closer to the level of detail of the pieces that I do like.

As for the mechanics of the game, two big challenges were the climbing functions, and the character movement controls. With the climbing, getting the squirrel to transition from horizontal to vertical smoothly was very difficult. I now know that part of this was how I implemented the running and climbing animations – the figures are in different spots in the individual sprites. This was done simply due to my inexperience. In the future, I will know better. However the problem still exists – I simply created a work-around.  Recreating all of the animations is going to be a lot of work.

The character controls for the basic squirrel movement has also been a challenge. I have tried many different solutions, and the work is still on-going. I’m hoping that I now have a good solution.

Finally, regarding the overall design, a big problem was trying to implement climbing and jumping in a 2-1/2D, isometric environment. When starting, I only had a vague idea how these would be accomplished. As I progressed, I was actually able to implement some solutions, but these would introduce new challenges. Ultimately, I had to reevaluate this planned feature. I finally separated these functions into two separate scenes. In the isometric area, there is no jumping or climbing. The other area is presented a simple 2D platformer, where one can climb and jump.

An early mock up of the game

Project Management

The biggest problem with the project management has been the scope of the overall game. Again, I attribute this to my inexperience. There are so many neat ideas I want to include, but not previously having a solid concept of the time required, there was simply too much included. Time and again, I’ve had to pull back on the scope of the project. Towards the end, I simply got to the point of very deliberate decisions of what to include to meet the requirements of the degree program.

Another early mock up, showing an undeveloped adventure

Development

The biggest problem with the development process has been my own inexperience. Especially early on, I was conducting a lot of research and experimentation when writing the code. Many times a solution would be discarded for another method. However, I feel that I have learned a great deal in this process, and my confidence has grown.

An early plan showing several undeveloped features

Testing

If there was any failing with the testing process, it was with my solution for controlling the squirrel character.  It was still not acceptable after the faculty review of my game. When I conducted the usability tests, my players did express some frustrations. However, they were happier after the initial tweaks I implemented. I guess the lesson here is try to get some people experienced in the field to test one’s game.

Screenshot showing the original character controls

Business Model/Plan

By simply releasing a ‘Lite” version of my game first, I am at risk of people not seeing the full potential for the game or my efforts. I am also risking not taking the game further, possibly allowing myself be distracted by other events in my life. I will need to remain diligent and have confidence with my efforts.

Summary:

In summary, I am thrilled by what I learned producing this game. I have learned quite a bit about the technical process of writing an app, and the important aspects of making a fun game. Additionally, I learned the importance of planning the project, and developing a schedule for completing the various parts. These helped me stay on course when difficulties arose.

As an initial effort, I am pretty happy with the resulting game. It certainly lacks many features I originally wanted, but I have much more knowledge on how to accomplish such a big project. While the game has yet to have the multiplayer functions, and a wider variety of features (adventures, mini-games, clothing choices, and so on), I know how to implement these, and am excited about what can be produced later. I do indeed hope to publish this game, but I do want rework some of the artwork, implement some of the smaller features suggested by my instructors and users. I’m hoping that this will become a reality in about six months.

A high point of the project was when, about three months into the development cycle (of about five total months), I noticed that this thing I was diligently working on started to feel like an actual game. The parts of the game came together and I could finally see the fun features. I actually started to laugh at the quirky little events in the game.

References

Audacity Team (2015). Audacity [OS X program]. Open Source Software: Audacity Team. Retrieved from http://audacityteam.org/

Bartles, R. (1996, August 28). Richard A. Bartle: Players Who Suit MUDs. Retrieved from http://mud.co.uk/richard/hcds.htm

Bradrick, T. (2015). Scoundrel Squirrels [Android game]. Dublin, OH, USA: FungiMuncher Interactive.

GIMP Team (2015). GIMP [Windows program]. Open Source Software: GIMP Team. Retrieved from http://www.gimp.org/

Inkscape Team (2015). Inkscape [Windows program]. Open Source Software: Inkscape Team. Retrieved from https://inkscape.org/en/

Skared Creations. (2014, March 16). combü [Unity3D API]. Retrieved from http://skaredcreations.com/wp/products/combu/#sthash.pJB4xhxb.dpbs

Unity Technologies. (2014, November 13). Unity Ads [Unity3D API]. Retrieved from https://www.assetstore.unity3d.com/en/#!/content/21027

Capstone Game Post Mortem: Airship: Wary In the Skies

Game Summary

Title

Airship: War in the Skies

Genre

Tactical Naval Action

Platform

Android

Revenue model

The game is intended to be released for free, with the primary monetization occurring from in-app purchases.

Development tools/Language

Airship was developed using Unity 4.6 as the primary engine. Assets were generated using Adobe Illustrator and Adobe Photoshop. The online components were created using the Photon Unity Plugin. The store components were created using the Soomla Store Plugin.

Game audience

The primary audience for Airship are young adults between the ages of 18 and 25, who have a history of playing online competitive games, or are interested in naval combat.

Team

Avram Suson worked on design and development.

Zachary Haley worked on initial level design.

Jacob Suson created all sound effects and music.

Michael Press, Derrick Snodgrass, et al. created the models for the ships.

Copyright/Reference

Airship: War In The Skies © 2015 Avram Suson

Demonstration Screencast

Backstory:

Sound Bite

As the country’s last hope, only the bravest can defeat the coming tide. Lead your ship to battle for victory in the sky!

Executive Summary

In Airship, the player takes direct control of a flying warship and goes head-to-head with other ships and players. The game offers a variety of vessels and game modes, so that players can enjoy the game, no matter what kind of play style they are looking for. People looking for competition can try the multiplayer arenas, aiming to be last ship soaring. If you’re looking for just playing some solo battles, you can hop into Practice Battle mode to get some practice against the AI. In either case, prepare to get behind the wheel of your ship and guide your crew to victory!

Inspiration

I am a long-time steampunk fan, and have always enjoyed the concept of Airships. One of the earlier games I had made for a quick assignment was a naval combat game with really simple controls. After trying to come up with an idea for a while, I decided to try and enhance the older game, but to change from traditional wooden ships into airships. 

Ideal

The ideal design for Airship is to have an active multiplayer system, with lots of players making rooms and fighting against each other. Similarly, players would be able to experience a story in Campaign mode, or play against challenges to test their capability. The ships would be customizable with a wide array of upgrades and power ups that players would buy and earn. This would also result in each battle being unique and exciting, as players could use power ups at unexpected times.

The Critique: What went right… 

Bug Database

Using the database to track bugs and features that still needed work really helped with keeping the workflow organized and efficient. It provided a list of everything that still needed to be worked on, while also showing what was more critical than others. It also served as a reminder of how much of the work still remained to be completed, and could be used to see how much work had just been completed. It was a helpful tool for keeping me focused on a task and knowing what I needed to focus on.

Development

A lot of the code structure was developed freshly and taught me a number of significant tricks that will be useful for a long time to come. The system that I developed for loading models during runtime turned out really well, and will be useful in the future. Also, the system was developed in a very open-ended way, which allows me to easily add more features and content as desired, which makes the game very easy to expand upon. This is predominantly because of the way the system reads from binary files for the content, rather than relying on the content being hard-coded into the project. This is something that will prove beneficial for expansion of this game, as well as future projects.

Testing

While some of the testing happened a bit too early on, some of the user tests proved really helpful with the feedback and helped show me how the players would interact with the project. While I have done testing before, my experiences with user testing throughout this capstone was different and substantially more useful than my past experiences. I was able to see what caught players’ attention and what didn’t, which allowed me to know how I needed to re-focus my work, or adjust certain features to help players with the game.

The Critique: What went wrong…

Design & Aesthetics

One of the original plans of the project was to try and build our own models, or find models online. However, after two thirds of the project timeline had passed, it was discovered that the team would not get around to making the models, and there weren’t any models of the desired type available online. I sent out a request for model-help and was contacted by a student group working for one of the professors, who offered to assist me with the models for free. I sent them a list of models needed, but the list was too much for the time remaining in the project. Before starting, we should have created a more realistic and solid plan for the assets, and we should have recognized when the asset plan was failing earlier so that it could have been fixed sooner. It is even more critical to catch when the asset plan needs to be changed early, since asset development can be one of the more time-consuming parts of a project.

Project Management

The largest reason for failure with this project was scheduling and time management. When I had developed the plan for this project, I had planned a tight schedule with a little bit of time for debugging at the end. However, as the project went on, some features took longer to be implemented than I had planned. Similarly, there were more bugs than I had expected, and I found myself quickly working to just keep up with the schedule while fighting bugs. It didn’t take long for me to become swamped and fall behind the schedule, requiring large features to be cut from the design to make up for the time to work on the bugs. In the future, I will plan that at least half of the development time, if not two-thirds of the time, should be dedicated to fixing bugs and features.  

Controls

One of the bigger issues that appeared late in development was a problem with the ship controls. This problem primarily appeared after I entered the final review stage, when the reviewers stated that they had trouble with the controls and couldn’t control the ship. This resulted in confusion, because it had contradicted with earlier user tests that I had run. The end result was a series of alternative controls hastily implemented to help the reviewers control their ships. What I ultimately learned out of this was, while testing with the public is still good for development, I needed to test more with the client for my game, the reviewers in this case, and ensure that the product was matching what they desired.

Summary:

Overall, I would say the project is well on it’s way for what I had desired. It is much more of a prototype and proof of concept than a completed product, but most of what remains is implementing assets and content, which can be done over time. There are a few major features, such as a Campaign mode, which had to be cut from the design due to time constraints, and I would want to attempt to implement these before final release. I did learn to plan for significantly more time for debugging, as well as to plan milestones more carefully so that I can spot when an aspect of the game is starting to not meet expectations earlier in the development cycle. I also learned that programming for abstract content benefits development in the long term. Similarly, maintaining a database of issues and features is a great way to maintain organization and focus of a development team. If I had to redo all of this from the beginning, I would probably implement those changes and more properly plan out the project in detail, using the experience I had from this project.  

Capstone Game Post Mortem: Treasure Craze

Capstone Game Post Mortem: Treasure Craze

Game Summary:

Game App Icon

Title

Treasure Craze

Genre

First Person Multiplayer Melee Combat and Item Collection.

Platform(s)

All Microsoft Windows 8.1 and later devices. (Phones, Tablets and Desktops)

Revenue model

Treasure Craze (Norri, 2015) is completely free in the Capstone edition, however in-app purchases were planned for the final retail version. Purchases would include upgraded flashlights & shovels.

Development tools/Language

Treasure Craze was built completely from scratch in C++ using a custom 3D engine built specifically for the project. All software was authored and tested using Visual Studio 2013. Game artwork was created and exported from Adobe Photoshop and Autodesk Maya 3D Modeling & Animation software. The only APIs used were low level hardware interfaces such as D3D11, XAudio2 and DatagramSocket.  

Game audience

Teens and Young Adults 13 – 35 who like competitive games. Treasure Craze is designed to appeal to players who fall under both “Achievers” & “Killers” under Bartle's player taxonomy (Bartle, 1996). The game also targets players who enjoy PC & Console multiplayer combat games but want a more streamlined experience for mobile devices.

Team

Lari Norri: Lead 3D/Network Engineer, Game Designer, Gameplay Programmer.

Joshua Fox: Lead 3D Character and Level Modeler, 2D Texture Artist, 3D Character Animations.  

Copyright/Reference

Treasure Craze is copyright 7thGate Software, LLC. (Norri, 2015)

Backstory:

Sound Bite

Get ready for a Rootin' Tootin', Doubloon Lootin' good time!

Executive Summary

Treasure Craze is a fast paced first person treasure hunting game where you battle other prospectors for loot & glory! Use the in-game compass to navigate a scary maze and find shiny doubloons. But be on the lookout for other prospectors who want the treasure all to themselves! 

Inspiration

The final design of Treasure Craze was influenced by many different games and experiences from my youth. I enjoyed playing many competitive first-person shooter games like Doom and Unreal Tournament. I also loved to play role-playing games with a particular fondness for dungeon crawlers. As a kid I used to love to explore the woods in North Carolina. I chose a “gold rush” era art style to try and capture that sense of adventure.  

Capstone Scope

While the full retail game called for internet play and in-app purchases, the actual capstone portion focused on just getting the fundamental technology and gameplay operational. This included: Random level generation, Player movement, Environment collision, Player matchmaking, Networking, 3D Rendering, Sound Effects and Music. Besides the critical features, I was actually able to get in two “B” level features on my list. These included “shovel combat” and “pre & post match screens”. Last minute additions that were never planned but I was able to cram in are: Active game player drop-ins, Player rankings and a compass indicator for the Gem and Ladder. These were added primarily based on faculty feedback.   

Ideal

In a perfect world I would have had the time needed to add some additional features and polish the graphics of the game to a much higher level. Visually I am happy with the results, but given a little more time I could have added normal & specular mapping to the game which would have bumped the graphics to the next level. Another feature which was on my “B” list was doubloon digging. Since you have a shovel it would have been nice to use it for something other than just hitting enemy players. I would have implemented this feature as a sparkling crevice in a wall that you could smack to yield even more treasure. The last item that I wish could have made it in, was a tutorial level that taught player the ropes of the game. Even though the game is fairly simple, additional help could have made things go smoother for new players.

The Critique: What went right…

Design & Aesthetics

Nearly three months into the program (after the prototyping class) I already had a very strong idea of what game I wanted to make. This meant that very early I was already documenting features, mocking up user interfaces and creating pre-production sketches. This proved immensely helpful moving forward as I could focus directly on how I would be putting the game together and worry less on design details as they had already been addressed. Access to the Weststar Music and Sound FX libraries (Sound Ideas, 2014) turned out to be invaluable. It was easy to find music and effects that complemented my game almost as if they had been made specifically for it. Last but not least are the overall visuals of the game. Writing my own engine allowed me to extract significant performance from mobile devices and to fine tune the game’s atmosphere directly. Another huge win came in terms of art & animation content but more on that later…

      

Project Management

Using Underdog was simple but effective. I was actually able to integrate GIT directly into Visual Studio 2013 which made commits and pull-downs a total breeze. The task and time management systems on Underdog were fairly straightforward if a bit barebones. I didn't have any problems using them though I do prefer more full-featured project management solutions such as “FogBugz” (Fog Creek Software, 2015). Even though 99% of the time source control really didn't do much for me, it’s always that 1% of the time where it is indispensable. For me it was when I had introduced a severe networking bug that caused constant disconnects in my custom network protocol written on top of UDP. Being able to “diff” with previous versions of my code ultimately led to finding where the problem had been introduced. Events like this are why source control should be considered “non-negotiable” on projects with any sort of reasonable scope.    

Development

Towards the end of development writing my own 3D engine really started to pay off. It became very easy to tweak systems or add new features since there was absolutely no confusion about how something worked. I was able to keep the engine/system code and the code driving the game fairly isolated from one another. This will come in handy if I want to develop future games using the same underlying technology. As you will see in the “what went wrong” section, creating a 3D engine is not a decision to make lightly. However, it does allow for focusing on just the essential technology that you need for your game. The other major benefit is that you end up with a game that has a very unique feel due to the custom tech driving it. Last but not least, there is no “learning curve” to things you make for yourself.

Testing

Play sessions and user-analysis ended up being the two most beneficial contributors to the Treasure Craze project. Multiple core gameplay revisions and feature additions are the results of direct player feedback. Even though a pre-multiplayer build was used during user-analysis it still provided significantly valuable information. Due to this feedback, I changed fundamental player controls and scheduled a compass feature for the game. Towards the end of the project, multi-player game sessions served to reveal game breaking bugs in the matchmaking and networking sub-systems. These sessions also provided helpful user suggestions that could further enhance game-play such as ranking order and in-game notifications. My Advice: Testing is seriously useful, do it early do it often. 

Business Model

Though the capstone version of Treasure Craze is a free game with no monetization, this is a good spot to discuss what the full game would have. In the Windows Store the game would be a free download but contain a way to purchase extra doubloons at an in-game bank. These doubloons can then be used to purchase upgraded shovels & flashlights as well as single-use items used to help win a match. Of course these doubloons can also be earned just by playing, but this offers a faster way for impatient players.

Artwork

I really have to hand it to my lead artist Joshua Fox! When I started this project I was expecting to simply cobble together whatever artwork I could scrounge from the internet. Josh is a good friend and colleague of mine who stepped up to the plate. He not only offered to create & animate my main character (my biggest concern), but he also provided beautiful level textures for my maze! I am beyond thrilled with what he came up with. He was also nice enough to put up with me constantly asking for tweaks and changes. I owe him a great debt of gratitude! (And some beers!)

The Critique: What went wrong…

Design & Aesthetics

Networking in general caused a lot of headaches throughout the project, but even something technical like this can trace some problems back to a few early design issues. Treasure Craze was designed with an emphasis on the mobile user, therefore the matchmaking system was designed to be one-click and go. This idea is great if you are playing on the internet and just want anybody to play with. Unfortunately the scope of the capstone led me to only support play over a local network. This ended up clashing heavily during play testing when we had trouble getting all the players into one game. The traditional lobby system would have made a great deal more sense for a LAN only game. At the end of the project Nick Penny suggested adding a drop-in capability to the game. After this was added, it significantly improved the ability for players to connect to a single game.

Project Management

Although most of my milestones went off without a hitch, I did end up falling behind briefly on one of my network milestones and one of my animation milestones. Though I had budgeted a week for each of these tasks, I ended up running into some issues beyond my control. The animation format I chose (*.CMO) ended up having some fairly significant bugs & limitations that had to be discovered through trial and error. On the networking side I chose to use the brand new Microsoft “DatagramSocket” class to do my low-level networking. It too turned out to have a serious glitch that I thankfully found a workaround for online. In both cases I had to hustle to make up time lost due to these setbacks.

On the scheduling side, “Sprints” seemed to work well enough for most of the project. However, I found them somewhat lacking in certain areas. For example: It would have been nice to have a pre-production milestone as well as an “Alpha” & “Beta” submission that were put through more rigorous faculty testing. I also ended up with a giant pile of minor tweaks and fixes that got pushed back because there was no time scheduled to address them. I ended up having so many that I struggled the last month to address as many of them as I could. Having scheduled points throughout development where “polishing is a priority” might have helped alleviate this.  

Development

What went right: Making your own 3D engine.

What went wrong: Making your own 3D engine.

Although the end product turned out well, initial development was at times seriously overwhelming. I knew writing the 3D graphics code would not be an issue (I already knew how). However, I had never before used a networking system let-alone built a new one from scratch! I ended finding some really great resources and articles online that taught me the fundamentals of UDP networking, but it was still a very real struggle to create something usable & reliable enough to build a game around.

By choosing to forego a pre-built engine, I started my project with massive technology debt. Before I could even start thinking about making an actual game I had to write code that would load my assets and draw them efficiently among many other things. I enjoy this type of work, but I certainly wouldn't recommend it for anyone who simply wants to get right to making a game. If you’re wondering why anyone would be crazy enough to do this when things such as Unity & Unreal exist, here are a few reasons:

1. It can be a great learning experience. (I learned all about networking)

2. I didn't have any problems understanding how to use my own technology. (Obviously)

3. Its free! Both now and later if you become successful. (No licensing fees or royalties)

        

Of course there are significant downsides as well, but if you can make your own tech it’s not necessarily a bad idea to do so as long as you know what you’re getting into.

Testing

As noted earlier testing overall was far more of a plus than a minus. If there was any downside to it, it is that I didn’t get started early enough! Because I wrote my own tech, networked gameplay was not available until late in the project. This meant I could not gather large scale gameplay data until things were coming to a close. Had I been able to do this earlier I may have been able to nip some of the early design issues in the bud before they became more serious problems. Although Unit Testing and A/B Testing were interesting ideas, neither ended up benefitting this project. In retrospect I would have preferred to use that time to do another user-analysis study.  

Networking

Networking is tough, do not add it lightly to your project. Even if you have an engine that does most of the heavy lifting, it can still be difficult to detect and debug errors that are caused by the asynchronous nature of game logic based on network events. I wish I had added a logging system to my engine, it would have helped me track and record problems more effectively. I did have output logging in my compiler, but that was of no use once I was running large scale tests with multiple players. An error log is also useful once your game is out in the field being tested on a variety of hardware configurations!

Summary:

Overall I am pretty thrilled with what I was able to produce in roughly three to four months. There are still quite a few rough edges, but that is to be expected for what is supposed to be an early preview of a full-game. I had to make quite few trade-offs during the development to focus on what I felt really mattered. I really wanted to have the game be a fun experience, something that you could play with other people and have a good time. I think I got pretty close to that target. To do so, I did end up trading time I had wanted to spend polishing the graphics or adding an in-game tutorial among other things.

In the end though, I am glad I made those difficult trades. I can always bring those things back into focus in the future. I do want to release the game on the Windows Store, it would be great to do so soon after the Windows 10 roll out. That being said, there is still a great deal of work to be done. I will need to re-evaluate my final design and tone down its scope if I want to make release a reality. I have always wanted to really hunker down and build a game from the ground up. I am very grateful to have had the opportunity to do so.

  

References

Bartle, R. (April, 1996) HEARTS, CLUBS, DIAMONDS, SPADES: PLAYERS WHO SUIT MUDS Retrieved From http://mud.co.uk/richard/hcds.htm#1

Fog Creek Software. (2015). FogBugz [Web Application]. New York: Fog Creek Software.

Norri, L. (2015). Treasure Craze (0.0.1.21) [Windows video game]. Florida: 7th Gate Software LLC.

Sound Ideas (2014) Sub-site of Westar Music Catalog. Retrieved from http://soundideas.sourceaudio.com/