DLLs and libraries for iso engines

If all you want to do is keep the engine code seperate from the client code, you could just put them in seperate folders and compile them both into an EXE

I think the question should not be how to keep them seperate, but rather how to make the engine reusable. Now we can discuss static libs vs dlls.

Ask yourself a few questions.

1) Is this code going to be used in more than 1 project?

2) Will updates be made available for those who have a game that uses the engine?

3) Will the engine be improved/refined over time?

If you answered yes to all 3, I would recommend dlls. This way, you don''t have to rebuild the game everytime you make changes to the engine. If you want your earlier games to take advantage of improvements in the new engine, just replace the DLL and voila! Your old games now have faster blitting speeds/level loading or whatever changes you''ve made.

Two caveats to keep in mind for this approach to work:

1) Any changes you make to the engine should not break backwards
compatibility. Don''t go removing methods or changing method names and expect your older games to work.

2) Do not link to the export lib which is created when the dll is built. Your app will be bound to that specific version of the dll and could possibly break if you try to use a different version. Instead, create your own static lib which loads the dll with LoadLibrary and load any functions you need to expose. Then, provided you''ve followed 1 above, there should be no problems.

With all that said, I typically use static libs myself. All of my development thus far has been for research/recreational purposes. When I finally reach the point where I''m pumping out games for the masses, you can bet I''ll use the dll approach. Then the end user only needs to download 1 file to update the game everytime I change the engine.