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