Work-Life Balance, and Finishing a Game

It's been a month since my last post.

Traditionally, I've been pretty good about keeping a rhythm on this blog. One post, bi-weekly for over two years, save for the occasional vacation. And even then, I was usually quick to make-up for lost time.

Lately, though, it's been harder to keep up that rhythm. For one thing, it's getting harder to find topics that are both relevant and as-yet uncovered.

Two years ago, I had seemingly endless questions about becoming an indie developer. How much money does it require? What's a day in the life of an indie like? Why do developers choose to become independent? I tried to dissect each of the events and considerations I faced, in an effort to draw back the curtain for others.

The bigger issue, though, is psychological. As I make NEO Scavenger's final push to completion, I find I'm using every bit of energy I can muster to stay on-task. Despite what I can only describe as a surprising success so far (positive feedback, encouraging sales, acceptance from vendors, and even Greenlight approval), I feel emotionally drained, fearful, stressed, and distracted.

It turns out that this isn't unusual. I definitely struggle with perfectionism, often putting off finishing something because I'm not completely happy with it. And two (plus) years on the same game/engine/job/problems has dulled that once-sharp edge of excitement and novelty.

In the aforementioned article, Ms. Saunders's suggestions for dealing with those blocks are helpful, too. Itemized to-do lists are definitely a huge help, particularly when the tasks are smaller and well-defined. The days when I can't stop working are those when my direction seems clear. Conversely, those that are the most grueling are when my task is large and poorly-defined (e.g. "finish NEO Scavenger's plot").

Recognizing the effort expended vs. the effort remaining is also useful. I'll admit that starting a new game looks enticing, to the point that I could find motivation to work on it in my spare evenings and weekends. But taking a look at how much effort it took to get here, and realizing that I would be here again in two years, helps put things into perspective.

Prioritization is also key. There are several areas which I try to balance in my life. Listed in order from most to least important:

1. Maintaining relationships (spouse, family, friends)
2. Staying healthy (i.e. eating right, getting enough sleep, getting exercise, avoiding crunch)
3. Running my business, Blue Bottle Games
4. Developing my first game, NEO Scavenger
5. Running this blog

That is to say, if something higher up on the list is threatened, something lower gives. So things like vacation, weddings, and funerals usually trump everything else (even healthy sleeping and eating, as a recent funeral has demonstrated). I'm also pretty rigid about not working on evenings and weekends, and eating at regular times (with a few exceptions).

