   Game Code Structure?
  This is something i've been meaning to learn about. Does anyone know the "standard structure" for a game. Like when your programming the game, do you start with basic math/movement functions or do you only add the ones you need for what your working on that moment?just would like to see/hear from someone about game code structure and pretty much how to put your programming knowledge into making a customizable/modifiable game.   
Quote:Does anyone know the "standard structure" for a game.There really isn't any, beyond the very high level concept that the game has a main loop that looks like: (1) gather input, (2) update logic, (3) render.Quote:Like when your programming the game, do you start with basic math/movement functions or do you only add the ones you need for what your working on that moment?That depends on what you're starting with. Generally you should not write code until you have an actual need for it, though (YAGNI).Quote:just would like to see/hear from someone about game code structure and pretty much how to put your programming knowledge into making a customizable/modifiable game.Practice. How many games have you actually tried to make so far?   ;Quote:Does anyone know the "standard structure" for a gameThere isn't one. It's frustrating to be told this, but it's the truth. There are patterns, but not really a structure or a particular hard sequence. You simply resolve dependencies and then build up the game iteratively.Quote:Like when your programming the game, do you start with basic math/movement functions or do you only add the ones you need for what your working on that moment?I resolve testing and debugging issues early on. Everything else relies upon being able to debug, trace, and test, for obvious reasons. How I do so depends on the game and the environment it is being run in. So a good portion of the initial work is getting this infrastructure correct. I deal with debugging first not because I have a notion of it being "a base component" but because I can see that it's a critical dependency. Everything depends on being able to debug properly. Don't treat what I said as a hard rule, though.You get a sense of how to approach long term projects through experience. Not hard rules, which only make sense when you're making the same thing over and over and over. And you're not. Each game is different (like any other piece of software).   ;  Thanks guys, i've made one complete project called "Galaxy Pong" a simple 2d/3d pong game. (using Dark Basic Pro) and i've begun porting a FPS i have in the works (everything but AI implemented nearly) to C++/Ogre. And as i guess my question comes down to:Should i build an engine and a scripting system to go with it so that when i make content i don't have to rebuild each time?I'm just curious on how i will need to adjust when i get a job as a programmer in the future.   ;Quote:Original post by cmkanimationsShould i build an engine and a scripting system to go with it so that when i make content i don't have to rebuild each time?I'm just curious on how i will need to adjust when i get a job as a programmer in the future.Don't know whether I am eligible to write here, as the number of my finished games haven't yet reached a integer number. However I recently got quite a productivity boost by not worrying too much of the future ("... and later when I want to do X it will be so much easier...) and try progress towards the functionality I need now.Adding scripting is surely very nice and also a good reference, however you can improve build times also by using forward declarations and trying not to have too many #include dependancies. You might also be able to improve build times by putting the logic into a separate dynamic library against which you link. Then you would only have to build that and not the whole game. Later on (when you really need it) you can then add scripting to that logic library.;Quote:Original post by cmkanimationsShould i build an engine and a scripting system to go with it so that when i make content i don't have to rebuild each time?You can also start with a high-level language immediately - and should the need arise, replace the slowest parts with native libraries. Python lends itself well for this.Either way, a data-driven approach is a good idea for a content-heavy game, scripting or no scripting.   