AMA #11: Tom Hunt, Indie Programmer

TomHunt

ok, so introduction..

I’ve been programming since I was very young – like six or seven years old when I typed in my first game in BASIC.

Worked on a bunch of little things on my own all the way through high school.

Went to college (just vanilla computer science – games-oriented stuff at colleges was very rare at that time).

Then I failed to get a job at a big studio – despite all my years of programming things, i hadn’t actually “shipped” anything commercial – so I wound up working for Microsoft on Windows for a few years

then i realized that was slowly boring me to death and went indie

Livio

oh what part of the windows team?

TomHunt

the team i was on dealt with multimedia content and devices

4lex1v

you didn’t ship any commercial game or just in general?

TomHunt

I wrote automated tests for property handlers for almost all of the various multimedia formats that Windows can handle. It was a job. It paid pretty well. I could go home and play XBox. I was reasonably happy.

hang on let me get to that part 😃

So I’ve been an indie game developer for the past 7-8 years or so

Shipped a couple of mobile games under my own company. Lately I’ve been more focused on contract work for somewhat bigger games. I worked on Act 1 of Hiveswap and am now contracted with Harebrained Schemes working on BattleTech.

I also sometimes like to do game jams

Livio

I see, so you got a non-games programming job because you couldn’t get a games job, then you went indie and shipped some games

TomHunt

Yeah. Pretty much. It was less than ideal, but better than getting a non-programming job.

Livio

We have a question from @esarkis, who couldn’t be here but wanted to ask:
“What advice would you give to aspiring game programmers regarding their coding process? Any tips for sticking with good programming patterns throughout a project and resisting the allure of quick and dirty hacks when the end is in sight?”

TomHunt

coding process.. so, if I’m writing code for something, I usually starting from some kind of task or a bug that is specific. If I don’t know what I’m doing then I need to fix that – through design, architecture, drawing things out, etc. Once that’s cleared up, then boils down to knowing the APIs I’m working with, developing a better understanding of what’s going on and what could happen here, then also testing/debugging until polished.

what advice could i give regarding that..

start with small problems

I just started teaching myself UE4 after having used Unity for the last 7 1/2 years. The first project I’m having myself do is to make a door and to understand how it works.

re: Any tips for sticking with good programming patterns throughout a project and resisting the allure of quick and dirty hacks when the end is in sight?: code review. code review is your friend for things like that.

4lex1v

> Shipped a couple of mobile games under my own company
Could you please talk about this experience? Starting a company, funds, etc…

TomHunt

I was out on my own, a little sour on corporate work in general, still wanted to make games after all these years, and happened to be sitting on a small pile of cash at the time. It seemed pretty obvious to me then that of course I should go into indie game development.

Mobile was still pretty new and hot at the time, and Unity was introducing a way of easily making 3D games for small touchscreen devices.

So I was going after this opportunity and trying to making innovative 3D games for phones.

I was able to support myself full-time for a while, until I managed to get a game out.

Livio

nice

TomHunt

The game didn’t sell very well. I had my first run-in with the realities of the mobile app store market.

The second mobile game that I shipped came along a couple years later. I was doing things part-time by that point and doing non-games contract work to pay bills.

That game didn’t sell very well either, but it was usually pretty impressive to show people at meetups, at least

And even just shipping those two games, even though they sold horribly, earned me the bragging rights of having shipped games, which I had never had before

Livio

are these games still on the app store(s)? are you ashamed of them now that your skills have improved, hehe

TomHunt

not on itunes, because they charge your $99 a year just to exist on their store

Livio

whoa

TomHunt

They’re still on google play tho

Livio

I remember their expensive developer fee, but I didn’t know they’d take you down if you didn’t renew

TomHunt

yeap

am i ashamed of them now that my skills have improved.. hm

I probably wouldn’t use them as prominent work samples. I have other things I can show that do a much better job of that.

But I wouldn’t be ashamed to admit having made them.

Livio

I get that

TomHunt

Especially not when they’re a part of my story as a game developer and how I got to where I am now

4lex1v

Having this experience have you tried to apply to a big game dev studio?

TomHunt

I haven’t tried recently to anyone really big.

Ian P

How do you find smaller developers?

TomHunt

Not sure how at liberty I am to give out specifics, but Harebrained is definitely the biggest team I’ve worked with, and it’s been a pretty good experience for me so far.

Find smaller developers, like to work with?

Ian P

Yeah, either other developers to make a team, or indie teams

TomHunt

socializing

http://Meetup.com has been very useful. Also Facebook.

Living near a big city with lots of game developers / tech seems to be working out pretty well.

GDC

I always meet lots of people at GDC

Livio

Was there a specific way that working at microsoft impacted your game programming skills? Other than just “getting more experience”?

TomHunt

Well, it gave me the experience of working on a humongous development team!

With very old and complicated code to work with

50 million lines of code

over 1000 engineers

that’s bigger than a lot of companies

Livio

oh right, it’s easy to get too used to working on tiny teams when it comes to self-started indie games or side projects

too easy to get used to being the only coder too

TomHunt

You know that was another thing too – there was this experience of being focused on just one particular thing within a much larger whole

When you’re indie you have to worry about _everything_

one minute I could be writing code, the next I’m doing some tax thing

4lex1v

While working on your games have you experienced any crunch time and a following burn-out? Any tips on overcoming it and continue working on the project?

TomHunt

uhhhhhh … yes. i have crunched, and i have burned out before.

My advice would be 1) avoid crunching in the first place, 2) take time off when you need to (mental/physical sick days), 3) keep active within a support group – help others and also don’t be afraid to seek help if you need it, …

