Game & Engine - Where do you draw the line?

[ajtgarber]

About 6 months ago I finished a simple game engine, and came back to it to use it for a game and found it was too
lacking in its features (and quite buggy). Today I've decided to rewrite the engine and plan it out more thoroughly
before I code it, and I got started thinking about where you draw the line between the Game and the Game Engine
and I want to get some other developers opinions on it before I get started. The engine is going to be coded in Java
and I want to get Lua into it if I can.

Right now I've got a guess on where the line could be
Engine:
Image Allocation
Velocity Management
Collision Management
Rendering (Well in Java this isn't as much of a problem)
Input
FPS

Game:
Game Logic
Collision Logic
NPC Logic

[rolland]

Looks good so far. Sorry, but it kind of eludes me too, so I can't be of more help.

[K-Bal]

Start with the game and code the engine as you encounter your needs.

[hurstshifter]

Start with the game and code the engine as you encounter your needs.

I definitely agree with this. Once you have an idea of everything you want your game to do, you will know what features the engine will need to have. I am sure you will find here and there that you need to add additional functionality to it as well.

[XianForce]

Well a game engine should be for a specific 'genre' of game, like maybe a platform game.

The line should be drawn where things start getting 'game specific'. You should have methods/functions that check for collisions, and then have the user of the engine define what should happen with a collision.

So if you look at the engine itself, and you see something that's specific only to your game, then you've probably crossed the line...


That's just my opinion though.

[ismetteren]

Well a game engine should be for a specific 'genre' of game, like maybe a platform game.

What do you call engines that isent genere specifik then? I dont think an engine has to be genere specifik, but i agree with the rest of what you said

[davidthefat]

I always thought engines were highly modifiable programs with no story... Like a physics engine that can be implanted pretty easily

[eatcomics]

Yeah engines are portable code that can be used for many applications...

I would say as long as you could make multiple games, be it different genre or just different story, that it would be considered an engine.

and as a side note engines don't have to be genre specific at all, most of the industry standard ones used to make games these days are very versatile, they make FPS, puzzle, raceing, they can do pretty much anything.

Now if you planned on making it very versatile for making future games just think out the basics of those games (collision, image rendering, AI (although this could be game specific), text rendering, gui rendering, and so on.

But anyway good luck on your game and engine, and while I don't think that you have to start figuring your game out first, I'm pretty sure it would be the best to do that for what you want.

[wtetzner]

You don't have to have a monolithic engine that your game sits on either. You can have multiple, more specific engines that you can sort of "plug" together: graphics engine, input engine, physics engine, sound engine, collision engine, etc. Then, you can put these together however you want to create an engine specific to your game. And you can combine smaller modules to make larger ones. That way, your collision engine, for example, wouldn't really be tied to the game or the engine, it would be it's own module.

So, by having modules that you can combine to make larger ones, eventually composing them to create a game, you don't really have a "line" between the engine and the game. It's more of a gradient. When you make another game, you can select which components you want to use, with whatever level of granularity you want to use.

Anyway, that's my take on it.

Of course, designing components that will be easy to compose isn't trivial, either. Then you have the problem of where to draw the lines between components.

[Falco Girgis]

Start with the game and code the engine as you encounter your needs.

I definitely agree with this. Once you have an idea of everything you want your game to do, you will know what features the engine will need to have. I am sure you will find here and there that you need to add additional functionality to it as well.

Ditto. That was also the design philosophy behind the ES engine.

[Bludklok]

My philosophy thus far for my video game development process is...

Step 1. Game Concept - Open up a notepad and record whatever ideas pop into my head that way I have a good idea of what i'll need for the project.

Step 2. Resource Gathering - I start designing pixel art and collecting other needed resources. The reason for this is so I can throw all of the art and sound into the level editor as a placeholder and decide later on what kind of 'setting' I want the game to have then I adjust the content accordingly.

Step 3. Level Editor - Since the main 'design' of each of my level editors are primarily the same I still like to design a brand new editor for each engine so I can learn from my past mistakes on level editors and try to avoid them.

Step 4. Engine - Build the engine. <.<

________________

I've found this to be the easiest and most productive way of developing an engine/editor from scratch (for me at least).