0
\$\begingroup\$

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.

\$\endgroup\$

closed as too broad by Josh May 30 '14 at 22:52

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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
0
\$\begingroup\$

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.

\$\endgroup\$
  • 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.