Disclaimer: Please try not to be scared of Angry Joe – he’s only a stick figure. In fact, he doesn’t even really exist. Steel yourself, read on and ride the storm. It’ll all be over soon.

There seems to be a lot of ideas held by new developers which, quite frankly, are leading them in the completely wrong direction. One could be forgiven for holding most of these assumptions: after all, they’re usually the result of laymen looking at the AAA industry through rose-tinted glasses and thinking, “Gee willikers. This is what game development is all about!” But that doesn’t mean that they’re correct.

Dev.Mag’s roaming correspondent, Angry Joe, dislikes these sort of ideas. In fact, he does more than dislike them. He feels that these game development hoaxes are discouraging new devs, destroying careers and undermining the very fabric of indie society. And this makes Angry Joe angry, because he doesn’t know what to do about it aside from telling as many people as possible how terribly, terribly wrong they are.

Angry Joe has graciously decided to grant an interview with Dev.Mag to outline some of the most common game development myths and dissect them with a series of coherent, level-headed arguments. His words may be harsh, but his advice is solid – so pay heed to Angry Joe as he metes out the opinions of experts and veterans in order to slam down false thinking and neophytical hubris.

Myth #1 – If you can code, you can make games

Q. Angry Joe, is it true that learning how to program well is all that you need to make good games?

AJ. The whu-? Of course not! What are you, an idiot? Programming is a key component of game creation, but that’s only a part of the broader issue. It’s like saying that you can instantly make great games if you’re an artist, or a sound engineer. Or a particularly ambitious jar of pickles. It’s like saying that you’ve built a skyscraper because you’ve successfully mixed the cement for its foundations.

Q. We’re not quite following you here.

AJ. Take a look at the front page of Gamasutra. You see those five little categories on the left? There’s a section for programming, yeah, but there’s an entirely different one for design. The Great Games Experiment also has these categories separated, and the Game Career Guide sports two separate feature articles geared at helping designers and programmers separately. The truth is that game design is a skill in its own right. That means that you have to practice making games. You have to read up on making games. You have to think properly about making games. If you waltz in with your pithy programming experience and state that you’re automatically an authority on game design,you are being an ass.

Q. That sounds a bit extreme.

AJ. No, it’s not. By claiming to know good game design before you’ve even started with it, you’re delivering a slap in the face to every single designer-by-career dev out there, most particularly the ones who have poured years of hard work into their craft. Take Tim Lang, for example. Whenever he says that he makes games for a living, people immediately ask him if he does programming. Of course he doesn’t, and I bet that those sort of questions really tick him off. Heck, I know it would irritate the living crap out of me.

Q. So you’re saying that developers are wasting their time by learning how to program?

AJ. No, stupid. I’m just telling them not to get a big head about it. If you’re a good programmer, that’s fine. But you’re still going to have to learn the game development ropes like everyone else. Keep your head down and exercise some damn humility.

Myth #2 – You need to start from scratch

Q. Okay, then let’s try a slightly different question. Do you believe that programming a game engine from the ground up will help you understand games better?

AJ. No, it’ll just help you screw them up better. How the heck are you supposed to make your own engine when you haven’t even tried somebody else’s yet? Stuff like XNA and Game Makerare out there for a damn good reason, and they’re made by people who already have a clue or two about what’s needed in game development. They’re not just sitting pretty and collecting glitter, either: some really crazy stuff has been made with these tools and quite a few projects have gone as far as the IGF.

Q. What we’re trying to get at is–

AJ. Shut up. I know what you’re about to say, and you’re being a damn moron. Getting down and dirty with something like raw C++ may sound helpful in understanding the support structures of game code. But there’s a stark difference between the building blocks of generalprogramming and game programming. Remember that Game Career Guide article I mentioned earlier? Look down at point number three: they suggest only an INTERMEDIATE knowledge in C++, and that’s if you’re going to be dedicated SOLELY to programming!

Sure, you may know how to prevent stack overflow and manage your memory well, but exactly how does that help you figure out how to set up the right classes for a game framework, or anticipate the code that you need for game-specific problems? Kyle Gabler spent ages getting together a useful game framework, building upon his experience by actually constructing and expanding on real games instead of fiddling around with inconsequential technicalities. Sure, you could draw a triangle without using any hardware calls, or work out 3D math from scratch, but in the end only one question matters: have you actually made a damn game with it?

Myth #3 – People will steal your ideas

Q. Okay, let’s leave coding alone and move along. What do you have to say about the threat of people stealing game ideas from budding new developers?

AJ. Not much, aside from the fact that people who think that’s going to happen are idiots.

Q. Why?

AJ. Because it’s like me stealing an eight-year-old’s creative writing piece and trying to hand it in as my PhD research paper. It’s a stupid concept that’s held by arrogant, clingy little snobs who think that every single one of their precious little ideas is an instant goldmine of creativity, sunshine and unicorns. The gaming industry has existed for, what, three decades now? Chances are that – at some point in your past – your current idea has been thought up, mulled over and eventually used to line someone’s litterbox because it was already old ten years ago.

