Home/ Questions/Q 6000553
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T00:42:36+00:00

I’m working on a lil’ game engine in C++, and decided to do it

  • 0

I’m working on a lil’ game engine in C++, and decided to do it all OOPily (heavy use of classes.)
It’s intended to be (theoretically) cross-platform, so I have an ‘Engine’ class, an instance of which is created by the ‘OS Module’, which is WinMain for Windows (the platform I’m developing it for first.)

I have three main questions:

  1. Is it considered poor practice to create a class that is only going to be instantiated once in the entire application? Perhaps because there is some kind of performance hit or added overhead incurred by using a class rather than a bunch of functions?

  2. I’ve been planning to have WinMain create the instance of Engine as a local variable. The Engine class will be fairly large, containing classes for rendering, script parsing, file system stuff, etc. Basically, the whole game engine, apart from OS specific code, will be contained in the Engine class in some form (possibly as an instance of another class.) Is creating a local instance of my very large Engine class within the WinMain function a bad idea? Is creating a local instance a bad idea when the class will be created when the program starts, and end when the program ends? Maybe new would be better?

  3. My plan (i/wa)s to divide the engine up into ‘modules’, each of which is represented by a class. The Engine class would contain an instance of almost all the other modules, like, as mentioned above, rendering, file system interaction, etc. Is using classes as containers for huge modules a bad idea from some perspective (performance, design, readability?)

Thanks for any help 🙂

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Game engines are not prime candidates for cross-platform’ness since they usually involve efficient interaction with low-level API’s (which are not cross-platofrm).

    The size of a class depends on the member variables it contains, not the number of functions it implements.

    Stack space is usually small (http://msdn.microsoft.com/en-us/library/ms686774%28v=vs.85%29.aspx) while the heap is theoretically as big as available RAM. So, if you have something really big, store it on the heap (with new).

    The “Splash Screen”: don’t do all the work at the beginning of the program. Users hate it when they run the program and nothing shows on screen because your program is busy initializing something…
    Lookup lazy instantiation, basically don’t do things that can wait and always show something on screen.

    As for specific answers:
    1. No, assuming no virtual functions, there should be no performance overhead.
    2. See “Splash Screen” and “limited stack space” above.
    3. Modularity is generally good, just make sure each class does/represent a single “thing”. But don’t have so many classes you start forgetting their names and purpose 🙂

    • 0