2
\$\begingroup\$

I've seen that the Quake 3 Engines uses QVMs and DLLs for the gamelogic. Unity uses some kind of Component-Entity system.

My question is basicly: What's a good way to keep the engine seperated from the game logic itself, without having such things as "QVMs" or Component Systems.

The problem is, all my current approaches on creating an "seperation" of the logic leads me in having kinda unflexible code or code that has to deal more with the engine than the logic itself.

I know this can be seen as too broad, but this problem is bothering me for a week yet and I can't seem to find a way to fix this.

EDIT, see first comment: To be honest I tried only 3 approaches.

My approache number one was for example to programm an "App Class" creating and handling events:

class DXApp
{
private:
  HWND ... // All that windows stuff
public:
  virtual void Render();
  virtual void Update( float fTime );
};

On top of that I created little abstraction layers ( abstract Buffers then Model classes based on them ) which ended in the code dealing more with the engine than the logic itself. E.g. I am asking the window for User Input, which makes use the explicit object(-methods ).

My second approach was to create an GameState based logic with ManagerClasses which are calling my methods. This made my game logic yet again pretty dependent of the engine.

My third approach however, was to use an scripting engine. This made my end up in mapping many classes to Python classes ( the engine was calling the scripts! ). The code wasn't clean at all. On top of that, the more function calls I used the slower the game worked. But the code was rather independent and had not to deal with any engine specific tasks.

I think this problem is more of a architectural matter.

I hope I could explain good what bothered me, if not please post below in the comments.

\$\endgroup\$

closed as too broad by Josh Aug 1 '14 at 15:18

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.

  • 2
    \$\begingroup\$ I think this is indeed a weak question currently. Perhaps sharing how all your current approaches have failed exactly, with code examples, would help. What kind of game logic do you want? What kind of engine? What do you want o separate and why? I think the topic is interesting but can't get a grip of it with the vague question. \$\endgroup\$ – antont May 10 '14 at 22:32
  • 2
    \$\begingroup\$ If you can also explain why you throw out existing, successful engine design approaches that would be good. In any case, of course your game stuff is dependent on the engine because it runs IN the engine. The point to an engine is that it takes care of the details and lets you use higher level meanings. Example: your game should not load object + load material + setup object and material, it should be asking the engine to "prepare this object called 'turret' for me, thanks." Try thinking of your engine as an OS that provides services and not a systems wrapper. \$\endgroup\$ – Patrick Hughes May 11 '14 at 16:55
  • \$\begingroup\$ the game engine is a set of functions that are set in stone so many different game editing code runs on it. unity can use dll's for extra connectivity into the unity editor and games, and it just has scene files that can save gameObjects controlled by codes. the game engine itself has configuration functions to access hardware and basic game objects i.e. backgrounds/cameras... \$\endgroup\$ – com.prehensible Oct 22 '14 at 21:32