In the past I have had projects that were using Irrlicht or Ogre as graphics engine. A graphics engine is there to manage the rendering. I am wandering what else needs to go into an engine to make the game engine label legit. Is it the fact that the game engine has a skillfully crafted bridge between the user input/gui and the game environment/graphics assets? that is if had to strip it down to minimum.

That's a philosophers question. In general a game engine offers everything you need to craft your game, that isn't gameplay code. In my opinion, throwing just libraries together is not what a game engine is made of, so thinking about it and spending at least some thoughts on software design should be made. For me, the bare minimum should be some platform abstraction, graphics and basic math. Asset handling depends on the type of asset you have, bitmap images and wavefront obj models don't need a library to load them because the file format is quiet easy.

That's why we decided to design our game engine from a collection of different modules so we can add whatever we need instead of spending the time to think about what to add and how ?

Basically I think, it's pieces of code that you would have redundantly in most of your games, it's purpose to help the game developer to avoid rewriting these code and focus on the final product. to have a game engine you need to have the basics, Render Engine as you said like Ogre, Audio Engine, Physics Engine, Resource Manager, GUI, Controller(to handle player's Inputs). each Engine / tool provide you with a unique way to process and handle your resources, but Engine alone is not a unique to any game. when you add your resources to it, it becomes a game.

fido9dido said:

Basically I think, it's pieces of code that you would have redundantly in most of your games, it's purpose to help the game developer to avoid rewriting these code and focus on the final product. to have a game engine you need to have the basics, Render Engine as you said like Ogre, Audio Engine, Physics Engine, Resource Manager, GUI, Controller(to handle player's Inputs). each Engine / tool provide you with a unique way to process and handle your resources, but Engine alone is not a unique to any game. when you add your resources to it, it becomes a game.

sounds like the standard prescription from the book.

I agree with Shaarigan, its a question of philosophy.

I define it as the following (and decades ago, we defined it like this)

1. The rendering engine: loads, manages and renders your geometry, loads and manages the textures, renders 2d texts and sprites, does all the opengl or d3d (or software rendering), api level interaction (keyboard, joystick and mouse input) and initialization, so it also manages the api level interaction. Its mostly about rendering, but not only rendering, as it has to initialize the interfaces to the os as well.

-The 3D (and/or 2D) engine manages the entire 3D scene, such as manages to animate your models (for example you can issue a command for a rocket to fly to x,y coordinates with V speed), measures your fps, manages your camera, allows you to make camera effects, particles, you can issue commands to it which makes. It implements physics and collision. Sound and music playback as well. The 3D engine includes the rendering engine.

-The game engine. The game engine includes the 3D engine. This implements the code for your game, such as this implements the ai and menus for your strategy game… or implements dialog system, map loader, battle system, etc for your RPG.

As you can see, this is being implemented in layers like an onion. The success of writing a software lies in the ability to translate all the problems into short and simple problems and programming tasks. (And this is one of the problems most of the modern programmer failing at).

@Calin

Here is a link with all the information you've requested.

https://en.wikipedia.org/wiki/Game_engine​

Seems like a pretty good site, I don't know why it's not more popular. smfh

well since we`re talking philosophy my take is that the render engine is that which does the rendering. As Geri pointed you can`t have visuals if you don`t establish a communication protocol/link to the OS so the communication protocol could be considered a part of the rendering engine. Input is a separate component, making the second piece of game engine I think. Everything else that remains, the `unseen/invisible stuff` that is, is AI (like if we take collision detection for example that`s AI because the computer `knows` if two units/characters are next to each other)

Calling it “a question of philosophy” is giving it far more credence than it deserves.