Being developer's when a game engine doesn't have a function that we require, we build our own - such as returning certain things we may require,
However game engines tend to be updated regularly and when we move to a new version of that engine we lose the functions that we have built and incorporated into that engine.
I was just wondering how people managed to move from the old engine to a newer versions keeping their functions without having to constantly remake them?
Keeping functions in a game engine. Switching engines
? what your suggesting is that your Modifying the acctual engine code? and when a new version is released, you code get overwritten?
Thats bad design isnt it?
Surely you have your DLLs structures like so:
SomeGenericGameEngine.dll
MyGamesBase.dll
MyGame.exe
Where MyGame.exe uses MyGameBase.dll which contains all the functionality of your Game, and uses SomeGenericGameEngine.dll which contains all the Code which an engine like Havok, Crytek or XNA has etc.
You dont' directly modify the Crytek engine, or the Havok engine to suit your needs, you tailor your own DLL surely?
Author
What I was referring to is actual code, the game engine that I'm currently using is written in c++ and uses only .cpp and .h files.
? what your suggesting is that your Modifying the acctual engine code? and when a new version is released, you code get overwritten?
Thats bad design isnt it?
Surely you have your DLLs structures like so:
SomeGenericGameEngine.dll
MyGamesBase.dll
MyGame.exe
Where MyGame.exe uses MyGameBase.dll which contains all the functionality of your Game, and uses SomeGenericGameEngine.dll which contains all the Code which an engine like Havok, Crytek or XNA has etc.
You dont' directly modify the Crytek engine, or the Havok engine to suit your needs, you tailor your own DLL surely?
What I was referring to is actual code, the game engine that I'm currently using is written in c++ and uses only .cpp and .h files.
I have three suggestions:
1) Stick to one engine version.
2) Do not modify the actual engine code.
3) Instead of updating between releases, regularly pull in changes in the engine's repository. Keeping modifications alive will generally be easier with a sequence of small incremental merges than with monolithic changes between releases.
That said, I would strongly prefer (2), followed by (1) if it absolutely has to be done. My personal opinion is that if you have to do such modifications to the 3rd party engine you either picked the wrong engine to begin with or an engine that was not sufficiently along in its development to use it in an actual product.
1) Stick to one engine version.
2) Do not modify the actual engine code.
3) Instead of updating between releases, regularly pull in changes in the engine's repository. Keeping modifications alive will generally be easier with a sequence of small incremental merges than with monolithic changes between releases.
That said, I would strongly prefer (2), followed by (1) if it absolutely has to be done. My personal opinion is that if you have to do such modifications to the 3rd party engine you either picked the wrong engine to begin with or an engine that was not sufficiently along in its development to use it in an actual product.
I keep a log of all changes with the originally codes and the changed code in two different files under two different folders for backup. When and IF I do an update due to a new version I simply re - implement my old changes according to the log in the new version(it can take some time but it is worth it). I use Torque 3D MIT(hence .cpp and .h files are also used heavily here :) ) and this has worked until now.
Of course until now my changes has been very few and more physX related than anything else so I guess it is not really a huge problem. Anyway my advice is to keep a log of changes with two folders where one is with the original .cpp/.h files and the other with the changed .cpp/.h files. When you update you will know what to re implement from you log and the folder with changed .cpp/.h files.
For a more elaborate engine, switching versions is much like migrating from one Microsoft server solution to another...
It can be a project in its own right. So think it through before switching! ;-)
But I must have the latest and greatest bugs!For a more elaborate engine, switching versions is much like migrating from one Microsoft server solution to another...
It can be a project in its own right. So think it through before switching! ;-)
But I must have the latest and greatest bugs!For a more elaborate engine, switching versions is much like migrating from one Microsoft server solution to another...
It can be a project in its own right. So think it through before switching! ;-)
Lol 
If you have a reason to modifiy a complete game engine, you are mostly likely not understanding how to use the game engine in the first place. And are then ruining optimizations etc that is doing behind the scenes for you!
Recommendation: Reread the engine doco
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
