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/

Capstone Game Post Mortem: The Crazy 8

Author

Torrey Daniel

Game App Icon

Title 

The Crazy 8

Genre

Action/Fighter

Platform(s)

Android

Revenue model

Free-To-Play

In-Game Purchases

Interstitial Ads

Development tools/Language

The Engine - Unity 3D

UI - Adobe Photoshop, Illustrator

Sprites – Adobe Fireworks

Version Control – Underdog

Programming – MonoDevelop, C#

API’s & Other Resources

·       Google Play Games Services

·       Photon Unity Networking

·       Cartoon FX Packs 1 & 2

·       MOGA Controller Plugin

·       Set Builders

·       Universal Sound Effects

·       Westar Music Library

Game audience

The intended audience for this game is from teens to young adults. Based on Bartle’s Player Types (Bartle, 1996), TC8 is intended for players who would fall into the Achiever category: Players who seek a challenge and play to unlock all of the characters. With that said, once player-vs-player is added, player’s who fall into the Killer category are expected: Players who play simply to give other players a hard time.

Team

Torrey Daniel - Designer/Developer

Copyright/Reference

The Crazy 8 Copyright © 2015 Torrey Daniel

Backstory

Sound Bite

The Crazy 8: Go In, Go Hard, Go Crazy.

Executive Summary

TC8 is a mobile fighting game with the goal of a classic fighting game experience to mobile devices. TC8 presents a more traditional fighting game play style than most modern mobile fighters.

Inspiration

TC8 was inspired the classic, console and arcade-based fighters. The overall goal of this project was to bring that nostalgic “feel” of playing a classic fighter to the mobile platform, which is a challenge due to the lack of physical buttons.

Capstone Scope

TC8 was a five-month, solo game project, which was completed within Full Sail University’s Mobile Gaming Master’s Program.

Ideal

Ideally, at the end of the Capstone period, TC8 was planned to have a playable roster of 8 characters, 8 playable stages, 6 game modes (Arcade, Time Trial, Survival, Single-Player VS, Multiplayer VS, and Training), all major mechanics implemented, a fully function in-game store, Google Play Game services fully implemented (Leaderboards, Achievement, and In-App Purchases), and multiplayer connectivity.

The Critique: What went right...

Design & Aesthetics:

·       Design Documents:

o   The design documents did well in providing an overall guideline for this project as the contained information that kept this project on track. With that said, I do believe that they could have been managed better (See Below)

·       Mechanics:

o   Out of everything that was achieved in this project, I am most proud of the fighting mechanics. At the start of the project, I struggled to decide exactly how the players should fight. I wanted something that was not too complicated due to device restrictions, while at the same time not as simple as simple swiping the screen to perform actions. In the end, I decided on something that fell between the style of Marvel vs Capcom and Street Fighter. A fighting game would not be a fighting game without combos, which is why I aimed to keep it simple while still requiring a bit of practice, just like the games that inspired TC8.

·       Balancing:

o   Each character has their own strengths and weaknesses. I had to keep this in mind as I created the roster in order to keep each of them from being too overpowered. For example, Sophi and Source Code are capable of performing more elaborate combos than the rest of the roster, but they also deal the least damage. Terrah Bihte and Lance are slower than the rest of the roster, and they’re also less combo-friendly. However, they deal the most damage of them all.

·       Graphics:

o   While the characters are 2D sprites, the stages are full 3D geometry. This gives the game a bit more depth than having a layered 2D background. However, there are a few issues that arose because of this (See Below)

·       Audio:

o   TC8 uses audio that fits the game well. Since voice actors were not an option due to the scope of the project, the game uses simple voices (grunts, yells, etc.) acquired from the Unity Asset Store. The music was acquired from the Westar Music Library, which also fits the game well. There’s different music for different sections of the game. In addition to the Unity Asset store, a few of the sound effects used were also obtained from FreeSFX.com.

·       Narrative:

o   TC8 has announcers that speak a certain points in the game. They are primarily used for announcing things related to the match. There are also loading screens before a match, which tells players their next opponent, and where they will be fighting. Also, character bios are displayed to the players during character selection screen. There’s still a bit more to add when it comes to narrative. (See Below)

·       UI Screens

o   TC8 follows a more dark, less saturated color scheme to fit the serious tone of most fighting games. I designed the overall color scheme of the menus to match the colors of the logo.

·       UI Controls:

