Help us write an episode for Extra Credits

Question

If you don't know of Extra Credits, you should go check them out:

http://www.penny-arcade.com/patv/show/extra-credits

We had James Portnow on the podcast a few weeks ago, and he asked us to send him some ideas for an episode called "So you wanna be a developer".

They've done two previous episodes in the "So you wanna" series:

• So you wanna be a game designer
• So you wanna be a producer

but they don't have personal experience with development and decided to ask us for help.

Now, we have lots of ideas about what makes a great developer and how to get started. For example:

• Code, code, code -- There's no substitute for just diving in and learning to code, and starting is easier than you think.
• Explore -- Don't tie yourself down to one language or approach. Explore other languages, other paradigms, other ways of approaching problems.
• Learn from smart people -- Don't code in isolation. Get involved in an open source project, find a local hacker group, participate in an online site about programming, etc. Find a way to learn from people smarter than you.
• Develop your communication skills -- You need to be able to communicate your ideas to other programmers. You also need to be able to communicate with non-programmers (and this is usually way harder, but equally important)
• Learn other stuff -- Don't just program, also study things like economics, writing, and math. All of these will come in handy, to some extent.
• Ship something -- It won't ever be perfect, but get it out the door. You'll learn more in 10 minutes of letting a real person use your product or a real developer use your code than you will in months of introspection.

Which is fine, but the show is about the game industry and none of us are game developers.

So our question for you is, what's different about game development? What advice would you give to someone who wanted to be a game developer? What skills are more important / less important in game development than other types of developing?

Thanks!

---

Watch So you want to be a Developer (Part 1) at Penny Arcade TV

Watch So you want to be a Developer (Part 2) at Penny Arcade TV

Answer 1

I'm a programmer, and I've worked in the industry before. So here's my list of important skills, from that perspective.

For a Programmer

• Know how to talk to artists. Game designers are generally easier to deal with, but getting through to artists (depending on what field of programing you're involved in) is oftentimes hard. Artists are not like you. Even if they have similar nerdish interests to you, they do not think like you. If your programming duties often push you into contact with artists (ie: you're doing anything with graphics, animation, AI, or sound. So, yeah, probably a lot), you are going to have to learn how to translate things that have meaning for you into terms they understand. And vice-versa.

  Most important of all, be patient with artists. They're smart people; they're just looking at things from a different perspective. If they don't get it when you tell them something, assume that it's your fault and try again. One of the best ways to understand artists is to spend some time in an artists shoes: make an art asset. Grab 3DS Max or Blender or whatever, and make a model. Texture it. Animate it. Good luck with that, BTW ;)

• Debugging. Especially for console developers, debugging skills are absolutely paramount. Consoles these days certainly have a lot, lot more debugging functions than they used to (and those who've coded on older boxes know what I'm talking about). But you're still going to have to know how to use them to track down problems. If you've never had to track down hard debugging tasks like random memory corruption, learn. Oh, and good luck with that, BTW ;)

• Problem solving. The fundamental foundation of all programming is problem solving. You should probably be good at this.

• Know how to program broadly. As part of a programming team on an existing codebase, you are going to be asked to write code in a style that you may not entirely agree with. Maybe you think that smart pointers, RAII, and exceptions are God's gift to C++ programmers. That's great; I totally agree. But if your project as a whole isn't using it, then your code's going to stick out.

  At the very least, if you want to deviating significantly from the established standards of the codebase, talk to your lead first.

For an Artist

• Ask for things. I have found that artists sometimes have a tendency to accept that their current tools are as good as they're ever going to get, and they just deal with the pain points. Don't be that person. If your development studio has people who work on tools, ask for them to address some annoyance. Those people exist to make your jobs easier, but more often than not, they don't use those tools themselves. If you don't have a dedicated tools team, find out who is responsible for maintaining the tools and talk to them about it.

• Learn to talk to programmers. Same deal as above; they're not like you. Their problem solving space is digital, quantified, and precise. Yours isn't. If a programmer lapses into technobabble, let them know that they're talking about something you don't get. Again, be patient.

  Again, to better understand them, take up a scripting language. I suggest Lua, which is both easy to learn and powerful. Try to write something fairly large and complex in that. You'll be better able to appreciate it when a programmer says that something will be "hard".

For a Producer

• Time management. Time Management! Markdown and HTML5 doesn't have enough emphasis for this; I need the old Blink tag back.

  Many of the projects that I've been on that had extended crunch periods did so because of poor time management from production. Features would be cut late in development, well past the time when the writing was on the wall for them. Tech would come online late in development, forcing a scramble to properly integrate it, which won't have been factored into the schedule.

  The job of the producer is to insure that production proceeds smoothly. That everyone is getting done what needs to get done, so that the next part can get done, so that the whole thing can get out the door well put together and on-time. Your entire job is time management. Please learn it ;)

• Make sure that there is an understanding of how new pieces fit into the overall whole by everyone involved. When some new piece of tech comes online, make sure that the people making it know exactly where it needs to go and how it needs to fit into the existing framework.

  Anytime new things happen, make sure everyone knows when they happen, how they happen, what they're for, and how they will be used.

• TIME MANAGEMENT. Did I make that clear? Tasks take time. Don't forget this. Please.

Answer 2

One simple thing: Never stop learning, never stop improving your skills (craft skill and human skill). This industry is crazy fast and if you don't want to learn a new technology you soon will be out of job.
The iPad is 1½ years old right now, but is more successful for Epic than Shadow Complex.

Answer 3

Nicol Bolas's answer is awesome, and amazing, and covers a lot, and gives some great advice. Here's some tips for people who are just getting started (assuming developer = programmer in this case).

• Start small. If you've never programmed anything before, spend some time learning a basic language or two (python, javascript, or actionscript are good options). Don't just start using C++ or even XNA because "that's what the professionals use". Learn the basics so you know about variables, arrays, functions, loops, objects, classes. Then you can start learning how to make games.

• Once you start making games, again, start small. Make a basic text adventure. Make Tetris, or Breakout. Make a game where you avoid bigger squares and "eat" the smaller ones. Make Pac-man. Join an event like Ludum Dare or Global Game Jam, where you spend a weekend making a game based around a theme. Do this enough and you'll get an understanding of how games are made.

• Now you can start making the actual game of your dreams. For a small, simple game (World of Goo, Lyle in Cube Sector, Terraria, Braid), you're looking at something like 6 months to a year of development time, depending on exactly how complex your game is, and how much time you can devote to it per day/week/month. If you're thinking of making World of Warcraft, then go back a step and make Tetris again, because making WoW will take you 10 years.

Answer 4

Just so you know, the first part is now out, check it now. So You Want To Be a Developer (Part 1)

Make sure to go back next week for the second part.

Answer 5

The simple job specification: Programmers are the people responsible for making the game crash.

Or at least that is easily their most notorious contribution.

Thus programmers really need to be the ninjas of game development, being invisible is part of the job. I think a lot of game programmers want more visibility, want to make that contribution that makes people say "Wauw!", they definitely don't want to be the ones who say that's not possible/feasible.

The thing is, for every feature added there is going to be a statistical number of bugs that needs fixing. The number of bugs added per feature will rise with code complexity and stress level.

Try to add too many features and the game will be buggy, try to add too many features and then some, and you get Sword of the Stars II.

Thus if the programming team fails to say no (or someone in charge fails to interpret "no" as no) when too many features are requested the predictable result is that the programming teams contribution ends up being very notorious.

That was a bit of a rant, but I hope it tells something useful about being a programmer.