I’m a big advocate of working primarily at an office that is physically removed from one’s home

It’s really nice to be able to just come home after work and relax and not think about work for a while before going to bed.

Livio

Co-working spaces are good for that. You pay per desk, and the rent of the entire office ends up being covered by everyone’s desk-rent.

TomHunt

Yes.

We have some great co-working spaces here in Seattle. I think other cities probably have them? I haven’t really checked.

Livio

I think San Fransisco’s equivalent of Indies Workshop is GameNest?

TomHunt

yes

Indies Workshop is awesome

I was there for about a year and a half. Just vacated there last month because I’m working at HBS now.

The Indie Support Group is almost kind of a miniature/free version of that.

Livio

oh neat

looks like the hour is up. any last questions?

TomHunt

there’s still this one from before that i haven’t answered yet: “Any tips for sticking with good programming patterns throughout a project and resisting the allure of quick and dirty hacks when the end is in sight?”

that’s a tough one

because that allure is pretty alluring at that point in the project 😃

there’s different approaches to this – this comes down to engineering, rather than just programming

as the project nears completion, bigger changes tend to be scrutinized more and more heavily

in a team environment this is usually the job of a lead programmer or producer type person

when it’s just you, you have to be the judge of that, and we’re too often not as great judges of this, and so this is how feature creep usually happens and makes your project take 5-7 years

get your big things in, then have the discipline to call it a day on big things, then focus on progressively smaller things until there is nothing left to do. then you’re done

in larger projects, tasks which feel too big to get done by the next milestone are often either cut or postponed

Livio

when you’re done I can give my take on that question, it is pretty tough and interesting to think about

TomHunt

sure

also, code review, like i was saying before.

Livio

First, thanks for taking the time to talk with us Tom. 😃

TomHunt

No problem 😄

4lex1v

Thanks a lot for taking your time 😃 Appreciate it

Ian P

Yeah, thanks a ton!

Livio

As for that programming question, I noticed myself falling into this general pattern:
1) Make the first iteration of a feature, often taking shortcuts and quick and dirty hacks
2) Then as I keep working on the game (fixing bugs, adding new features, etc), I start to notice things about the code that bother me. The more the code bothers me, the more likely I am to eventually get around to refactoring it and doing it a better way that may or may not follow some design pattern.

I think this habit is a result of the fact that I keep getting hired to do preproduction work and rapid prototyping, where you just want to get the idea tested as soon as possible. But because I studied computer science in school, I got exposed to a bunch of programming design patterns, and I’ll often face problems where I’ll readily recognize as “hey, you know what, *this* design pattern is the textbook solution to this problem.”

TomHunt

Yeah the first hack at something is more opportunistic. If I can think of a great way to do something offhand, great, but time and iteration rhthym is more valuable at that point.

I find the design patterns come in much greater handy when it comes time to scale up a project

Livio

One of my computer science professors would talk about “smelly code.” Specifically he taught us a list of common “code smells,” or things that make codebases less pleasant to work in. Being aware of those things can be a really helpful way to properly diagnose problems and just save you energy when making tradeoffs between “should I refactor this to be better, or leave it be?”

TomHunt

a “smell” as I understand it, is a flaw in code that may not be immediately obvious because the code as it is may be completely satisfactory under the current set of requirements, but you sense that those requirements are going to change in a way that the code is going to quickly become more a hazard than a help

Livio

that’s a pretty cool definition

TomHunt

the concept of smells is rooted in Agile, which assumes that the requirements are going to change

Livio

I like how it emphasizes how leaving a code smell in may be a valid choice. There’s no need to run in circles fixing code design flaws in classes that will probably never need to be changed again.

but if it’s creating a lot of bugs and it’s hard to maintain, or if you’re adding lots of stuff to it, then it may definitly be worth investing some time into cleaning up that mess

I usually have a pretty intuitive way of making decisions about that stuff. I usually start by asking “do I *feel* bad enough about this code to change it? Is it *that* big of a pain to deal with, or am I okay with it?” Once I’ve consulted my feelings to figure out whether or not there is a problem, that’s when I start thinking in a more logical or textbook-like way, where I take the foundation of knowledge and experience I have to *diagnose* that problem and find the proper solution. That’s really the core decision-making process I have when it comes to these codebase design issues. It’s also how I approach any design issue: whether it’s game design, web design, etc.

There’ve been times when working on a team when I didn’t care enough about a code design problem, but someone else did, and I just figured “sure, if it bothers them enough, then it’s worth fixing.” I imagine less experienced devs getting into arguments about whether it’s *really* worth the time to fix, but in my book, if someone’s motivated enough to fix it, then it’s probably a problem

there’s definitely a balance though

TomHunt

It’s a management issue. On a team of 1-4 people, you can work that out amongst yourselves. On a team of 5 or more people, you need a dedicated cat-herder

Livio

that’s true

and you definitely don’t want people making truly sweaping changes on a whim when it comes to big projects. and the total knowledge of the entire codebase is split among so many people that you really shouldn’t make big design decisions without consulting the rest of the team since they almost definitely know about stuff you don’t.

TomHunt

definitely not. but those kinds of changes tend to be pretty obvious 😃

and, you know, basic stuff like regular QA, version control – if something like that happens, the damage is contained.

on the big projects i’ve worked on, there’s usually more than enough work items left to do in the system that anyone manning JIRA/bitbucket should be able to find stuff to do for any bored engineers 😃

and with that, i need to step out for a bit

thank you all for having me here 😃

Livio

thanks so much Tom!