There's a different way to make games.
Much of the complexity of game development has less to do with the game itself, and more to do with the environment in which its created.
And much of that complexity is unnecessary for the small team or solo developer.
So i should probably start by saying that this "different way" won't work in many (most?) situations.
But when it can be used, there's little reason not to (at least that i've found so far).
So, when is it applicable?
1. when you have complete access to and control over the code.
2. when you can rely on discipline as opposed to hand holding to prevent problems.
3. when you're developing a single title as opposed to an engine, library, or purpose built reusable component.
These right there probably sum up how the development environment complicates the process.
1. when you don't have code access and control, you have to make editors and engines for the non-coders. you also have to design your code so any numbo coder on the team can use it and not blow up the game.
2. when you don't have disciplined coders, you have to do a lot of hand holding work in the form of designing "developer proof" code. Much time is spent on making it so other coders can't misuse code.
3. much work and consideration goes into design for re-use. however, not all code is reusable. not all code gets reused. its "anticipatory coding" - trying to anticipate possible future needs and designing the code to handle that eventuality. all fine and good, but in some respects, that's somewhat akin to "pre-optimizing".
So, from this list, you can see that these circumstances don't apply in all cases. If you work for a big studio, and have to deal with non-coders and numbno coders, you're done reading. This journal is not for you. But if you ever do an independent project after hours, you might find it interesting. If you're looking to break into the commercial game development industry where there are non-coders and bad coders this is not for you. but if your just looking to build a game without all the usual federcarb, this is for you.
i'll be concentrating on C++ windows directx development, but as always, most general concepts are hardware, OS, and graphics library independent.