Hi all, I have been browsing gamedev.net for about a week or so, and have been amazed at the amount of information that is available in each of the sub-forums. I have read through a few guides, and do have a bit of C++ programming experience. (Less than one year.) But my question is, what now? This is pretty much my understanding of how to make a 3D game, although I know it is incorrect... Engine Graphics Gameplay As you can see it is a very skewed and basic viewpoint that I carry, but it is the only one I have learned. I have been looking for an in-depth guide, or at least a basic outline as to how to start me on my path to my first "good" game. Does anyone have any insight, links, or resources that describe the entire game design process? I am eager to learn, and am a bit of a perfectionist with quite a bit of time on my hands. So I hope that some people will set me on my way and I can go about it at my own pace, learning skills as I am required too. EDIT: About 5 seconds after posting this I found the Enguinity articles. While they do help with engine creation, they do not tell me the order in designing a game. [Edited by - Gallivan on March 3, 2006 9:28:29 PM]

That is a very vague outline. When you say graphics are you talking about graphics programming or creating models, textures and artwork?
Many would say that your graphics programming and gameplay are part of the engine.

Well that's the thing, I only have a very vague idea? What would really help is a fairly complicated (half a page) of in what order a company sets about making a game. What is implemented first and so on. I know each game will differ in some aspects, but there must be some fairly set direction they all take.

I would say that the game play should absolutly come first, because all other elements are built around facilitating that one aspect. The graphics, for example, are determined by the gameplay because what the player does determines what the player needs to see.

This could be analogous to the process used where I work (programming but not games) in which, early on, we define the user requirements. Incidently, our design process is as follows:

1) define problem domain:
This is where we do research to find about the problem that our clients are trying to solve. This has nothing to do with programming yet. This determines what the software should do, but not how. Similarly, you'd want to know what your game would do before you know how you are going to write it.

2) define user requirements
Here we think about how the user will interact with the software and how the use of the software fits in to the user's daily routine. Will a feature be useful or just add clutter to the screen? How can this feature be intuitive and prevent the user from making mistakes? Does the user want this feature or does it just make more work? Game play is very musch like this. It might be a good idea to a plan for the user interface/ how the player can interact with the game world/ how can the user navigate menus/ do what is necissary to play the game.

3) impact analysis:
We determine what resources/languages/libraries/depencies are required to produce the software and what software that we have written can be re-used/ adapted to contribute to the project. You might think about all of the features that your game requires and what your general plan is to attack those. Graphics is only one small part of a complex system, because you don't just look at the world, but you also interact with it.

4) implementation details:
Detailed description of the implementation. Usually a description of all procedures and data types that are required. For a game, this would be huge.

5) testing plan:
Now that you are finished, does the game work? Sure it works fine for you, but you know how you had in mind for people to use your software. What hsppens when other people use it? What happens when you do silly things that aren't part of the intended use? Basically you write a case analysis for all of your features: what should happen if the user does this or that? This is not only usefyl for testing your end product, but it helps you think about catching these cases before you even start writing code. also I find that writing the code takes 10% of implementation time and the other 90% is figuring out why the code I wrote doesn't work.

Then we start coding.

That anonymous poster was me. I guess my log-in expired in the past 15 minutes, or something.