4 edited tags
| link
3 edited tags
| link
    Post Closed as "primarily opinion-based" by MichaelHouse
2 added 466 characters in body
source | link

I'm on the planning stages for an internal game engine I am about to start creating, which will be used for all my games going forward. But I'm struggling a bit with how it should be built.

The choices come down to: framework or library.

My basic objective is to hide engine details as much as possible to keep high level game development on scripts and config files as much as possible. But also to reuse the core engine for any tools we might develop in the future.

Frameworks can make things nice and easy for development, but then you're locked in. Libraries are good if you're only interested in a specific subsystem. But we need to glue everything together in a game by game basis.

Well there is also another, building the engine as a standalone exe that handles all game resources, and all the subsystems. Game logic (and other per game dynamic stuff) is done exclusively on scripts with config files to configure each internal engine subsystem.

Which one will give me more flexibility in the future.

Thanks.

Edit: Thanks everybody, guess I was looking at this in the wrong perspective. We can't really plan something like this without a priori knowledge of what the games need, guess this is why there is no such thing as a general engine for all genres.

I'll focus first on the game proper then iteratively analyze at the end of each game how to make decent abstractions for libraries or frameworks depending on my work-flow (or possibly that of a future team).

I'm on the planning stages for an internal game engine I am about to start creating, which will be used for all my games going forward. But I'm struggling a bit with how it should be built.

The choices come down to: framework or library.

My basic objective is to hide engine details as much as possible to keep high level game development on scripts and config files as much as possible. But also to reuse the core engine for any tools we might develop in the future.

Frameworks can make things nice and easy for development, but then you're locked in. Libraries are good if you're only interested in a specific subsystem. But we need to glue everything together in a game by game basis.

Well there is also another, building the engine as a standalone exe that handles all game resources, and all the subsystems. Game logic (and other per game dynamic stuff) is done exclusively on scripts with config files to configure each internal engine subsystem.

Which one will give me more flexibility in the future.

Thanks.

I'm on the planning stages for an internal game engine I am about to start creating, which will be used for all my games going forward. But I'm struggling a bit with how it should be built.

The choices come down to: framework or library.

My basic objective is to hide engine details as much as possible to keep high level game development on scripts and config files as much as possible. But also to reuse the core engine for any tools we might develop in the future.

Frameworks can make things nice and easy for development, but then you're locked in. Libraries are good if you're only interested in a specific subsystem. But we need to glue everything together in a game by game basis.

Well there is also another, building the engine as a standalone exe that handles all game resources, and all the subsystems. Game logic (and other per game dynamic stuff) is done exclusively on scripts with config files to configure each internal engine subsystem.

Which one will give me more flexibility in the future.

Thanks.

Edit: Thanks everybody, guess I was looking at this in the wrong perspective. We can't really plan something like this without a priori knowledge of what the games need, guess this is why there is no such thing as a general engine for all genres.

I'll focus first on the game proper then iteratively analyze at the end of each game how to make decent abstractions for libraries or frameworks depending on my work-flow (or possibly that of a future team).

1
source | link