University of Southern California Dissertations and Theses

MECHA: a post mortem on exploring independent game development

(USC Thesis Other)

MECHA: a post mortem on exploring independent game development

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content MECHA
A post mortem on exploring independent game development
By
Robert Paul Warren Finney
Master of Fine Arts
Interactive Media & Games Division
School of Cinematic Arts
University of Southern California
August, 2016

MECHA Page 2 of 17
Table of Contents
Acknowledgements ....................................................................................................................................... 3
Introduction .................................................................................................................................................. 4
Solo Development Process ........................................................................................................................... 5
Summary ..................................................................................................................................................... 12
Appendices .................................................................................................................................................. 13

MECHA Page 3 of 17
Acknowledgements
I ask the indulgence of the people who may read this post mortem for dedicating this
project to two people: my Mom and my deceased friend James Dean Wells.
I dedicate this project to my Mom for many reasons: she has always encouraged my
creativity and tenacity, she helped with the project as voiceover for the BrainTree, she was there
for me at a rough time in my life and career despite her suffering nine years of breast cancer, the
list goes on. Most of all, I dedicate this to her because all children are capable of saying their
mom is the best, but I know it to be true in my heart. Skol!
I dedicate this project to my friend Jimmy because he was a part of our nerdy cohort
growing up and we were all too busy having fun playing tabletop and video games to get into
any kind of trouble. He was a friend during the formative nerdy years in my life when playing
video games and the idea of making them became a passion. However, I lost sight of my dream
to make video games somewhere along the way for many years living in LA. His suicide and two
near death experiences within a very short period of time were the eye openers I needed to get
my life back on track and remember the dream to make video games I moved out here to
accomplish in the first place. May the four horsemen ride again.
This project would not have been possible without the help of some extraordinary
individuals: I want to say thank you to my team - Jacques Brautbar, Xiao Liang, and Jamie
O'Connor, the faculty of our program, my advisers in particular - Danny Bilson, Chanel
Summers, and Scott Easley, my friends Elaine, Natalie, Anshul and Austin, my parents, and the
USC Interactive Media & Games Division for providing me with the possibility space to learn
how to make video games and fulfill a dream!

MECHA Page 4 of 17
Introduction
The decision and goal to work individually on my thesis project was one that I've had for
a long time now, going back to when I first applied for admission into the program. I believe this
was strongly due to my interest going into graduate school in exploring an idea for a game I'd
been developing for many years as my thesis project and a potential flagship title for a small
independent game studio. This idea I'd been developing for awhile was in fact my most precious,
darling idea - the game I've always wanted to make.

The game I've always wanted to make has it's roots in my personal story - the story the
game is trying to tell is very much so an abstraction of my journey out west to learn how to make
video games fifteen years ago and being absent most of the time my mom was sick with cancer.
This is represented through the narrative of the game's main quest which entails the player going
off into the world and finding the last seed in order to restore the dying BrainTree, and in turn
restore nature. The game is an action RPG set in an infinite procedural wasteland with roguelike
and survival horror gameplay mechanics.

There are many things to consider before making the decision to go the route of solo
game development. I think unless you feel a deep and personal need to work individually and are
comfortable with your development skills, and the need to grow them as development
progresses, I would strongly advise against doing it. If you like the challenge of becoming a
better developer, and perhaps finding a strength along the way, then this may be a favorable
venture worth pursuing. Personally, going into this project there was a sense of needing to prove
to myself that I could do this, or at the very least, see how far I could get on my own.

MECHA Page 5 of 17

I was curious to explore if minimizing the need for integration time and the inherent bug
fixes that typically come with integration, and at the same time taking advantage of the broad
range of high quality assets available on the Unity Asset Store, could make up for the absence of
a larger team size. Having an undergraduate degree from the Roski School of Fine Arts, the
appeal of an artist's lifestyle working out of an independent studio space and being entirely self
sufficient as a video game developer continues to be the ideal situation I'm working towards.
Essentially, I wanted to explore with my thesis project if I could establish myself in the industry
as an independent interactive artist.

Herein lies the tale of my journey through the process of trying to make the game I've
always wanted to make as an independent, one man band developer.

Solo Development Process
I approached my process for solo game development with a very militant, routine-
oriented mindset. For me to make a project of this scale happen, I knew I would have to dedicate
an extraordinary amount of time to development, and so I established my first rule to work by:
consider this project your full time job and work a minimum of forty hours on the project each
week.