Q. But surely you can’t deny that the theft of ideas does occur from time to time? We’ve all heard the horror stories, after all.

AJ. Dude, yeah. It does. Big whoop. The entire gaming industry has become an incestuous hive of crappy ideas that are simply being repackaged, recombined and rereleased with a slight twist to appease a slavering player base. This isn’t necessarily a bad thing. I, for one, have gone absolutely insane for XBLA’s new Lode Runner offering, which is basically a nice-looking rehash of a game that was originally released way back in 1983 and has enjoyed about seventy gazillion remakes since.

And what about PopCap’s latest game, Plants vs Zombies? I bet that a lot of people have had loads of fun with this already, but it’s basically a glorified version of the same old Tower Defense schtick. Nobody cares who made the game concept first: they only care about who has made it well … if it gets made at all, that is. After all, nothing’s going to happen at all if developers just sit on their concepts and sulkily hide them from everybody else.

Q. What about more original concepts like Spelunky? And Iji? Wouldn’t it have been, er, rather crappy if somebody else had gotten wind of these ideas and made another game first? It kinda steals the thunder a little.

AJ. Okay, doofus, maybe I need to explain again. Firstly, even I’m not enough of a dedicated dick to learn about some guy’s prototype, play through it and instantly decide to make a full game from it before they do. Not to mention that this would be extremely difficult to do if, you know, the original creator could actually be arsed to do the legwork and release the final game him/herself.

Secondly, I know that Dev.Mag has conducted interviews surrounding both Spelunky and Iji. In both cases, the same question has cropped up: the source of inspiration for the game. And lo and behold, the game’s authors cited other people’s games as the progenitors of their ideas! Ask anybody else the same question, and you may be surprised by the number of times that people admit to drawing inspiration from other titles. Heck, even a generic run and jump platformer could be seen as shamelessly ripping off freaking Super Mario.

Myth #4 – You have to build a team immediately

Q. Teamwork and communication are pretty important when it comes to game development. How should developers go about gathering a team for their first project?

AJ. Oh, COME ON! Where do you people learn all this crap? Team work is great, but only when there’s a call for it. Little Dirkie von Flubberglub’s Sidescroller of Minor Shootey Rubbish isn’t going to need more than a solitary developer hacking away at it. Heck, a lobotomised monkey could do that job by itself.

If you’re going to get involved with a project big enough to warrant a team, it’ll be at a time when you have way more know-how under your belt. You and your fellow devs will all need to have a fair amount of experience with making games on your own before jumping into a team project. Working with other people makes things more difficult even when everybody concerned knows what they’re doing – hopping onto the “I’M IN A LARGE-SCALE PROJECT YAY” bandwagon too soon will only compound problems. It’ll probably also provoke Giant Daikatana Arrow Syndrome.

Q. Okay, but sometimes there exists a harsh reality: not all of us are great artists or sound wizards, and need a little bit of assistance here and there to create an acceptable product.

AJ. In cases like this, the team formation process should be purely organic. Don’t set up your “New game Thredz of ULTRA COOLS!!1!” and immediately bawl for people to come help you on a project that doesn’t exist. Churn away at a game prototype, use whatever resources are available to you and focus on making things fun. If somebody shows an interest in a product that you’ve already put a fair amount of work into, you can then request their skills for the betterment of your game, mankind and your own demented ego.

Myth #5 – Your first game will go big

Q. Okay then, final question: what do you do if your first project just happens to be “the big one”?

AJ. *snorts*

Q. What?

AJ.It won’t be, you tool. Simple as that. I’ve never juggled in my life – do you think I’d be able to pick up a bunch of flaming knives and start throwing them about right now?

Q. There’s always a small chance of success.

AJ. Yeah, a really small chance. But people keep treating it like it’s a really big chance. Which is stupid. Your first game isn’t going to be the killer app – and even if it is, you can probably just deal with it when the situation arises. Regardless of how good it turns out, though … well, I believe it was Derek Yu who once said, “Don’t sell your first finished game.”

Q. It was. We interviewed him about it.

AJ. Just shut up and listen. I take Yu’s words to heart. I really do. Too many new devs are so caught up in the potential glory of their projects that they lose sight of where they are and what they really need to do. Their heads are filled with glossy visions of fame and fortune, and sometimes they just wrap themselves up in that daydream instead of realistically sitting down and tackling their job one step at a time. It’s kinda stupid. Saddening, too. But mainly stupid.

Q. Well, thanks for the interview, Angry Joe. It was a pleasure to chat to you, and we’ll do our best to take your advice to heart. I’m sure that our readers appreciate it too.

AJ. Yeah, whatever. I still hate you. Now when am I going to get paid for all this crap?