Jump to content
  • Advertisement
Sign in to follow this  
Deadlybones

How to separate my game engine and my game?

This topic is 2579 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

Hello there. I'm working on a 2D engine/game in C++/SFML(using VC++ 2010 express). I'd like to separate the reusable code(ie my "engine") from my game specific code but I'm not sure how. I want to be able to drop my engine part in other projects without picking through classes and files and copying/pasting each one. I saw a C# video where someone just dropped their engine project in to their solution(where the game project already was) and they could access everything after adding it to their references(not sure if references are an old visual studio feature or if they are specific to the XNA game library but I don't see that folder/tab in VC++). Anyways, what would be the best way to achieve something similar to this?

Share this post


Link to post
Share on other sites
Advertisement
Have all the parts of you engine in different classes. E.g. have you your render class, your input class, your physics class, your model class, your sound class, etc in classes that you can reuse. Game specific stuff goes in classes specific to the game you're making, and the main loop.

Share this post


Link to post
Share on other sites

Have all the parts of you engine in different classes. E.g. have you your render class, your input class, your physics class, your model class, your sound class, etc in classes that you can reuse. Game specific stuff goes in classes specific to the game you're making, and the main loop.


Yeah perhaps I was just overcomplicating things because of the video I saw. I think I'll be able to keep things organized enough.

Share this post


Link to post
Share on other sites
Seriously?
Don't.

Ok, I am not the right person to say this but really... unless there's the proven need, do not spend time in the engine. Write games, not engines. If the game is done, it's done. The only meaningful way to write an "engine" is to let it emerge from different needs - products - over multiple iterations.
If your game logic needs to be "separated" then 1. it's probably not an "engine" 2. there's some chance usability might be lower than expected.
Do not spend effort on "pulling out the engine" just to add a bullet point "engine is separated". It probably won't work for you.

If you want to make a game so that you can just pull in your engine with no work involved, odds are
A. Your "engine" is terribly complicated - BAD. You invested too much effort in the first place!
B. You could actually just swap the assets... and possibly even reuse the executable. No need to "pull it out".

(B) seems to be the norm for Flash and browser-based games.
(A) is what I was forced to do (to survive the ugly mess I've been stuck in). I'm still far from breaking even - and I can tell you I've been through several "designs" which didn't made it.

Moving everything into classes is only the tip of the iceberg. Those classes will have interface and semantics, those will bring you a legacy. Saying that to have an "engine" whatever your definition is, needs to have everything in "classes" is a gross oversimplification.

Share this post


Link to post
Share on other sites
I write my engine with C++ OPP, expose plain C functions from the engine dll, and write my game, my editor, my game logic and scrips calling these engine dll functions. Works for me.

Share this post


Link to post
Share on other sites

Seriously?
Don't.

Ok, I am not the right person to say this but really... unless there's the proven need, do not spend time in the engine. Write games, not engines. If the game is done, it's done. The only meaningful way to write an "engine" is to let it emerge from different needs - products - over multiple iterations.
If your game logic needs to be "separated" then 1. it's probably not an "engine" 2. there's some chance usability might be lower than expected.
Do not spend effort on "pulling out the engine" just to add a bullet point "engine is separated". It probably won't work for you.

If you want to make a game so that you can just pull in your engine with no work involved, odds are
A. Your "engine" is terribly complicated - BAD. You invested too much effort in the first place!
B. You could actually just swap the assets... and possibly even reuse the executable. No need to "pull it out".

(B) seems to be the norm for Flash and browser-based games.
(A) is what I was forced to do (to survive the ugly mess I've been stuck in). I'm still far from breaking even - and I can tell you I've been through several "designs" which didn't made it.

Moving everything into classes is only the tip of the iceberg. Those classes will have interface and semantics, those will bring you a legacy. Saying that to have an "engine" whatever your definition is, needs to have everything in "classes" is a gross oversimplification.


Hello, thanks for the feedback. I understand the games vs engines debate but like you said, everyone has a different idea of what an engine is. I'm not creating some arbitrary engine just so I can make games with it, rather I'm creating an engine specifically for this game. When I say "engine", I'm talking about the core mechanics of the game. The stuff I can reuse to create other games while making sure it doesn't all melt together. However, I have come to the conclusion that I'll just go with the flow and try and keep it as organized as possible. It shouldn't be too hard to disect the "engine" from the game after the whole thing is finished.


I write my engine with C++ OPP, expose plain C functions from the engine dll, and write my game, my editor, my game logic and scrips calling these engine dll functions. Works for me.


That sounds nice but I'm not exactly sure how to do that :) I think the best action to take is to do whatever I think works for me and see how that goes.

Share this post


Link to post
Share on other sites
[size=2]If you want a complete separation from your game and engine at the project level, why not put the engine into a static library? You could put both of them into the same solution file. Then when you are working on just the game part, you wouldn't have to rebuild the engine part (which can save some time depending on how large your project is). True, there really is no need to separate the game from the engine, but doing so gives you experience with making things more modular.

Share this post


Link to post
Share on other sites

If you want a complete separation from your game and engine at the project level, why not put the engine into a static library? You could put both of them into the same solution file. Then when you are working on just the game part, you wouldn't have to rebuild the engine part (which can save some time depending on how large your project is). True, there really is no need to separate the game from the engine, but doing so gives you experience with making things more modular.



Thanks, that sounds like what I was aiming to achieve. Could you expand on what you mean by "[size=2]put the engine into a static library"? I'm not really sure how to do this.

Share this post


Link to post
Share on other sites

[quote name='bluehailex' timestamp='1321125268' post='4883259']
If you want a complete separation from your game and engine at the project level, why not put the engine into a static library? You could put both of them into the same solution file. Then when you are working on just the game part, you wouldn't have to rebuild the engine part (which can save some time depending on how large your project is). True, there really is no need to separate the game from the engine, but doing so gives you experience with making things more modular.



Thanks, that sounds like what I was aiming to achieve. Could you expand on what you mean by "put the engine into a static library"? I'm not really sure how to do this.
[/quote]

The way you build a static library depends on your compiler. Do a Google search for buildings static libraries in c++ and you should be able to find what you need.


But to add to the original topic. If you want to make your "engine" easily separable from the rest of your code that needs to come down to the way you design your code. Make good use of encapsulation. That means that one class shouldn't have to know about the internal workings of another class to use it. Stay away from global variables.

In the end you will probably have to make adjustments to the engine every time you use it to create another game. You may need to add a feature that the engine doesn't support. That is okay. Make the point of your work to make a game, the reusable code that comes from making a game should just be a result of good program design.

Share this post


Link to post
Share on other sites
I'm a beginning C++ programmer myself, so I can't really help you out with all the technical aspects.
But at college, where I study, a group of teachers handed us there own game engine. As far as I can talk about it
all the engine parts are seperate classes. Like previous posters said. Then we have 1 file, the main game part,
with some functions in it (e.g. GameCycle, GameInitialzer, etc). All the student has to do is build a project, copy/paste
the files into the project folder, do a find-and-replace on 3 files (replace X with projectname) and write their own
gamecode.
I don't say it is the best way, and it is a good and safe way to handle memory (and also performance), but it is in fact
a great educational way of learning C++. I don't know how larger commercials engines work exactly, but as far as I know
they work with seperate classes, wherefrom a singleton is created in the main-class (e.g inputstatemanager, rendering manager, etc.)
So why not writing all the rendering code in a seperate class for example?

It is surely an interesting topic to talk about!!

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!