I also went into my thesis prep class with a belief that once I established a prototype that
peaked my interest and felt like it was working towards exploring the science fiction narrative I'd
been working on for years, I should stick with that prototype and continue expanding on the

MECHA Page 6 of 17
experience and functionality of it thereafter into ideally my thesis project prototype. Indeed, my
first thesis prep prototype was an attempt to experiment with people's expectations and creating a
system that did not necessarily cooperate with the player. This took the form of a very John
Carpenter-esque inception scene where the player was asked a series of questions, and a
censoring system I developed for it would eventually begin to black out the answer text options
available to the player and take the choice away from them.

The events and experience revolving around the creation of the player character from my
science fiction narrative very quickly became the focal point of my thesis prep prototypes and
was something I was intrigued with exploring. In terms of process, have or come up with an idea,
and once you're interested in exploring that idea, something I found that has helped me
immensely throughout my game design career is my second rule: always maintain current and
completed task logs! These are really just simple lists in files I created with Notepad. Once I had
the inception of the player character scene in mind, I created a current task log breaking down all
the various tasks I could think of associated with the experience I was trying to develop, with
highest priority tasks at the top and lowest priority tasks at the bottom. Sometimes having a long
current task list could become daunting, and it helped process wise to establish a work routine,
which is my third rule: start your work day by asking yourself a simple question - how many
hours do I plan to work today? My answer would typically be eight hours. Once you know how
many hours you intend to work, ask yourself how many and what specific tasks do you intend to
accomplish or work on for that day? Subdivide your intended work hours amongst your specific
tasks and try your best to hold yourself to that time allocation. I found dividing my time amongst
two or three tasks was the sweet spot for my most efficient periods of game development. Once

MECHA Page 7 of 17
you get into the five or six tasks for any given single work day you risk not making solid
progress any of those tasks and I'd advise against it.

With regard to development during thesis prep itself, I had prior work experience with
using SVN repositories for projects and I strongly recommend you look into using something
like GitHub, BitBucket, TortoiseSVN, etc. For my project, I utilized TortoiseSVN through
Cloudforge and highly recommend it for version control purposes. Unless you use version
control you risk every change you make to the prototype being the one that breaks the project
and will spend a lot of time you otherwise need for development troubleshooting issues.

With thesis prep, I really tried to explore a breadth of player abilities for the player avatar
once I expanded from the inception scene into more of a narrative-light, exploration-heavy
scene. Avatar evolution and transformation became the next focal point, where I explored
recreating the Transform, Rotate, and Scale manipulator tools from 3D software like Maya in
Unity and allow the player to modify the shape and size of their bodies individual cells. I also
had a task goal of establishing a transformation from the player's initial snake form into human
form. Thesis prep became the staging ground for seeing if I could really expand on and establish
the breadth of systems I was interested in seeing in the game I'd always wanted to make. As
much as you may have an established game plan for what your game should be, I recommend to
embrace the flow of wherever your design process may take you. This may sound unwise, but I
found the most creative and cool ideas for my thesis project emerged from going down the rabbit
hole on entertaining an idea that came to me along the way in completing some task I'd set out to
finish. A great example of this would be when I first figured out the player avatar's movement

MECHA Page 8 of 17
would start with their skull slithering across the ground, I instinctively felt that it reminded me of
the movement of a snake and developed follow behavior for additional cells the player picked up
along the way in the experience. But the rabbit hole idea that emerged from that was really
embracing the idea that the player avatar in this initial form is moving like a snake or worm, and
in the case of it moving like a worm, why not entertain the notion that the player could burrow
through the ground? How many games let you burrow through terrain like Minecraft, yet aspire
to have a AAA quality look to them? This opened up entirely new movement and level design
considerations, and got me extremely excited about continuing to work on the project.

While thesis prep was a great experience in terms of establishing the broad systems I'd
hoped to explore for my upcoming year of thesis development, I still didn't have a great idea of
how exactly I wanted the narrative to play out from a moment to moment basis. I had a great idea
of what the entirety of the game narrative would be, but the specifics and details hadn't really
been hammered out yet. Meeting with my chair Danny and getting the advice from him to sit
down and write a beat chart of exactly everything I wanted to have happen in my winter show
experience was invaluable and really helped guide and move the project forward as a result of
creating the beat chart and holding to completing the experience it articulated. In retrospect, I
don't think I met with my advisers nearly as much as I should have and I recommend to do so as
much as possible and makes sense for you.

