   The process of creating a game?
  Well, I've been programming various games for several years, but I always had a feeling I was doing the whole process wrong, even though I improved at each game I started.A Google search only brought me results of the process of general game design, what I'm actually looking to know is what the programming process is, when you start a new game.I'm sorry I'm a little hard to understand, I just don't quite know how to define my question, I guess what I'm actually asking, when you start a new project as a programmer, what do you do first? What functions do you make first? Which part of the game do you even start with? Visible mechanics? Behind the scenes mechanics?I really would like some feedback from other programmers on their personal beliefs on new projects.   
  I think this is what you are looking for. Tons of stuff to read about the software development process.It's not specific to game programming, but in this sense a game is just another piece of software. The same rules apply on the large scale.I myself am using a sort of blend between iterative and test-driven development. I like the freedom and robustness TDD brings when you get the hang of it. And I also like the idea from the iterative process to rapidly come back to prototypes that can be evaluated against some set of requirements.If you are a single developer I think it depends a lot on what kind of person you are. Some people like to plan out the whole structure before they begin to type the code. Others just like to wing it, make it up as they go along and go back to restructure once a clearer picture has appeared.   ;  I usually start with a basic render: I need to see what I'm doing.Here's a log I started when I made a minesweeper clone. But I quit doing the devlog unfortunately.Day 1, 2010.02.13:setting up windowhex field rendering (not optimized, immediate mode)making initial textureview controlling: pan, zoomDay 2:basic element selectioninitializing random fieldrevealing element (calculating bombs around it)handling edges of the mapzero-field automatic reveal with recursionfixed rendering (still not optimized)implemented all the controlling features in the field, that the original version hasgame overDay 3:Game loop: only redraw when event (re-factored main loop)view controlling finished: restricting, setcapturerecursion rewrittenfading at window edgeswin gameOkay, this post is quite meaningless.   ;  When making games on a LARGER scale, the thing you want to start with is the engine. This is the core of your games and if YOU built it, you know how it works and it does so because you want it to and you can always modify it for improvements and additions. It must be as universal as can be. Creating engines for each game is a stretched process because you can just have one central one that handles all the necessary processes and focus on the actually Game part of the programming (even though I guess the whole thing is "the game" part of it).A general engine consists of:- Collision Detection- Artificial Intelligence of some sort (this one might force you to make one for separate genres of games so you might want to consider what you do with this)- Graphics handling- Sound handling..- things of the likeFrom that point, you get to the point of creating the story and contents of your game. Programming them in is a lot easier than all the low level stuff and since all (well, most) of that is done in the engine you can focus on it a bit more ;] I've always stumbled on collision detection D: I'm still trying to get a functional system ^.^ I'll get there eventually.Have fun[Edited by - boogyman19946 on May 21, 2010 6:53:47 AM];  Actually. Doing the engine first is a good idea. That way you can fit design to the engine functionality, instead of constantly having to hack the engine to fit the design :)Ofcourse, you need a general idea of what you want the engine to be capable of :)   ;  It really depends on the game. Usually I start with what I think is the most important aspect of the game, and start working on that, and then build out from there. So for example, when I was working on a game that was similar to Bejeweled, the first thing I did was make a grid of gemstones and have them respond to being clicked on. Now I'm working on a game with procedural map generation, so the first thing I did was work on the map creation code. Neither of these started out remotely interactive -- you'd start up the program, it'd pop up a window, show you what it'd done, and then you'd go to the terminal and hit control-C to stop them. Really bare-bones stuff, but it gets me started, and helps me see if conceptually I'm on the right track.I feel that if I started with the engine and user input and all that boring-but-essential stuff, then I'd rapidly lose interest because I wouldn't be working on the actual game. When you're your own development team, maintaining interest in what you're doing is crucial.   ;Quote:Original post by ozakActually. Doing the engine first is a good idea. That way you can fit design to the engine functionality, instead of constantly having to hack the engine to fit the design :)In practice it is exactly the opposite - you need to develop the game in order to determine the features that the engine needs to support. Most successful engines are developed by writing a game, or two, and then spinning off the common features into an 'engine'.   ;Quote:Original post by swiftcoderQuote:Original post by ozakActually. Doing the engine first is a good idea. That way you can fit design to the engine functionality, instead of constantly having to hack the engine to fit the design :)In practice it is exactly the opposite - you need to develop the game in order to determine the features that the engine needs to support. Most successful engines are developed by writing a game, or two, and then spinning off the common features into an 'engine'.Agrees.The reason for this is building an engine is a mammoth task and it is sometimes unclear on what is actually needed to build 'x' game for beginners. By building a few games (well) you should find that you have constructed reusable pieces of software that you can take out and use in another project, if you do this enough you will gain a substantial code base of which to build your game engine with (at times refactoring is neccessary, to seperate the game specific stuff from the engine stuff).Though I will say 'trying' to build a game engine is a LOT of fun most of time and for me personally it is better than building an actual game (which is why I want to go into engine and tools development). So if your not to worried about getting a game done, have some fun and give it a go. ;)   ;  This is what I did.I created a tetris game, I didn't use anything remotely close to an engine (just barebone API) and after I finished the game completely I reviewed my code and I could easly see what things could've easly been made easier. (I used Direct2D for that one, and well, if you want to make a different size of text, you will have to create different interfaces and stuff, and also store and recreate those things.When a game uses five different text sizes, it already starts to annoy you.So I started by first creating a class that initializes stuff, then I did some resource management, and with that, I started creating something else.What I want to say is, creating a COMPLETE engine in one try isn't going to work (well, there probably are a few exceptions) so you'll need to do stuff, make mistakes and learn from them. With that, you can make a nice codebase with which you can later use to make the next game easier.Well, I recently gave 3D a try, so now most of my codebase (which was direct2d specific) can't be used :PExcept my timer class ofcource :D Hope this helps a little :)Tigran   ;  The short answer is, there is no right way. :)There is Top-Down where you start with the higher level user interface and work your way down to the machine level interfaces.  There is bottom up which goes the other direction and there is doing both or neither.What you need to determine is consider your whole game project itself and think about what components you will need. Then start will the well-defined and more critical components.  As mentioned before a Game Engine is a critical component, but early in your design stages it isn't well defined.  But then maybe you can break the Game Engine up to sub-components, some of which may be well defined at the beginning, like surface rendering.Or start with the user interface and see how you will want to support it.Best to start with parts you suspect won't change much as you go forward.  (They may but that is another topic)Software development in general is a bit of an art form.   