Numbers 3 and 4 have been more demanding lately, not to mention s summer thick with number 1, so blog posting has admittedly been swept aside. And even then, skipping the blog only frees up a few hours every two weeks (normally), so I shudder to think where else the squeeze has occurred (I'm looking at you, number 2).

All things considered, I think I'm surprisingly still pretty healthy in my balance. I still quit at 6:30pm each day, and don't touch work on weekends, except to deal with occasional emails (less than 1-2 hours per weekend).

It's been hard to focus, though, and stress is at a local peak. I'm gritting my teeth again, clenching my jaw unconsciously, and my mind wanders at any possible opportunity. I had a good day, Friday, when I refused any internet distractions for most of the working day. I got a lot done, and I felt better for it. But it was a slog.

I think this is the way it's going to be until I finish NEO Scavenger and launch it. And even then, the prevailing wisdom is that it just gets more stressful in the subsequent months. The road's getting tough, and the toughest is yet to come.

How I Got Into the Game Industry

Last post, I talked about training to be a game developer. A lot of the discussion centered around where to obtain the skills for entering the field. The sobering, and unsurprising, answer is: practice a lot. Whether via school, at work, or on your own, the more practice you have, the more marketable you are.

However, that's a fairly theoretical scenario. Real life is rarely as clean-cut and well-planned as sitting down for a few years and coming out the other end ready to go. In order to provide a more concrete example, I want to talk about the path I took. It's not the ideal path, and probably not even a common one. But it shows how much a portfolio and work experience can influence hiring, and how persistence and hard work pay off.

Education

Let me clear this up first: I didn't enroll in a program designed for the games industry. I studied physics at the University New Hampshire. It was a good school for physics, but terrible for games. It had zero offerings in game-related studies. Not even a computer graphics lab (i.e. no 3DSMax, which was a bit crippling, in retrospect). I'm not even sure I realized I could be a game developer at the time I chose my major.

Basically, I liked science, had an interest in space propulsion and power production technology, and figured I could turn that into a career as a researcher. Low in-state tuition meant I could go there without bankrupting my family and saddling myself with insurmountable debt. And I had some friends going there, too.

I don't think it was until my junior year that I started to realize my heart was really in making games. All my spare time was spent playing games, picking through their data files, modding them, and tinkering with art software (from DPaint and Degas Elite to TrueSpace 3). I spent a summer working on a Rifts total conversion mod for Dark Reign. I penned a prodigious amount of role-playing game scenarios, settings, rules, and even designed some new systems.

Sprites from my Rifts total conversion for Dark Reign.

In retrospect, I should've seen it sooner. I just didn't think of it as a "real" career. And by the time I started to realize how wrong I was, I was way behind the curve. Spotty art portfolio, barely passable programming experience, one published article about swing dancing in the university magazine...I had a lot of dabbling in all the right areas, but I needed to get my act together.

I did have some things going for me, though. I worked hard to finish my degree, and I took all my courses seriously. I poured my heart into creative writing assignments, and milked the single art class my curriculum was afforded. I designed posters for the local theater troupe, and worked as designer on the school magazine. I got a job in the space science center, scripting tools to work with satellite data. My senior project was working on a Faraday ring ammeter instrument for satellites, which has zero application to video games itself, but sure turns heads on the resume.

I was also an early adopter in the burgeoning field of web development and design. I was fortunate that the campus was quick to adopt site-wide internet access, so I spent a lot of time tinkering with websites. Most of it was tabletop rpg stuff: character sheets, campaign settings, play-by-comment adventures (like play-by-email, but with a webpage thread).

Post Graduation

When the time came for graduation, I tried applying to a few game studios (among other, more physics-appropriate jobs), but I didn't know what the hell I was doing. It showed, too. I scraped together all the art I could find on my hard drive, but no game studios were interested. I still have my rejection letter from Greg Zeschuk, politely telling me they didn't need anyone with my skillset at this time at BioWare.

I did, however, know more than your average person about website design and development. And in the late 90's, knowing how to piece together a webpage was a golden ticket to employment.

Unlike games (and even physics), finding work as a web and print designer in 1999 was dead-easy. Within a few months of graduating, I had a job at one of the biggest publishing companies in the world as a web developer and designer. What's more, it was my ticket to living in a place I've always wanted to: New York City!

Left: My office. Right: My apartment.

First Career

Being a web developer wasn't my first pick for a job, but man, was it an awesome ride. I made friends with folks from all over the world, I worked on a huge range of technologies and design styles, I made great money, and all while living in one of my favorite places.

What's more, there was so much work to be had that I was approached by a coworker who needed to offload one of his clients. In one of the more significant career-coaching conversations, he told me "you're worth $50/hr with this, and he'll pay it. Don't accept less." Sure enough, the client did test the waters, but I was firm at that rate, and got it.

What's more, a lot of the tinkering I did with 3D gave me a huge advantage in the web/print design arena, as it was a novel art asset to bring to bear. I had several smaller contracts and jobs going on the side, for wide-ranging amounts of compensation.

The extra work was both educational and lucrative. I had my (modest) student loans paid off within two years of graduating, was debt-free, and was able to start saving. I learned how to manage clients, assess requirements, and work without supervision.

Lucrative!

I also learned how devastating overwork could be to stress levels.

Career Burn-Out

By this time, my full-time role had evolved from web developer to project manager and lead designer. I had a small team under me, clients to manage, websites to keep running, and development teams to liaise with.

My freelance life was no less demanding, it just used my free time instead of business hours. I got calls and emails at almost all hours, had many late nights, and pulled at least one mid-week all-nighter.

And all this time, I had a growing feeling that my heart just wasn't in it. The novelty of my first job, first apartment, and the big city were all wearing off. I still wanted to make games, not publishing and medical journal websites. Even some of the more exciting website IPs, like Elvis, Dr. Seuss, and Playmobil paled in comparison to the possibility of working on the next Neverwinter Nights or Elite.

My employers were good sports, allowing me to add web games to our portfolio of offerings, but our clients needed websites, kiosks, media players, and back-end technology more. My job was simply not the right venue for what I wanted.

Bootstrapping a Game Portfolio

Realizing that web development wasn't the end-game for me, I redoubled my efforts at building a portfolio in my spare time. I offloaded my lucrative web client to a friend, and started reaching out to game studios and projects.

My online portfolio, vintage 2004.

A buddy of mine, already in the games industry at this time (a then-recent animation grad of Pratt Institute), helped me to understand the prevalence of 3D Studio in the games industry, so I obtained a copy and taught myself modeling. I also set forth on learning to code. It was a whirlwind of self-education:

• I bought a Wacom tablet and started teaching myself to paint in Photoshop.
• I modeled and textured vehicles and weapons for an Unreal mod (unpaid)
• I did sprite work for a side-scrolling computer game (paid $50)
• I bought a book detailing the character modeling process, and followed along with my own character.
• I did some 3D character prototypes for an action-adventure game (unpaid).
• A web-acquaintance and I combined efforts on a Herzog Zwei remake, just for fun. (Sprite and terrain texture work, mainly)
• I wrote a side-scroller prototype in Allegro C. 
• I wrote an asteroids-clone, a particle physics demo, and some funky header procedural animations in Flash.
• I made a spaceship model in 3D Studio and wrote a DirectX app to fly it around.
• I took a traditional animation course at a local art school.

All the while, I applied to every job and recruiter I could find, within reason. If the job involved games and looked even remotely applicable to my skills, I applied.

Fishing for a Job

I had a few nibbles. Raven Software got back to me, offering me an art test from none other than childhood hero, Kevin Long. They were working on a new iteration of Quake, and asked me to do a 3D model of a muscular arm with cybernetics. I fudged something together, sent it in unfinished, and never heard back. An important lesson here, for any readers that missed it: either do the art test 100%, or not at all. Nobody likes a half-assed job.

My buddy also tried to pull some strings at his studio, Cyberlore. Alas, they didn't have room for greenies like me. He did help me quite a bit with polishing my portfolio and website, though. Having someone with a critical eye to say "that one's not worth showing, focus on these, and beef-up this area" was a huge help.

One bite which went a bit further was a call from Turbine. They needed an art intern for their upcoming MMO, Dungeons and Dragons Online. I dressed up in my interview suit, hopped a train to MA, and met my interviewer in the parking lot...wearing shorts, a t-shirt, and body piercings. Employees hushed and whispered as I walked the aisles, and later, I found out folks thought I was their office's lawyer.

Despite that, the interview went well. I spoke with several team members and managers, and was shown around the project space. However, when it came time for the offer, I was in for a surprise. "I don't think we can give you this internship," he said. The job was unpaid, would end after the summer, and there was no promise of renewing my contract. Despite my willingness to sacrifice my career and relocate for the job, it didn't sit well with them.

BioWare

In February 2004, I sent my resume to BioWare again. A lot of the positions I applied for so far were either 3D or 2D artist positions, or interface/graphic designer roles. This one was a tech artist position.

Weeks went by with nothing more than the auto-responder to tell me they received my application. However, almost two months later, I received an invitation to interview by phone! I could barely contain myself over the next several days. Anticipating that call was all I could think of.

The hallowed halls I yearned to enter.

The call itself went well, and I was given an art test to gauge my abilities. My test consisted of modeling, texturing, and lighting a section of sci-fi hallway illustrated in a provided concept sketch. I was given a polygon budget, a texture file size budget, and instructions for sending the materials back when done. It had to be done in 3D Studio Max, and I was told to keep track of my time spent working on it. Color scheme and areas beyond the field of view in the illustration were up to me.

Unlike the Raven Software test, this time I followed-through. Every part of the test got my best effort, and I made sure not to leave anything unfinished. Some areas were more polished than others, of course, but nothing was left incomplete.

It was another two weeks before I heard back from them, and this time, it was for an in-house interview. Interviewing is a complex-enough topic that it could warrant its own post (or book, even). However, suffice to say that I was polite, professional, honest, accommodating, and eager. (I again wore the suit.) I was required to relocate away from my favorite city, and my starting salary was a huge pay cut. I'd have to climb the ladder all over again.

I wanted it, though, and was willing to work for it. I got the job.

Post Hiring

It'd be tidy to say that that was it. I got hired, and the rest is history. I could sit back and enjoy the spoils of my victory.

However, I didn't look at it that way. And I still don't. I continued to operate in "interview mode" for pretty much my whole career there. Every single day at BioWare was a chance for me to prove myself worthy of their taking a chance on me. Humility, eagerness, and diligence were my tools of choice, and I credit much of my success there with those traits.

99% Perspiration

Looking back over this story, that's what made everything possible. Keep working hard. Work honestly. You know when you're putting in 100% and when you're dogging it, so don't cheat yourself. It took me six years of kicking my own ass after I decided in mid-university that games were for me. Six years of part-time portfolio-building for games, mixed with full-time, tangentially-related IT work. And six years of rejection letters (if any response at all).

And even then, I got the role because I made a good tech artist, not because of my artistic skill. In fact, when I asked point blank whether I could fall-back on an artist job if I wasn't a good tech artist, they told me "no." In retrospect, I'd likely have needed years more practice in art if I wanted to go that route. Tech art just happened to be a growing field at the same time I was (unknowingly) training for it.

So work hard. Put in the requisite time, and practice. Don't give up. It won't be an easy ride, nor a short one. But if it's what you want, you'll work for it. And employers will notice the applicants that do.

Training to be a Game Developer

Recently, I posted a massive brain-dump on /r/gamedev, in an effort to further disseminate some of the info I've collected here. The results were very positive, and I'm thrilled that so many people found useful topics to peruse.

One question came up, however, which involved an underrepresented topic on my blog: training. Further, another developer pointed out that most of my advice was more applicable to folks who already had skills and experience in game development.

With that in mind, I thought I might share some of my experience on training and skills in game development, both as an indie and a former decision-maker in hiring at BioWare.

How to Become a Skilled Game Developer: The TL;DR Version

If I were to summarize this post in one statement, it would be this:

Learn and practice your chosen craft full-time for 5 years.

There. That's it. That's all you have to do. Figure out what it is you want to do as an indie or game industry employee, and start learning and practicing the craft full-time. That means 8 hours per day, 5 days per week, taking time for holidays and vacation. Do that earnestly, and you'll be a skilled game-maker and master of your chosen craft in about roughly five years.

Already have a job? Cut the hours per day down, and add an appropriate number of years. E.g. 4 hours per day instead of 8 with 10 years instead of 5, or similar.

What About School?

That's a good question. What about school?

Consider [the way we define] a master's degree. In much of the world, a master's degree represents professional-level mastery in a practice or field of study. It is typically about 2 years of advanced study after completing a 4 year bachelor's program.

According to the ECTS standard, that equates to roughly 1500-1800 hours of study per year, over 6 years. By comparison, one year of full-time work represents roughly 2000 hours.

Masters program = 6 years * (1500 to 1800 hours per year) = 9000 to 10,800 hours.
5 years full-time = 5 years * (2000 hours per year) = 10,000 hours.

As an aside, Malcom Gladwell has written an interesting book about several of the world's great success stories. One thing many have in common? 10,000 hours or more of diligent work in their field. It's not the only thing that got them there, mind you, but I tend to agree with him that it's an important component.

Is School Better Than Self-Training?

That's hard to say, really.

On one hand, an accredited degree program includes much more than simply study of related topics. It includes experience with different learning methods, socializing in different settings, learning to be independent of one's family, access to contacts in academia and industry (including valuable experts, a.k.a. professors), and access to facilities that would often be beyond the reach of a single person.

On the other hand, school isn't always the wise investment it used to be. With tuition rapidly outpacing housing costs, and free educational resources abundant all around us, one could probably have an equal (and sometimes, better) self-directed education.

Some Degrees Are Better Than Others

If you do choose to attend university, carefully consider the program you're following. Some degrees carry more weight, and are more valuable in the world, than others. The same goes for institutions.

When I was a hiring manager at BioWare, I looked at a lot of resumes and portfolios. I not only made decisions on hiring for my own team, I sat in as an advisor on decisions for other teams. When deciding on which applicants to invite for an interview, we looked at three things:

1. Their work experience.
2. Their portfolio.
3. Their schooling.

Numbers 1 and 2 were, by far, the biggest factor across all hires. We wanted to see what you've done, and if that level of quality was high enough that we wanted you on the team. A killer portfolio of work (art, mods, tech demos, etc.) would almost guarantee an interview. Similarly, a significant role on an awesome game or team would get our attention.

In the absence of those two (or sometimes, despite them), school could sometimes tip the balance. Seeing a programmer graduate of University of Waterloo or MIT, or an art student from Sheridan would usually be a worth a second look.

However, unless the school was reputable as a consistent, quality source of students in the given field, it rarely did more than tell us the applicant had enough diligence and social grace to graduate. Important skills, no doubt, but not exclusively learned in a university, and not enough on their own to warrant an interview.

Work Hard, No Matter Which Path You Choose

One thing is certain, though, and that is discipline matters. Whether you enroll in an university program, or decide to teach yourself, take it seriously and work your ass off. Kicking your own ass to learn as much as possible, and putting that into practice, will put you head and shoulders above the sea of applicants around you.

Whether watching online courses and practicing your craft, or sitting in lecture halls and doing homework, the amount of effort you put into your education will matter more than where/if you enroll.

Be Well-Rounded

One thing to be careful of, whether studying in an accredited program or on your own, is to be well-rounded in your curriculum. Skill in your craft is important, but fairly useless if you can't relate it to the rest of the world.

Learn a bit about history, psychology, art, science, writing, and anything else you can manage. Learn the scientific method and quantitative analysis. Learn objectivity, various problem-solving methods, how to brainstorm effectively, and how to find info that you need.

And please, for the love of all that is holy, learn how to work well with others. In fact, make this your top priority. I can tell you with 100% certainty that if you are a douche, your career will be short and painful. You could be brilliant, a virtuoso, or a damned modern-day Leonardo DaVinci. But if you're also a douche, you're out. (Unless you're a rich-enough douche to call the shots, in which case your career will be longer, but probably still painful.)

Also, a note of caution: some crafts are less employable than others outside the game industry. If you can't think of another industry using your skills besides games, you may want to consider making said craft secondary in your studies. Look for complementary, more in-demand areas to study, and use that as a way into games. You can still specialize in your preferred craft, but you'll have a broader skill to fall back on.

As an example, I know quite a few game designers who were programmers or quality assurance before they became designers. In contrast, I know very few designers who started out in the industry as a designer. As another example, most of the tech artists I worked with came from programming or art backgrounds. None of them came from a "tech art" degree program.

What Did I Do?

So how did I get into the game industry? A little bit of everything above, amounting to a mainstream education mixed with lots of self-training in my spare time.

I started describing that process here, but it was quickly turning into a story of its own. So with that in mind, maybe it's best saved for a separate post.

Stay tuned for part two!

Fake Graphs About Real Things

I have a tendency to be pretty verbose in my blog posts. My typical topic length has inched ever higher over time, and I think it's starting to impact my comfort level in starting new topics. Each new post, it feels harder to write about something because of the growing number of things I've discussed, and the growing number of words I seem to use each time. And as readers, I'm sure the sight of a wall of text is none too enticing.

This week, I had an idea for something different: fake graphs about real things. Basically, there are some concepts in game development that seem like they are easily described in graphs. They're not always possible to quantify, but the trends are pretty easy to qualify. Like describing volume as a function of distance from a speaker, or speed as a function of time spent accelerating, we can describe certain things in our industry in relation to other values.

So, before I accidentally type another paragraph, let's start "graphing!"

Fig. 1: Amount of time spent actually working on game over length of project.

The above one's pretty easy. Particularly if you're a solo indie, this is what you should plan for. In fact, it's a bit incomplete:

Fig 1a: Everything else you'll be doing.

Oh, and one more thing:

Fig 1b: It ain't over 'til it's over.

Here's another one for those running a game-as-a-service or Minecraft-like beta funding model:

Fig 2: Anxiety as a function of build release schedule.

Those with heart conditions shouldn't wait too long between releases! Particularly if:

Fig 2a: Ohgodohgodohgodohgod!

This one, while sobering, is probably no surprise to most:

Fig 3: Game sales over time.

"That's not so bad," you might think. But we may be missing some points of reference:

Fig 3a: WTB rent-free treehouse with free electricity and internet...

There are a few things you can do to help, though:

Fig 3b: Or this might just be a NASA pulsar graph

Each of these peaks will likely have a diminishing effect on the subsequent peaks, as market saturates and relevance decreases over time.

You could also try adjusting the price of your game:

Fig 4: Sales as a function of price.

$0 is a popular price! Conversely, not many people are into mortgaging their homes to buy a game. Though, as the app store has shown us, there are 8 people who will buy your game no matter what (1 of which, accidentally).

How does this look in terms of actual money? Probably something like this:

Fig 4a: Number may not actually be magic.

This assumes some minimum price, of course. Most places aren't selling games for $0.000001. If that were the case, the vertical slopes would be more gradual.

Let's talk about another topic. Phil Fish has recently made the news (again), and you might be wondering what you'd do in his shoes. Being criticized can be unpleasant, but not all criticism is created equal:

Fig 5: Amount of attention paid to criticism vs. how much I respect the critic.

Put another way, if someone is the type of person who slings insults at complete strangers over the internet, it's hard to take them seriously. After all, with such a low barrier to lashing out, they probably do it to everyone. I might even feel left out if they didn't.

Similarly:

Fig 5a: Attention paid as a function of bias.

Overly negative (and positive!) commentary isn't very useful, so I tend to pay the most attention to balanced critique and critics. Overly biased feedback is about as helpful as a ruler with all 8s.

Speaking of usefulness:

Fig 6: Likelihood of reading feedback as a function of its length.

If I open up an email or forum thread, this is pretty much how things are going to play out. Don't get me wrong, the following is also true:

Fig 6a: Wanting and doing are different things, though.

But if it's going to take me 30 minutes to read, 15 minutes to digest, another 10 to re-skim, and then an hour to reply...well, I might not. Of course, I tend to dwell in the far right hand side of this graph when writing, so there's some irony/hypocrisy to be had here.

And while we're on the topic of weaknesses, here's a big one for me:

Fig 7: Desire to postpone decision as a function of its importance.

Decisions can be hard. Big decisions even more so. While it can be healthy to take time to consider options when faced with a decision, it can be unhealthy to postpone for too long:

Fig 7a: "Just a little more research..."

The important feature of this graph is the peak and subsequent negative slope. For every decision, there is some amount of consideration that is optimal, and beyond that, an ever-increasing opportunity cost. The real-world version of this graph may be bumpy, but the general form is the same.

There are more, of course, but this is already quite a bit. Let me know if you found this format to be helpful, entertaining, or even erroneous. And enjoy the break from my walls o' text while you can!

The Hardest Part of Making Games

I was playing Rock Band the other day. We dug the plastic instruments out of storage, and fired up the 360 to dust off our faux musician skills. And at one point, we played Nine Inch Nails's "The Hand That Feeds."

As the little, colored notes dropped off the screen, I found myself imagining how cool it must be to make music like that as a career. I love musical instruments, and to be surrounded by synths, sequencers, 1/4" audio cables, humming amps, electric guitars, and mixers would make my day.

I've dabbled in composition from time-to-time, and I've even had some relatively pleasing results. Sure, they're amateur at best, but creating them was fun. I actually long for the time when I'm simultaneously un-busy enough and motivated to get back into that.

That last thought brought me back from my daydream, even as the colored notes continued. "I'm too busy and too tired," I thought, "because I already have a cool day job like that." It was as sobering as it was uplifting.

In reality, Trent Reznor probably doesn't sit in his studio, admiring his collection. He doesn't sit with a cup of tea, trying out all the synth presets on his Korg M1. He doesn't feel the blissful absence of pressure as he surveys his laboratory.

Mr. Reznor has a business to attend to. He has music to compose, a brand to promote, investments to consider, and relationships to manage. What we picture him doing each day is blissfully ignorant of pressure.

What's So Hard About Making Games?

Like with music, I think there are many on the outside looking in at game developers. Each has their vision of what goes on in a developer's day, and some are more accurate than others. Some may picture developers coding away in the late night hours, illuminated by a cold monitor. Others might picture long conference tables, half-empty pizza boxes, and colored dry-erase diagrams.

Some people picture...other things.

So when it comes to game development in practice vs. imagination, what actually goes on? What are the types of work being done? Are any of them pure enjoyment? Tedium?

And what is the hardest part?

As with music, games are complex products, the creation of which involves a wide variety of tasks. How hard or enjoyable each of these tasks is will depend on the person(s), their abilities, and their preferences. It will also depend on the type of game being made, the tools being used, and the project constraints.

Since NEO Scavenger and Blue Bottle Games are primarily a solo project, I wear a pretty good number of hats. I do most of the dev work, content creation, business administration, and I've even collaborated with a few talented individuals.

What follows, then, is a review of the types of things I've had to do as part of developing NEO Scavenger and running Blue Bottle Games since it started. Along with each, I'll try to call out some of the more enjoyable, challenging, and tedious aspects of each.

If you're considering getting into game development, maybe this will help illustrate some of the rewards and challenges you'll face. And if you're already there, maybe it'll comfort you to know you're not alone :)

• Game Ideas - It won't surprise you to learn that this is one of the easier, more enjoyable aspects of game development. I love coming up with ideas. I can't not do it, in fact. When I get up from bed to go to the bathroom at 3am, I have new ideas by the time I crawl back into bed. I have journals stacked in a drawer with ideas, a massive folder on my hard drive, another on Google Drive. When I bought my first Palm III, it was so I could jot down ideas as I rode the subway to work. I gave up a lucrative job at BioWare so I could make my ideas into games. I've been known to turn down perfectly good ideas in favor of coming up with ideas of my own. Have I mentioned I like coming up with video game ideas?
  
  While usually not tedious, there are a few times when it can be frustrating to come up with an idea. Usually, this is because one needs an idea for a specific problem, but none are coming. Ideas pour when they rain, but they're not always what you need when you need them. They're also notorious for derailing otherwise productive work with distraction.
• Research - This one's a bit like ideas, above. I have to restrain myself from researching things if given the chance. Before I start drawing something, I research it. Writing about something? Research. Start building a new system? Research what other games do.
  
  Research can be tedious, of course. Plowing through an academic paper is rarely as instantly gratifying as Wikipedia. And many times, there are conflicting sources that need to be resolved. Vocabulary can also cause research effort to mushroom, as one is confronted with a wall of unfamiliar terminology.
  
  And then there's the question of research's value. Some of it is justifiable, as research can reveal useful strategies or opportunities. Most of the time, though, it's a guilty pleasure that gets in the way of real work. The challenge is often keeping that in check.

Not the hardest part of making games.

• Pixel Art - Drawing game graphics is moderately hard work, but I enjoy it. It was harder and less enjoyable when I started, as the results were more frustrating. However, with practice, I'm getting better at producing the level of quality that I want, and I enjoy the process more. (The process grows faster, too.) The least enjoyable part of this job is when a piece requires other "infrastructure" art to help it.
  
  For example, drawing a new rifle is lots of fun. Drawing that same rifle again and again, once for held, worn, and stored versions, and again for the combat UI, then all of the above again for the strapped version, again for the scoped version, and again for the strapped, scoped version? Tedious. I'd rather draw a new rifle. However, for it to work in the game, it needs all of its requisite art done, not just the fun part.
• VFX - This one can be a lot of fun, but also very frustrating and complex. The cool thing about it is that subtle changes in code and art can make some really spectacular and interesting things happen. It's almost like a mini game development project within a larger project. (E.g. programming the flying, blinking lights in the Detroit map within NEO Scavenger, below).
  
  The hard part comes when the VFX requires complex algorithms, wrangling multiple coordinate spaces, or bypassing limitations in the platform (e.g. alpha blending that doesn't kill performance).

• Audio Design, Recording - Audio work is something I am terribly amateur at, but still enjoy immensely. As hinted at in my musings about Trent Reznor, I'd love to sit down with some audio equipment and just noodle for days. And I've even afforded myself a few such days during the course of NEO Scavenger, field recording, cutting and looping effects, and even composing a title screen piece (mercifully replaced by Josh Culler's great soundtrack work).
  
  It's not fun all the time, though. Sometimes, it means listening carefully to hours of recorded audio for useful bits, cleaning them up, slice and package them, and labeling them with tags for reference later. And in the worst cases, it can be doing this process over and over until it sounds "right."
  
  Frankly, producing good audio is a full-time job of its own, and I haven't given it the love it deserves. It's beyond my capacity right now, as features and bugs eat the lions share of my development time. I still want to, it's just been back-burnered while fish are frying.
• Programming - This is where a lot of time is spent. If I had to guess, this probably takes the largest share of my time. For just about everything I create in NEO Scavenger, some coding needs to be done to make it appear. Even coding sometimes requires more coding to work (i.e. bugs).
  
  As I approach the end of the project, that seems to be changing, though. Most of the early art/writing/design was for new systems that needed to be built. Now, I'm mostly filling in content variety in established categories, so the coding is shifting more towards maintenance and fixes.
  
  The difficulty and enjoyment in coding varies pretty wildly. Like with VFX above, coding can sometimes mean big changes from little code. This is also often the case when adding a design feature. At such times, coding is my favorite task.
  
  At other times, coding is a tedium that is hard to endure, or impossible to sort through. Rewriting the GUI for NEO Scavenger is one process that was agonizingly boring and involved. And some of the more complex problems can involve abstract and difficult thinking, especially when the system one is building is dependent on one or more systems that also haven't been built (or defined) yet.
• Writing - Writing may actually trump artwork, in terms of time spent on tasks. NEO Scavenger is pretty heavy on text, so a lot of work goes into planning and creating that text.
  
  As with many tasks above, there is fun writing, and there is boring writing. The fun writing comes when my brain is in the right mode, and I have trouble keeping up with it. The story just seems to flow, and I always know what to write next (at least roughly).
  
  The tedious part of writing comes when one needs to handle all the peripheral infrastructure. In NEO Scavenger, players can take multiple paths in encounters, and that means those paths have to be written. The tedium is helped a bit by the fact that I try to make each path interesting. However, nothing helps that sinking feeling when I realize, "ugh, they might do that, and that means a whole new string or tree of encounters I need to conjure up."
  
  The hard part of writing is rather like what I described in programming, above. When so little has been defined, it might seem like one has lots of freedom. However, that freedom can be paralyzing, as one is constantly second-guessing whether the idea or character is plausible, interesting, or whether it might sabotage the story somehow down the line.

"...and the player will be able to choose ANY action they want!"

• Game Design - Design is a bit hard to separate from the above, since it involves almost all of them. On a good day, it means recognizing clever ways of making two systems interact, producing a complexity greater than the sum of its parts. At times like these, one can almost enjoy their own game as if they're a new player, watching systems interact in surprising ways.
  
  On other days, there is a design problem that appears to have no good solution. I've spent days on some problems: thinking; starting down a path; recognizing a new issue; erasing; repeating. It can be very disheartening and frustrating. Sometimes, the problems with a new system don't emerge until all the work is done. Then, it becomes a trade-off between spending extensive time fixing, or extensive time rebuilding.
  
  And tedium can rear its head here, too. Some systems require reams of data entry and proofreading. Other times, navigating a web of interdependencies to ensure the systems don't undermine each other.
• Build and Platform Management - This refers to the process of getting the game to run on the platform of choice, whether it be a browser, Windows, Mac, or Linux. It also refers to the process of getting that game into the hands of the person who needs it, be they oneself, a collaborator, or a customer.
  
  I'll admit, there's little here that I enjoy. I'm thankful for some of the experiences I've had in making NEO Scavenger cross-platform, but I wouldn't call the work enjoyable. Mostly, it's a mixture of tedious and challenging.
  
  The challenge is usually wrestling with the idiosyncrasies of each platform, be they resolution, user input devices, UI conventions, performance, or unexpected bugs. Flash helps with much of this, but as it turns out, causes almost as many problems.
  
  The tedium is usually the actual build process for me. Creating each of the platform builds requires a lot of PC-hopping, file uploading, changelog-writing, and form-filling.

They LOOK friendly enough...

• PR - Interacting with press and public is a job in itself, and can take as much time as you offer. There will always be more conversations out there about your game than you can handle, so you have to set some limits to leave time for game development.
  
  Without a doubt, reading press and player feedback is my favorite part of PR. Praise can be highly motivating, as can constructive criticism. Even knowing that people are simply playing the game can raise one's confidence.
  
  I also enjoy learning about the art of promotion, and creating plans for publicity (e.g. special events, giveaways, strategic link placement, game festivals, etc.).
  
  I'm terrible at executing those plans, though. I hate asking people for things, so cold-calling press outlets is hard for me to do. I also have a hard time pulling the trigger on a PR event, knowing that "just one more" fix or feature would improve the first impression, perpetually delaying my plans.
  
  When it comes to customers, some interactions are easier than others. I love helping people, so if my response can offer something useful to the player, I feel good about it. Conversely, if I don't have anything helpful to offer the player, responding stresses me out.
  
  There are critics out there, but they're actually not as stressful as you might imagine. In cases where the criticism is valid and constructive, it's actually welcomed and helpful. And in cases where it's more insult than critique, it's easy to disregard.
• Team Management - NEO Scavenger may be a solo endeavor, but I have had help along the way. And most of my experience prior to Blue Bottle Games was with large teams.
  
  At its best, teamwork is awesome. Being surrounded by talented, creative, and motivated people can make you do amazing things, and create stellar products. Some of my happiest moments (in any career) were when surrounded by a tight team of bright minds with a shared vision.
  
  Working with Josh on NEO Scavenger's music, and Cameron on NEO Scavenger's story and design, was equally inspiring. They could see things I missed, and offer ideas I never would have, helping to produce a fuller, more professional game experience.
  
  If there's any tedium I experienced, it was due to one major mistake I made: making myself the bottleneck. There's nothing more mitigating to a high-performance machine than forcing it to drive in rush-hour traffic, and that's what I did with Josh and Cameron. I never built the infrastructure for collaborators to contribute directly, and I wanted to own as much of the process as possible. As a result, I slowed down their progress. One could argue that I failed at one of the greater challenges of team management: delegation.
  
  Of course, there can also be bad teams. I've been on my share of those as well, and they can cause no end of tedium and frustration (for both the members and managers). Diverging goals and opinions, authority issues, poor communication, and lack of clarity can ruin even the best collections of talent. Bad teams are jobs in themselves, and making games becomes a side project compared to keeping things from melt-down.
• Business Analysis - As with PR, this is an area I enjoy exploring quite a bit. And that came as a surprise to me.
  
  Learning about economics, business strategies, and entrepreneurship can be really addictive. I enjoy looking at the game I want to make, the market it's trying to reach, and hashing out features, pricing, sales channels, and partnerships to make it viable.
  
  Running the numbers can be tedious, of course. As can digesting info to keep one's picture of the market up-to-date. However, there's a certain Skinner-like reward to reading news about the industry, and suddenly recognizing an opportunity your product is poised to take advantage of. It's one of those rare moments in life when your "money-making idea" can actually do what it says on the tin.
  
  The hard part, here, is often just finding useful information. Nobody is in the business of writing "A Market Analysis Tailored for Dan Fedor." There's a lot of filling in blanks with educated guesses, extrapolating data, and in some cases, blind faith. Will your next game idea be a hit? Nobody knows. Even the AAA analysts are clueless here.

Let's not forget DIY desktop support.

• Testing and Debugging - When folks say things like, "oh, you just play games all day?" this is probably of what they're thinking. And they're wrong.
  
  Just about everyone on a game dev team tests and debugs their work. Or at least, anyone worth their salt does. Fire up the game, navigate to the area where your recent work shows up, and start testing it.
  
  This can actually be a pretty fascinating area of work. It rewards good experimental method, note-taking, statistical analysis, and deduction. Sometimes, it can feel like forensics or detective work. And yes, once in a while, you get a chance to play through a section to see how it "feels."
  
  Unfortunately, this type of work can also require a lot of patience and persistence. It's not good enough that one tests entering combat and exiting again. One has to test cases where the player initiates combat with AI, AI with player, player with AI already in combat with AI, AI with player vs. AI. What if the player dies instead of leaving? The AI? What if one AI leaves and another stays? What if the player leaves, and more than one AI stays?
  
  There can be a combinatorial multitude of scenarios to test, and doing this job right means testing them all. Worse yet, once a change is made to the system, this entire suite of tests needs to be run again. And changes to the system are always happening.
  
  Some testing can be quite frustrating, too. A notorious example in NEO Scavenger are the null-pointer bugs that only show up later in a game session. They're frustrating because the cause is unclear, and one must play the game for long periods before the bug might appear. And often, the symptom of the bug varies from game-to-game, making it hard to tell if two bugs are related. If the bug cannot be caused reliably, and requires long periods of play to trigger, imagine trying to fix it. And worse, verifying that the fix works.
• Project Management - In an ideal world, each developer could just release the game they want, when they want to. In reality, the pressures of time, budget, and manpower impinge on that ideal. Project management is the process of quantifying those needs and constraints, and finding the compromise that balances those forces best.
  
  A lot of folks picture project management as Gantt charts, scrum, status meetings, and spreadsheets. And a lot of project management involves those things.
  
  However, all of us do some amount of project management subconsciously when we assess the value of a new feature against our capabilities, schedule, and budget. Whether it's a customer asking for widescreen format support, or a teammate asking for alpha channels in their sprites, we're assessing cost vs. value somehow in our decision-making process.
  
  There is little that I enjoy about this process, honestly. Gathering data can be a lot of work, it often involves telling people "no," and the results are based on a lot of guesswork.
  
  That said, the process can reveal useful questions and concerns that are missed in more casual assessments. It can also serve as a common reference point for discussions among others. Even as a solo developer, it can be very helpful to have a to-do list that I can sort by effort, value, finished/unfinished, or other criteria.
  
  So, for me, it's one of those things I'm glad to have done, but dislike doing.
• Taxes and Accounting - If you're running your own business, the CRA/IRS wants to know what you earn. And likely, you'll want to know as well.
  
  There is nothing enjoyable nor rewarding about doing taxes. It is 100% tedium and challenge, so I'll leave it at that.
  
  Accounting can be grueling, but the rewards are there if done right. It's important to know how one's business is performing, in order to make sound decisions. And it can sometimes be an ego boost if sales are good. But it's a lot of careful, detailed work, and it can involve some challenges of data-management and research.

More fun than taxes.

Some Additional Hard Parts About Making AAA Games

There are quite a few other areas that I could discuss, particularly from the point of view of a larger team. NEO Scavenger is a pretty small undertaking compared to AAA efforts, and I don't (yet) have to worry about such things as:

• Animation - Either traditional or 3D rigging, keyframing, motion capture, and the like.
• 3D Modeling - 3D models include characters, environment art, props, etc.
• Materials - The development of textures, shaders, and other surface material properties for models.
• Lighting - 3D worlds, and even some 2D worlds, require sources of light to be placed strategically.
• Cinematics - Positioning cameras, moving them around, as well as managing the content being shown, settings for playback, and related work.
• Localization - Translating the game for multiple markets.
• Physics - Assigning volumes and physical properties to items in the game world.
• Licensing - Negotiating permission to use licensed properties.
• Other - And everything else I've forgotten about.

What is the Hardest Part About Making Games?

So what is the hardest part about making games? You may have noticed a pattern in the list above, having to do with the aspects which I find tedious or difficult. "God is in the detail," as they say, and this is as true in game development as any other field.

Dabbling in an art or science is fun, but due diligence is work. The hardest part of any task above is when I have to get my hands dirty and follow through with all the details. There's a reason organizations usually have a limited number of leaders with the broad-strokes vision, and an army of workers to do the detail work.

However, even the tasks listed above are manageable on their own. Many are measured in hours, days, or weeks, and not much worse than school assignments in that respect.

The hardest, in my opinion, is finishing a game. Spending hours each day, every day, consecutively for over two years. Waking up on day 520 of NEO Scavenger, and finding the motivation to do one more. That's the hard part. I like making games, but even I get tired of making the same game after all that time.

Don't mind if I do.

The hardest part of making a game is finishing it. For all the things I can do on my project, that's the one I still haven't.

Game Dev From the Ground Up

Recently, some of the players on NEO Scavenger's forums posted a request for advice on how to start making games. I've talked quite a bit about bootstrapping indie game development here, but a lot of my focus has been on the business aspects. I do mention tools and techniques here and there, but they've been spread across two years of posts, and are often directed at a somewhat more experienced crowd.

Today, then, I thought I might take a bit of time to walk newcomers through the field. There's a ton of info out there. And sometimes, that can be just as bad as there being no info out there. How does one know they're following advice or tutorials that will lead anywhere? What if one follows a tutorial, only to find that it dead-ends somewhere down the line?

As it turns out, there's both good and bad news here. The bad news is that false-starts are common. Even experienced devs are lured into dead-ends. Technology is an ever-shifting field, and games even more so. It's easy to commit time and resources to something that won't pan out, and that's par for the course.

The good news is that there's usually something to be gained from such failures. This is particularly the case for beginners, where every step is contributing to new skills and perspectives, if not the end product. When one is a complete beginner, there's nowhere to go but up.

Where to Go for Info

As already mentioned, there are billions of places to get info on developing games. Google searching can be a bit daunting:

Better make some coffee...

So how does one know where to start?

I considered compiling a list of indie development resources, but then I remembered that someone has already gone through the trouble. In fact, many people have:

1. Pixel Prospector maintains a gigantic list of indie resources. It's probably one of the most comprehensive lists on indie game development tools, techniques, and wisdom, collected from around the web. http://www.pixelprospector.com/indie-resources/
2. TIGForums is one of the more active independent developer forums. Subforums abound, covering every aspect of development, including creative, technical, business, and tutorials. http://forums.tigsource.com/
3. Gamasutra is a major source of all things gaming, with a focus more on the developers than consumers. There is a vast catalog of knowledge here, including news, tutorials, GDC videos, jobs, and op-ed. http://www.gamasutra.com/
4. StackExchange is probably one of the most valuable places to know about when trying to find the answer to a technical question. The questions and answers are usually of high quality and value, owed in part to their curation and voting mechanisms. Many of my epic quests for esoteric programming or technical knowledge end here. http://stackexchange.com/
5. Daniel Cook's blog posts are also a good place to read about game design, business, and the craft in general. Aspiring indies who struggle with art may be particularly interested in his article about sourcing game graphics. http://www.lostgarden.com/2008/07/directory-of-posts.html

Some folks like sharing what they've learned, which might make this a good time to mention an important lesson I've learned: see if someone's already done the work for you. The internet is a pretty amazing thing, giving us near-instant access to a growing proportion of all human knowledge. When it comes to game development, a lot of the problems (most, in fact) are ones that have been tackled before. It's worth doing a quick search first, just in case someone's already saved you the trouble.

Which Tools to Use

Choosing a platform, engine, tools, or project management method is like choosing a religion: fanatics are everywhere, and will try to sell you on their favorite. But in the end, just about any of them will teach you something, even if it's that religion isn't for you.

Again, I'm going to harp on Pixel Prospector. One of the first links they list covers a vast list of tools and engines. Read what people say about them. And more importantly, look up what people are building with them. There's no greater proof of a tool's validity than the thing it was used to create.

What did I learn on? Well, this:

Computers can do ANYTHING

I also learned by copying BASIC code from Antic magazine into an Atari 800, and watching the results go. Also, trying to emulate Leisure Suit Larry as a text app in my junior high computer class, using BASIC on an Apple IIe. And taking a "programming for engineering" course at univeristy. And buying 20lb "Learn 2 Program" books from Barnes & Noble, and copying their C-code into engines like Allegro. And writing Flash apps for my web development employer. And following Microsoft's XNA banner for a while.

The point of my telling you this isn't to say that I've had a lot of training. Most of the above was better described as "flailing," or maybe just "failing." And even the things that did succeed became obsolete with time. Technology comes and goes fast, as do platforms.

The point is to learn something in the process. All of the above taught me bits about how computer programs work, how information is organized, how logic controls data in an application, and how bitmaps work. Sometimes those lessons were learned while modding Dark Reign. Other times, I wrote code that put pixels on the screen in a starfield, and I moved them about in sloppy for-loops.

What's my tool of choice? I'm a fan of Flash's Actionscript, and flixel. Actionscript is a c-style, object-oriented (OO) language, which is a good type of language to learn. Many game-related technologies are c-style, OO languages:

• C/C++
• C#
• Objective C
• Flash
• Unreal/UnrealScript
• Java
• HTML5/Javascript
• PHP
• Perl
• Haxe/OpenFL (a.k.a. NME)

Learning one is usually a good head-start in any of the others.

Flixel is a game engine built on Flash actionscript, and is a good balance of existing systems and free-reign to do what I want.

Would I build my next game in Flash/Flixel? Probably not. Flash is starting to limit me in some ways, and I'm looking towards Haxe and HaxeFlixel as a next step. It takes a lot of what I like about Flash and Flixel, adds some powerful abilities to it, and frees it from the clutches of Adobe (and the Apple-Adobe-Android wars).

That said, building something in Flash/Flixel now should put one in a good position to transition to HaxeFlixel later. They're similar enough that learning one teaches most of the other.

Hello, World

And once you've chosen your tools of choice, what then? Should you write an epic design doc, plan out all the facets of your game, and start building?

I'd focus on "Hello, World." If you can get code to compile and display that phrase on the screen, there's nothing stopping you from writing "Health = 100," or "You are standing in an open field west of a white house, with a boarded front door."

Or simply print some ascii art, and let the arrow keys move it around the page. Or maybe write some text about how much candy you have. Or how your dwarves feel.

The point here is that once you've got something displaying on the screen, the rest is just tweaking and watching the results. NEO Scavenger was originally a sprite of a man, and clicking a button moved that man closer to a dot. Each time he moved, his sleepiness went up. If you clicked another button, he slept, and his sleepiness went down. I kid you not.

So choose a tool, any tool. Search Google for:

tutorial "hello world" <tool name>

and don't give up!

Return from Vacation, and the Road Ahead

I apologize for the previous gap in updates. Rochelle and I were at the beach with my family for a few weeks, and I made it a point not to do any more work-related stuff than was necessary.

I could get used to these.

Unsurprisingly, work still crept in, here and there. I cut down my email and web administration duties to once every other day, but it still took a few hours each time. There isn't really anyone to cover for me in these cases, so I'm on the hook for order issues, spambot surge mitigation, and customer inquiries. One alternative would be to "go dark" for several weeks, but that seems like an irresponsible thing to do when running a business, particularly where customer support is a component.

As such, vacation wasn't a complete break from the stress. Nothing critical arose during the break, thankfully, but it was still something that was in the back of my head. Work check-in was never more than a day or two away, and more significantly, a giant to-do list awaited me when I returned.

I think that while previous vacations have taught me that vacations are necessary and healthy, this vacation added the caveat that vacations can be diminished by obligation. Basically, there would either have to be no obligations to fulfill, or someone to fill those obligations for me in order to completely relax, stress-free.

The former requires that NEO Scavenger be finished and support-free. Admittedly, that goal is pretty far off, if even possible. More than likely, there will be a long tail of support and attention required, no matter how bulletproof I make the game. Platforms evolve, partnerships are formed, and other changes in the business landscape mean that a product is never truly dead (see Homeworld, Wasteland, etc.)

The latter requires that I expand the team, which is a daunting goal in itself. Questions of trust, availability, motivation, and compensation are each topics that require their own, significant, due diligence. I've long been reluctant to let anyone into the sandbox, and these are some of the big reasons why.

It's time to "start finishing."

As such, my current goal is to "level up" NEO Scavenger, and make it newsworthy again. A little more work, and I can at least consider the demo "done," making it ripe for sharing with portal sites like Kongregate and NewGrounds. That should hopefully make new players aware of the game, and if the beta looks like a worthwhile-enough upgrade, drive new sales as well.

The increased awareness would help with the Greenlight campaign, which is a bid for more PR and sales in itself. There are some contests I'm considering, as well as some "taste makers" I'd like to finally contact, now that NEO Scavenger is maturing.

And if things go smoothly, I can see either finishing the home stretch personally (albeit slowly), or maybe investing a little money to speed the remainder of the content work.

It's a scary moment, one of those crossroads where I endlessly find excuses to avoid taking the next step, but it's time to get into high gear. Whatever happens, I'm already happy with the outcome so far, and I only have more to gain from moving forward.

Plus, peace and rest waits for me over that next hill, and I never thought that would be such an enticing goal.