With the beat chart fleshed out, I then translated the experience within the beat chart into
a burn down chart listing all of the art assets, mechanics, AI, sounds, etc. that would be needed
and allocated time to each of these tasks based on my total hours available for the semester.

MECHA Page 9 of 17
Given my first rule of working at least forty hours a week on the project, my total hours for each
semester typically fell around the six hundred and forty hours available range. I do not
recommend you work that many hours unless you're accustomed to taking many breaks and
balance the amount of time developing your game with a healthy workout schedule and diet.
Working that many hours on a project you absolutely risk burning out, and that's why it's always
good to allocate time in your week to something not involving working on the project. If you feel
like you're getting sufficient exercise, then taking a break to play a game isn't a bad idea and
could inspire you with the work ahead. But I found in order to work that many hours I needed a
fourth rule to my solo development process: establish a routine! What I mean by this is you need
to find that sweet spot of conditions and surroundings to get yourself back into that magic circle
of creativity as quickly as possible. For me, I love working out of my apartment and listening to
music while I work with a clean workspace. I tried to work in the open space environment of
thesis space, but found that it was very distracting. The only way those environments work is if
everyone is a working professional and knows to maintain a general sense of being quiet and or
works with headphones on during the work day (which doesn't really exist in thesis space) and is
mindful of not being disruptive to other people. I think in five hours of working in thesis space I
only got one hour of actual work done. So this just speaks to finding your ideal workspace and
work routine. There's no way you'll reach the finish line with solo development if there are
constant distractions, and one of the inherent benefits of solo development should be a lack of
disruptive external stimuli.

This should have been mentioned earlier, but going into developing your thesis you
should also identify and play to your strengths in regards to the platform you choose to develop

MECHA Page 10 of 17
for and the skill set you bring to bear working on the project. I decided very early on that I
wanted this project to be a PC game that might eventually be released on Steam. As such,
playing to the strengths of making a game for PC meant that I knew I should explore juicing up
the graphic fidelity and quality of the game as much as I could and capitalize on the high quality
visuals PC as a platform provides. This fit perfectly with my strengths as a developer, because I
knew I was pretty good at level design from prior Unity game engine experience. You're most
likely going to have to improve your skills for the aspects of development you think you're weak
at anyways, so you may as well give yourself something of an advantage from the start by trying
to focus your project towards your strengths.

Developing this thesis in the Unity game engine, I wanted to explore if I could utilize the
extensive high quality assets available on the Unity Asset Store in the absence of working with a
team. I cannot recommend using the Unity Asset Store enough. While you do risk a purchase not
ending up being exactly what you were looking for in terms of how they implemented the code
or assets, if you find something your project needs and it's a bit on the expensive time, it can turn
out to be completely worth the investment and ultimately save you hundreds of hours and or
dollars you would have otherwise spent creating the functionality yourself or hiring someone
else onto the project and paying them to do so for you.

In regards to why I decided to develop independently instead of bringing on a larger
team, there were many considerations that went into the decision and evolution of my
collaboration with others or lack thereof. Free work from other students is great, but often times
I've found it to be insufficient for the needs of the projects I've worked on in a collaboration.

MECHA Page 11 of 17
There are several risks to working in a team format that often consume a lot of development
time, but are rarely accounted for in scheduling: integration time, bug fixes, the need to learn or
improve a skill to get a task deliverable to a desired state, misinformation from team member
responsible for completing a task, etc. At the very least, if you plan to ever work in a team format
and not pursue solo development, please account for in your burn down charts and or other
production scheduling means for time required to integrate other people's work and potential bug
fixes that come along with said integration. Minimizing the need for integration with other team
members was a huge part of where I thought I could make up for a lack of humanpower that a
larger team would have provided.

While this thesis project started as an interesting field test of the desire to work solo
development as a one man band developer, I found that the project would have floundered from
my current desired time tables if I had not adapted and been flexible enough to bring other
people onto the team. Through thesis prep and up through October of the first semester of our
thesis class I did a great job of making the one man band developer scenario work and was able
to handle all aspects of development. I knew as a one man band developer I could rise to the
challenge for the code, art, game design, and sound design for the game, but I also knew that if
there was any one area I could definitely use help with regarding development, it would be for
the composition of the thesis project's score. This composer along with finding a marketing
business partner would form the ideal holy trinity of game development long term I knew I was
looking for, but was resistant to exploring initially in my thesis project. I didn't want to break this
rule I set for myself and wanted to explore, but I also didn't want my dream to make this game
die or not live up to the potential it has.

MECHA Page 12 of 17

Thanks to a fellow student organizing a composer pitch meeting with students from the
Thornton School of Music, we had the opportunity to present our thesis projects to them for
potential composer recruitment onto our projects. While I'd been resistant to stepping away from
the one man band approach towards developing my game, I figured what the heck and that it
couldn't hurt to at least see what people might produce for my game with a demo of it in mind.
So I presented at the composer pitch and to my surprise a great number of the composers took an
interest in the project and wanted to work on it. I can't stress how helpful to the project this
composer pitch meeting was and very much so recommend you organize and attend one
yourself. Having eight composers take an interest in my project inspired me like I've never been
inspired before in my life, and I'm very fortunate to still be collaborating with two of them as
team members today.

Summary
The best thing solo development has to offer is the exploration of self as a developer.
You are forced to find out what you're good at and what you're terrible at, which is an invaluable
self awareness as a developer to have moving forward. You're granted complete creative freedom
to explore whatever you'd like the way you'd like to and are acutely aware of the reality of what
you're team is capable of achieving at all times. I think I could have made truly independent
games by myself, but they would have been hurting in the sound department big time. Running a
larger team is a great exposure opportunity to working as a team leader and manager, but you
also risk becoming relegated to only functioning in a team leader and manager role when you
have too many tasks and too much to oversee the integration of into your project. With all that

MECHA Page 13 of 17
said, I set out to attend graduate school to level up my developer skills and make the dream of
developing the game I've always wanted to make a reality, and I realized I couldn't jeopardize the
fulfillment of that dream out of pride to keep the development of it for myself. I'm still going to
explore incorporating my own LLC to work under as an independent interactive artist and
officially hire on team members down the road as third party contractual developers, but I know
that for me to work completely solo is to risk hurting the potential and quality of the project and
ultimately I do hope to find that core group of people I enjoy collaborating on projects together
throughout my career.

Appendices
Original Thesis Proposal:
Robert Finney
Thesis Proposal
Sept. 17, 2015

MECHA

COMMITTEE

Chair - Danny Bilson
Sound - Chanel Summers
External - Adam Reilly

Please see Appointment of Master's Committee Graduate School form.

PROJECT OBJECTIVE

To create a survival horror indie game that captures the experience of what it would be like to be
labeled and hunted as a terrorist.

MECHA Page 14 of 17
PRIOR ART

Don't Starve Together
Predominantly drawing from this game's core gameplay loop to construct my own 3D survival
horror game revolving around the day night cycle of the sun and moon. Resource collection and
consumption will reflect the simplicity of this game to the extent that it exists, as well as random
enemy encounters.

Bladerunner
Drawing from the film's aesthetic, models and classes of synthetic humans, and more
philosophical contemplations of what constitutes having a soul and the desire to seek more life
that will be predominantly referenced from this film.

Hellraiser
Intrigued with creating a resurrection or avatar cellular evolution process akin to the evil Uncle
Frank from this film slowly coming back to life and forming into a human being again in the
upper attic of the house in the first Hellraiser film.

James Cameron's The Terminator
Perhaps drawing most heavily from the aesthetic of the machines and setting in this film, The
Terminator has been an obvious reference point and topic of heated discussion as to how
seriously people and players will consider a game that draws heavily from this movie's aesthetic.
That said, the setting and concerns of the film still have merit and validity to explore through
interactive media.

USC ICT Military Training Simulations: DICE-T & MCIT
Having previous work experience in two military training simulations, I hope to leverage the
techniques, tactics, and procedures I was exposed to during my time working at the USC ICT to
incorporate some degree of the counter-IED threat and bomb detection/defusal process into the
combat and gameplay of my thesis project. This prior work experience will be leveraged
especially in consideration of the experience of being labeled and hunted as a terrorist.

Warhammer 40,000
This tabletop game and science fiction setting is a huge influence and inspiration for the
intolerant, semi-future dark ages setting I'm striving to create in my game, especially the
religious and daemonic aspects of this game world. Additionally, the gargantuan robotic Titans
of this game are inspiration for the late stage cellular development the player will be able to
experience in MECHA.

MECHA Page 15 of 17
PROJECT DEVELOPMENT PLAN

Development Environment
Unity 5 Pro Perpetual Commercial License with initial target platform of PC. Potential support
for Xbox and PS4 controllers.

Eventually porting to mobile/tablet - iOS, and Android pending success of PC launch.

Team
1 Full Time, expanding to 1 Full Time and 2-3 Third Party Developers. Third party developers
would ideally be a marketing/finance person, a sound designer or composer, and a 2D/3D artist.

User/Usability Testing Methods
Primary - Action RPG Gamers (Age: 18-35)
Secondary - Horror Gamers (Age: 18-35)
ESRB rating of E for Everyone

With these primary and secondary target audiences in mind, a bi-monthly test plan will be
constructed around initial playtests involving the primary and then secondary target audiences,
followed by testing with individuals outside of the target audience, and tests with non-gamers. A
lot of initial testing will be conducted with friends and family, with brothers representing the
desired target audience.

MECHA Page 16 of 17
PROJECT PRODUCTION PLAN

Alpha milestone reached in November, Beta milestone reached in April, and Gold Master
milestone reached in May 2016. Expansion DLC packs are tentatively scheduled for August-
October 2016, but these may be pushed back due to patches to the base game.

Expansion
Should the base product be commercially successful, an expansion to the base game will be
considered for future development with a target development cycle of 3 months if the base
game's development cycle achieves its anticipated 9 months of development.

Included in the content of the expansion will be co-op multiplayer functionality to afford other
players and friends the ability to join and assume control of various NPC followers in the main
player's dynamic warband.

DLC
While the base premium game ensures the player will experience the entire game as it was
designed to be ideally experienced, a variety of DLC will be made available to the player to
enrich their gaming experience. The DLC will include at varying costs to the player:
 Avatar Cells, Markings, Heraldry, and Skins
 NPC Follower Skins
 Explorable Territories (Large Set of Multiple Sectors)
 Explorable Sectors (Individual)
 Unique Artifacts, Enemies, Events, NPC Followers, and Gear

MECHA Page 17 of 17

PROJECT BUDGET

Abstract (if available)

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Life On A String: an ink painting narrative game

PDF

Revisions: an exploration of metafiction and metaphors in game design

PDF

FRKN WKND and video game mixtapes: developing talent and experience through video game mixtapes

PDF

Bardcore!

PDF

Stepstone Island

PDF

The Toymaker's Bequest

PDF

OCTOBO: the interactive storytelling plush octopus

PDF

The Distance: a cooperative communication game to long-distance players

PDF

Southland

PDF

The Toymaker’s Bequest: a defense of narrative‐centric game design

PDF

Aether Twins

PDF

Moloch: creating games with alternative mental state goals to move beyond flow

PDF

Building interpersonal trust through digital games

PDF

duOS

PDF

No Ground: a nostalgic play on childhood

PDF

Tracking Ida

PDF

The make of The Surveillant: a thesis project ""postpartum""

PDF

A game called Paako: the challenge of an autobiographical video game

PDF

BONDS: an asymmetrical collaborative adventure game on exploring the player's emotional connection and emergent gameplay

PDF

One little change: exploring relationship abuse in a virtual reality narrative

Asset Metadata

Creator Finney, Robert Paul Warren (author)

Core Title MECHA: a post mortem on exploring independent game development

School School of Cinematic Arts

Degree Master of Fine Arts

Degree Program Interactive Media

Publication Date 09/08/2016

Defense Date 08/01/2016

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag Development,game,independent,indie,minimal,OAI-PMH Harvest,Solo

Format application/pdf (imt)

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor Wixon, Dennis (committee chair), Lemarchand, Richard (committee member), Watson, Jeff (committee member)

Creator Email finney@usc.edu,robert.finney@gmail.com

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c40-302288

Unique identifier UC11279428

Identifier etd-FinneyRobe-4780.pdf (filename),usctheses-c40-302288 (legacy record id)

Legacy Identifier etd-FinneyRobe-4780.pdf

Dmrecord 302288

Document Type Thesis

Format application/pdf (imt)

Rights Finney, Robert Paul Warren

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA