How to separate my game engine and my game?
Author
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?
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.
Author
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.
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.
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.
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.
Author
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.
[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.
Author
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.
[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.
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!!
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!!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
