Regardless of background, there's just so many factors that stand in the way of budding game developers. It's actually rather surprising how many are produced at all. While the quality varies, even the most mundane games takes a level of commitment to complete. Which is probably one of the biggest factors. Developing games for a passion is one thing, but out of obligation is something entirely different.
Ignoring media / skill (experience), developers need to sort out their tool set early on (language/mapping/animation/collision/lighting/Physics/AI etc etc ). Identifying the base potential is important. So we need to find what's strength and weaknesses these tools have ? This is important for the design process, so conceptually we can design projects that fit the tool set from day one. There's no point trying to force a square peg into a round hole. No matter how much fun that is
The temptation is to run off now and start building your final vision. Some people can do this really well, not me however. I find that once the tools are sorted, it's important to flesh out your game layer. Regardless of the language you're using, you can be assured it won't work entirely how you want it to. So by building some base function sets, we can abstract our game code from the language underneath. The idea is that these layer(s) of code are generic enough that we use them project to project. Think of them as a quick start frame work that connects all the components together. Over time this frame work will evolve as our ideas/skills evolve.
Ok so that probably sounds like a lot of work to just get to stage one, but the idea is that we can save ourselves time and effort by streamlining the process before we rush out and start our next behemoth. Once we're happy, then start prototyping our base ideas using our kit. Initially this is where a lot of hiccups are discovered, these might be things with the tools, your game layer, or just unforeseen complications. Whatever the issue, it's up to you to choose the path forward. Be it solve them or just accept them as limitations and move on with your design. Of the course the latter might indeed rule out some features of your game. It's always going to be compromise.. We can't do everything !
Once you've built a working prototype to show your design works. Then we can start seriously looking at the building the game itself. As the programmer, It's so tempting to hardcode all the functionality into the actual game engine (maps/layout of characters/specials/high sores/ etc ect). This is a
huge mistake (since this makes the programmer the keyman!), Rather we want to build the game so that it can play whatever level we want it too. So while the programmer's) will most likely build in custom code control enemies behavior for example through the game world. The layout and world space should be done externally. Sometimes this is achievable from generic tools, but you'll often need to build a simple (no frills, but functional) tool to drop characters/set times/bonsus etc etc into worlds/levels. This way anybody in the group (or externally) can contribute to the content creation process.
Imagine your building an Arkanoid clone with 100 levels say. Sure you could use data statements and layout them out internally in the code. But no matter how much you love your game, this is going to get old real fast ! Hence, if we make a simple external editor, we can share this work across the group. Not only that it opens up the door way for to build expansions at some latter date.
The point of this ramble is just to re-iterate the importance of design. The bigger the project, the more important it becomes.
This is massive subject, so here's some
More Tidbits
