So I have this game idea . . .

If you're on this page, you either clicked because you thought it might be interesting (exploration is good for you!) or I sent you here. If you're in the latter category, please note that by linking you here, I am trying my level best to help you. I do not mean to offend your sensibilities, and I feel like you can genuinely benefit from the following advice.

I get the title interlude every now and again. It's not always a game—sometimes it's a library or an application. But they have one thing in common. To be blunt, they are completely unrealistic.

Now, I consider myself a spectacular programmer. My recent code (e.g., my maintained projects) is crisp, clean, relatively robust, and intuitive. I hack these up in days, if not hours. My calculator is Python Shell. So, I know about the mentality. Perfect programmer syndrome is real. But maybe you think you're even better, since you're out in the real world and you're enjoying success on non-trivial problems. "I'm the greatest programmer,", and "All that is just pessimism about lesser programmers—I'm different.".

No, you're not. You might be a cut about the rest, and you might have exceptional talent.

But you're not a deity.

I will not tell you what's possible and what's impossible, but I can tell you what's probable. What's probable is one person learning basic programming in a few weeks or months, writing a small game from scratch in a few weeks time, and enjoying some success before moving on to bigger things. What's not probable is for one person to learn basic programming "as they go" and write a WOW-killer, or the next FPS overnight, and enjoy worldwide fame. What's even less probable is for someone to help you if you approach programming like that.

Suppose you're just starting out in graphics, and you want to make the next great game engine. Noble goal (maybe), but what's the difference between specularity and reflectivity? Can you write a good solid FBO class to back up your multi-pass deferred renderer? Is a bitonic sort appropriate for fragment OOT? Will you support hardware tessellation, or will you emulate it with geometry prepasses and the transform feedback buffer? Will your internal format store triangle adjacency for stencil effects on manifold meshes? How will you deal with the extra overhead—keeping in mind that not every GPU supports geometry shaders for runtime generation? Does your matrix class store data in column-major or row-major order—and will it link nicely with GLSL matrix uniforms? Will you accelerate complicated operations with OpenCL or something like CUDA—or maybe even CPU acceleration through MP's #pragma directives? What is the winding order of your triangles, and is hardware culling sufficient—or do you need a full LOD implementation? Parallax occlusion mapping is pretty, but will you clamp depth values—noting that depth biasing complicates the per-pixel ray trace? Will you use virtual texturing to page texels asynchronously through a PBO like every modern game? Or will you be a cool person and use procedural noise to add displacement-mapped or normal-mapped detail? Will you have an HDR pipeline? Are you going to compress chroma values to try to cram luminance into eight bits per channel, or will you use a full 128-bit/texel texture or a compressed extension? Maybe modulate a luminance bias through the alpha mask?

Are you an expert in all of these things? I'm not. I know a lot about most of them, but that's the product of years of hard self-study. Not all of the above are necessary for making a great game, (or application or whatever), but you need to know which.

Be realistic. Blockbuster video games aren't made overnight—and even statistical anomalies like Minecraft took a veteran programmer of at least twenty years experience months of development in alpha and beta and the addition of a dedicated software development team before they achieved a final release.

Because I err toward constructive criticism, if you're new to programming and interested in making something, by all means try. You will learn a lot this way—in fact, it's the best way to learn. My suggestion, if you're new to game development—or even programming in general—is to try your hand at making a small game. The easiest language to use is Python, and I have basecode on the tutorials page to get you started. I recommend a basic 2D game—something classic, like a "Pong" clone. It's kindof a rite of passage. If you're feeling adventurous (and I highly recommend making a 2D game first), you can try 3D. Be warned, as the above paragraphs should have made clear, this is heavy wizardry you're getting into.

COMMENTS