Quick Initialization Question

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Quick Initialization Question

      Hi,

      At the moment I have my game logic loading the static terrain and world information, and my player view doing the same in it's constructor. I want to try and make it a little more generic, as the paths are hardcoded right now. I am thinking to add either an 'InitializeWorld' or 'InitializeViews' event that will carry the game data path and the filename of the xml file containing the static world information. I already have a 'GameInitialized' event which is used to build the quadtree etc. once all initialization is complete.

      Do you think adding an event to intialize the world is overkill, or should I just really pass this path information into the views constructor? Would you consider this kind of information to be an initialization of the views, or of the world? Techically I could still leave the code that creates the renderer etc. in the player view constructor, or I could move it into the initialize event. That would somewhat seperate the two. Not sure if that's a good thing or not.

      Thanks for any advice.
      Regards
      Ray

      The post was edited 2 times, last by Raeldor ().

    • First off, you shouldn't be doing anything in the constructor except setting member variables and similar house-keeping routines. You shouldn't do anything that can possibly fail since you can't return anything from constructors.

      I think an initialization event is a good idea. It adds a bit of flexibility to your game, especially if you have a few of these events. That would allow you to reinitialize parts of your game as well.

      In Rat Race (and Barbie) we don't use an event, but we do have a multi-stage initialization. Our WinMain basically looks like this:

      Source Code

      1. int PASCAL WinMain( HINSTANCE instance, HINSTANCE /* prevInstance */, LPSTR cmdLine, int cmdShow)
      2. {
      3. gAppInstance = instance;
      4. Pause();
      6. if(!PreInit()) // anything the gfx engine might want to do before we touch anything
      7. {
      8. assert(false);
      9. return 0; // failure
      10. }
      12. if(GamePreInit(cmdLine)) // initializations that happen before asset loading, etc,
      13. {
      14. if(GameInit(cmdShow)) // asset loading, plugin registration, etc. During the loading title screen.
      15. PumpMessages(); // play the game
      16. }
      18. GameCleanup();
      19. return 0;
      20. }
      Display All


      This isn't a copy & paste, but it's pretty close. I only stripped out some namespace stuff.

      As you can see, we actually have 3 levels of initialization. PreInit() is for the graphics engine in case it wants to do something before we load any resources (some graphics engines do, some don't). All we do is make engine calls here. The GamePreInit() function is where we do everything we need to do before loading assets. This includes setting up the Lua window, loading custom settings, setting up asset paths, loading the loading screen, etc. Finally, GameInit() is where all the real asset loading happens. All models, textures, sounds, World data, subsystems, etc are loaded here. We use a "load everything needed for this episode/level and pray the user has enough memory" method, but out worlds are pretty small so it works well. I'm not sure if that's appropriate for what you're working on.

      Anyway, hope that helps.

      -Rez

    • That helps a lot, thank you. I was worried about doing too much initialization in the constructor too, but it seems a lot of sample code does this so I think I have picked up some bad habits. I'll remedy this and thanks again for the confirmation that the multi-stage init is not overkil.

      Regards