I'm pretty new in developing videogames. By now I only used SDL with C/C++ to create games. I'm currently learning OpenGL and I realized that to be fluid and easy to maintain the code must be logically separated. Since I want to use OpenGLES on iOS and Android I was wondering how the engine must be imagined in a technical way, some questions came up:

  • Do I have to separate input/update functions from draw functions in different threads?
  • Is there only one proper way to think a game engine/loop?
  • What kind of assets should I use to create a 3D game using openGl ES to get better performance?

EDIT: I figured that I had more questions lacking of answers reading the links DMGregory refered me to. I'll keep reading it till I fully understand it and than ask for the good questions. Thanks a lot.

  • 1
    \$\begingroup\$ This is probably (at least) three different questions to ask. In games though, there's rarely if ever "only one proper way." Asking for a broad list of alternatives is generally considered off-topic. You may find you get better response by asking one question at a time, and framing it as "This is the strategy I'm using, and it has these particular drawbacks. What can I do to address this specific issue?" \$\endgroup\$ – DMGregory May 30 '14 at 21:58

With regard to engine design, Entity Component Systems are currently very popular. They're not the only way to think about game engines & loops by any means, but many developers have found them to be a useful standard.

The principle of composition over inheritance they emphasize tends to be well-suited to game development for a few reasons:

  1. Flexibility (Non-Brittleness): When the design changes at the 11th hour in response to playtest data, juggling a few components is often simpler than uprooting a whole inheritance hierarchy.

  2. Code Cleanliness: (With appropriate discipline...) component classes tend to be smaller, simpler, and have narrower focus & responsibilities than the sprawling Player classes of older games. They're a better fit for the amount of code a human can hold in their mind at a time, making it a bit less easy to create unintended side effects and hard-to-track-down bugs.

  3. Reuse & Remixing: Composition makes it easy to create new behaviours, by sticking together existing components like LEGO bricks. This is a huge help on larger teams where you have many non-coders who need to tune complex interactions - like a designer refining AI archetypes or an artist creating a new effects sequence. If they can chain together existing components to do it, it removes a dependency on programmer time, letting everyone get more done.

    This is also significant for games with procedually generated or user-generated content - it creates a useful level of granularity for these systems to work on. Level editing tools

  4. Performance: This isn't automatic, and it's certainly possible to code an ECS implementation with terrible performance. But if you make it a priority from the ground up, ECS can be made particularly amenable to multithreading and data locality for efficient cache usage, by encouraging smaller single-purpose update functions and standardized dependency patterns between components/systems (more on this in the links below).

These articles have been very influential to my thinking about ECS, particularly with regard to structuring for performance:

Component - Game Programming Patterns

Data Locality - Game Programming Patterns

Data Oriented Design - Game Developer Magazine September 2009 (p49 of PDF) and September 2010 (p33 of PDF)

These resources should give you some good ideas for ways you can create your own systems.

| improve this answer | |
  • 1
    \$\begingroup\$ Thanks a lot for you your answer! I began reading your links and it seems to be what I'm looking for. I'll keep reading it and then I'll edit this topic to be sure I don't miss anything. Thanks again. \$\endgroup\$ – Ganitzsh May 31 '14 at 5:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.