Jump to content
  • Advertisement
Sign in to follow this  
KieranChandler

Unity Game Engine Modules/Projects

This topic is 891 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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).

Share this post


Link to post
Share on other sites
Advertisement
I would like to have 3 projects setup like this:

 

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

Share this post


Link to post
Share on other sites

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 smile.png

Edited by imoogiBG

Share this post


Link to post
Share on other sites

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 smile.png

 

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.
What "some things" do you mean here?

 

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.
Euhm, not really.

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.

Share this post


Link to post
Share on other sites
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.

 

 
This does not really have much to do with your stated organization of DLL/EXE/EXE though. Which means you're likely overcomplicating your approach for no reason. You have not stated a compelling reason why your project needs to use that approach, so you shouldn't (since it is a more complicated approach).
 
A static library will be significantly simpler to start out with, and can be easily adapted to a DLL if needed later. However starting out with a DLL, unless you're familiar enough with their production (and I don't think you are since you had to ask the question in the first place) will introduce a lot of boilerplate code, such as the necessity to expose a C-style ABI for your engine and do the appropriate marshaling and/or data hiding that gets in the way of accomplishing your actual goal of making something.

Share this post


Link to post
Share on other sites

Strictly speaking you can also live dangerously and take the approach that the engine DLL and the game simply need to be compiled with the same C++ compiler, and therefore allow working through C++ ABI directly instead of making a proper C API (C4 engine, and some graphics libraries like Ogre work this way.)

 

But I agree that dynamic libraries are a complication and the OP likely doesn't need them right now.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!