Game App Icon
Title
Treasure Craze
Genre
First Person Multiplayer Melee Combat
and Item Collection.
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.
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.
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)
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/
