Basically the title sums up my question. Where do you draw the line between game and engine code. What would you classify what? cammera == engine, character control == game,but camera class == engine, etc...??? i know its really up to the coder.. but whats your suggestions?

The game is the actual content.

Ben

[Icarus Independent | Jump Down The Rabbithole | Tombstone: Vendetta ]

I know that the game is the actuall content. but what about boarderline functions? once that can be considered a game function or an engine function.. where is that line?

Engine functions should consist of rendering code, data loading (such as textures, models, and maps) Most physics code could be considered borderline IMO, but since most games attempt to simulate the same reality (eg gravity friction etc.) then physics could be built into the game engine. Camera movement code is somewhat borderline I think, but it''s possible to implement it in different ways. You could keep a pointer to a camera entity in the player entity, and update the camera and player position after physics/ai calculations are finished.
I think the simplest and most obvious way to classify a function as game or engine is : Game functions can call game functions AND engine functions, but engine functions should not call game functions. Anyway, this is all just my opinion and the way that I implement things, and it could be wrong for anyone else''s particular style.


Feel free to email me.

It probably depends on how much versatile you want your engine to be...

regards
Jindrich Kolman

My advice is not to bother with the distinction.
Make a 3D game and make sure that it has a nice tight game loop. After this is done, then you should seperate the two.
Its quite pointless developing an engine on its own... you''re sure to miss something. (Probably why id make games and then sell the engines)