o   The UI controls are straight-forward. There are four buttons located on the right side of the screen, and there are directional input buttons on the left side for movement. Players have the option to change the opacity of these buttons.

Project Management

Given what was accomplished within the short scope of this project, I believe that it was managed well. Most of the planned features were added, and what was not added was does not impact the primary features and functionality of the game.

Development

The code is set up well with each mechanic/feature organized in separate scripts. Unity Engine was great to work with. As it stands now, the game is set up in a way that allows additional features to be added with minimal issues. New characters and stages can easily be added with only a few lines of code. The AI has 3 changeable difficulty levels which each behave differently. With that said, there’s still some work needed for the AI.

Testing

During testing, TC8 performed well. The only causes of crashes have been memory issues caused by oversized textures, which were easy fixes by compressing them. Although the tests went well, setting them up was difficult.

Business Model/Plan

TC8 will follow the Free to Play (F2P) revenue model. The game will also use ads that will appear after completing a game mode or receiving a game over. In addition to that, TC8 will also have in-app purchases. The first of which, is the in-game currency. TC8 features it’s own currency called Fight Coins, which is used to purchase additional Sanity Attacks for each character. Players can either ear Fight Coins by playing the various game modes, or by purchasing them in coin packs.

Lastly, at release, there will be an initial playable roster of eight (8) characters. Over time, an additional eight characters will be added. These characters will be released in sets of 2 called Rival Packs. Players will be able to purchase these new characters via in-app purchases.

The Critique: What went wrong…

Design & Aesthetics

·       Design Documents:

o   During the Usability Test, some of the participants made a few suggestions about the layout of the main menu, since then, I’ve been experimenting with other layouts, but at this point in time, I have haven’t decided on a new one. Below is a snapshot of the layout that I’m considering going with for the main menu. Also, I tended to get very carried away with development, which caused me to forget to keep the project documents updated.

·       Mechanics:

o   Although the primary mechanics were added, they are not perfect. There are still a few bugs that need to be fixed, specifically when it comes to collisions.

·       Balancing:

o   The balancing could use a bit more work, but its nothing major. The characters’ strengths and weaknesses could use a bit more enforcing.

·       Graphics:

o   At this point in time, there are still a few placeholder graphics that I had planned to replace by now with other graphics that fit the UI theme better.

·       Networking:

o   One of TC8’s primary planned features was multiplayer. When I began this portion of development, I encountered numerous issues. Because of this, I decided to leave multiplayer out of the scope of the Capstone, and focus on solidifying what was already in place. I still plan to add multiplayer in the future.

·       Narrative:

o   In addition to the current narrative aspects in place, Arcade mode is missing the scenes that tell each character’s story. These scenes would be short, manga-style images that portray the events that lead up to the final boss fight.

Project Management

Although I tried my best to stay on schedule, there were situations where I had to extend the time scheduled to complete a task. This occurred most often during the sprite creation phase, which was extremely time consuming.

Development

The code could have been organized more cleanly with comments and having related methods and variable declarations grouped together for improved readability. The repo should have also been updated more often.

Testing

Although the tests went well, some were quite difficult to set up. This is because I had not planned to test early in development. This made it difficult to isolate the blocks of code being tested because of their dependencies with other scripts.

Summary

Overall, I’m proud of what was accomplished within the scope of the Capstone. The final version of TC8 was not far off from the planned one. The primary fighting mechanics were added, there is a roster of 8 characters, there are 8 stages, and 5 out of the 6 planned game modes were added.

Besides development-related things, I learned quite a lot from this project. My main take-away is project management. Although a lot was achieved, it was difficult to stay on schedule. I also take debugging more seriously after this project. Android’s Logcat debugging tool was essential in finding the dreaded “Out of Memory” error that plagued this project for a while. Also, I learned the importance of making code testable from the start. It saves a lot of headaches when it comes to testing. That would be the only thing I would redo about this project.

For me, the high point of this project was completing the combat system. It took a bit of time to get it working, but once it did, I felt a great sense of achievement. The low point was when I decided to postpone multiplayer. Although I do plan to complete it in the future, I was disappointed that I could not get it working at the scheduled time.

     From here, I intend to continue working on TC8. There are still some bugs that need to be fixed, and features that need to be added. It won’t take much to fully set up achievements, leaderboards, and in-app billing via Google Play. Multiplayer will be added via update after release. Once the game is in a stable condition, I plan to release TC8 on Google Play.

View the Screencast HERE