Hi there,

I recently started writing a small game engine, mainly for educational purpose not intending to sell it, but i do intend to use it (hopefully). I have got to a point where it has enough features to make a basic game, but i can't really think of any way to make a game with it without tying game-specific code to the engine.

I would like to have 3 projects setup like this:

· Engine [Lib/DLL]

· Game [EXE]

· Editor [EXE]

Im not quite sure how to achieve this or if this is even the correct approach. I'm also not entirely sure, lets say this is the correct approach, whether or not i compile the engine into a static library or a dynamic library. I have read a little about static libraries vs DLLs but i'm still not sure which one would actually better as they both have their disadvantages.

The game world in this engine is composed of actors(Game Objects) which can have components attached to them, just like unity and UE4 (more so like UE4) and i would like to be able to easily define actor and component types in the game project.

Also please note i am hoping to make this cross-platform (the editor side of things at least, so i can edit the game on linux).

I would like to have 3 projects setup like this:

Do what works for you, If you find a reson do have a DLL "engine" do a dll engine. If you need an externel editor write an editor, that it basically.

If you have 2 choices where you struggle to weight the pros and cons, we will be happy give you our opinion

I know the common saying is to make games not a game engine, but there are some things that you may not learn by simply making games and i would like to learn about those things, which is why i would prefer to make a game engine.

I would like to have 3 projects setup like this:

Why? What are your goals in choosing this particular approach?

To have an engine that i can use to make basic games in and use as a test platform for learning new things (more specifically, low level aspects). It also means i can easily modify the engine while working on games.

Do what works for you, If you find a reson do have a DLL "engine" do a dll engine. If you need an externel editor write an editor, that it basically.

If you have 2 choices where you struggle to weight the pros and cons, we will be happy give you our opinion

I'm not sure which one will work better though. Ideally, i would like people who have had past experience with this to comment on their experience and possibly what mistakes they made and why they think their way is better.

I know the common saying is to make games not a game engine, but there are some things that you may not learn by simply making games and i would like to learn about those things, which is why i would prefer to make a game engine.

That advice also means that if you make a game from scratch, you will automatically end up with an engine by the end, but if you make an engine in isolation, it will be a jack of all games and master of none.


As for DLLs vs static libs, use static by default and DLL when forced to. DLLs are a lot more complex and only give a few benefits - dynamic loading (and potentially reloading) ability to be replaced without recompiling the game (assuming the DLL was written in C, not C++...).

Having "engine" (shared, reusable) code in a library, shared by multiple EXEs is a fairly common approach.

So do you think, given what i said before, that it would still be more beneficial for me to try and create some specific games first?

Also if I were to start out compiling to a static lib and then find out down the line that I need to compile to DLL I would need to make quite a few code changes wouldn't I? also if iI wanted to have c# as the primary scripting language I would have to compile to a DLL wouldn't I?

Make a list of logical operations that your engine would have to perform to create a game. Anything that is not related can be its own reusable library. Rendering and physics are the two easiest examples of libraries that should be decoupled, creating a reusable framework on which to build future titles.

I know the common saying is to make games not a game engine, but there are some things that you may not learn by simply making games and i would like to learn about those things, which is why i would prefer to make a game engine.

If you don't use a game engine (that is, make a game from scratch) you implicitly have to implement a game engine as well. Depending on where you put the focus, you could "make a game" (where the engine is a sort-of by-product), a "game+engine" (try to consciously split specific game code from general code), an "engine+game" (where the game is a sort-of by-product), to "game-engine" (no game at all).

The more you shift focus to the engine, the more precise you need to know what it should provide. Do you have an understanding of what exactly the engine should do, ie what is its API?

If you know this exactly, you can at least in theory, build the engine. If you don't exactly know, maybe it's better to use a game as use case, and co-develop it.

To have an engine that i can use to make basic games in and use as a test platform for learning new things (more specifically, low level aspects). It also means i can easily modify the engine while working on games.

If you have a common engine for a set of games, and you change the engine, all games die, and you have to fix all games for the changes that you make in the engine. In other words, the engine connects all games to each other, and you have to drag everything along with each change.

The alternative is to not share the engine between games, and just make a copy of the engine when you start a new game. It's a valid solution, depending on how bad you think it is to have some games use an older version of the engine.

To have an engine that i can use to make basic games in and use as a test platform for learning new things (more specifically, low level aspects). It also means i can easily modify the engine while working on games.