I've had an admissibly insignificant five years in game development, and I'm still trying to break into the industry; in the process, however, there are some things that I've learned. Indeed, there are some big things that I've learned, and a lot of them.

I've learned from the masters, among them Abrash, Carmack, Egerter, Hecker, LaMothe, and I've practiced and shared what I've learned. I've derived a lot of material entirely on my own.

But after all of this, I've realized that there's something that it might take industry experience, or the company of those with such experience, for one to realize about the fundamental nature of game development, or rather the game developer.

For some mysterious reason, there's a commonly held belief--let's call it a superstition--that game developers are the best of the best in computer programming. Why? I don't know. Perhaps it's because some of them are.

The simple truth of the matter is that aside from the amazing talent and genius that goes into a small part of game source, the rest of it, you could probably write with your current education. Production quality doesn't necessarily mean "the best" in the industry; more often, it means "done".

Don't take my word for it, go download publicly available source to a professional game. If I were to make a reasonable projection, I'd guess the following: You're likely to find a few thousand lines of optimized assembly at most, and a somewhere around a hundred thousand to upwards of a million [depending on the magnitude of the game] lines of plain-old, unadorned C or C++ support code.

The moral of the story is that professional games are projects, not miracles. For a starting company, a deadline can mean make or break. Like movies, production games are a business, and even though their end results can be both entertaining and impressive, they are scarcely appreciated for their artistic purity in the industry.

Ultimately, the success of a movie won't depend on the methods used to film it, but rather on what it looks like on the screen, and what it sounds like in the theatre. The success of a movie will also depend on the construction of its plot, how it moves, and what the critics think about it. The same is true for a game.

Sad though it may be, developers trying to keep a roof over their head can lose interest in the integrity of their code. There comes a point in a large project when one becomes tempted to say, "As long as it looks right, it is right; even if it's not." This isn't an isolated thing; it happens all over the place.

If one wants to exercise film-making as a pure art instead of as a business (entertainment), no one's stopping them. On the other hand, and unfortunately, Joe Consumer of Entertainment isn't going to care about the symbolic significance of the way in which the camera moves, nor the extreme efforts that went into the characterization. Moreover, he's probably not going to go see the movie in the first place if its function is a work of pure art, and theatres are probably going to realize the fact in advance.

It's the same story with game development. Pure games, in an artistic sense, may have every line of code commented, and every approach may be the most efficient one. They may be superb for the text-books, and all-in-all, fantastically constructed. But here again, Joe Consumer of Entertainment doesn't get to see the source code, and he's not going to care how you did it if he doesn't like the way it feels. If it isn't entertaining, he's probably not going to pay for it. Again, publishers are also probably going to realize in advance that this will happen.

If you want to ship in 18 months, and you want to have a roof, you'll end up making some compromises.

On the other hand, a purely commercially oriented game isn't necessarily going to do as well as a more inspired one. Take a look at Myst... pretty successful indeed! Cyan weaved a beautiful world, incorporating artistic and literary elements ad nauseam. At the same time, they came up with a really entertaining game that sold. This isn't an isolated incident either. DOOM and Quake were entertaining, but showcased artwork of a technological form.

This all might lead one to conjecture that the best solution to the problem at hand--the problem of how to write a great game, make a living and ship on time, all in one package--lies somewhere in between good code and bad code. Perhaps the solution to effective game design also lies somewhere between entertainment and art.

The most important thing to realize from this tip about the industry is that you CAN write it. The only question would be: Will you?

Happy designing; finish that game. ;)