A DLL-based approach for my game

Started by
21 comments, last by rpg_code_master 17 years, 10 months ago
Sorry if this is a bit lengthy. I just want to know what people think: My current daft little DirectDraw platform game defines a virtual interface to Items providing enough information to draw them and call an Update function each frame. This is all the main engine sees and later units then implement this interface for the player, enemies, pickups and so on. My level file contains definitions for items that start with an ID number, which is passed to a Factory function along with the InputStream thing that is reading the level file. The Factory then returns a new Item, whose type is based on the ID number and which is passed the InputStream in its constructor. The constructor for each type of item then uses the InputStream to initialise the various type-specific properties of the item. Now, I started playing around with making DLLs the other night and discovered that by including the virtual Item interface in the main program and the DLL, I can then implement the Item in the DLL and just export one MakeInstance function that the main program calls to get an Item pointer to the DLLs specific type (or types). So I am now thinking that I could implement each different item in a seperate DLL (or several in one DLL, whatever) and my level file could register DLLs with the engine, along with maybe string identifiers to represent the types it provides, then the Factory could query this registry to find the right HMODULE and get the implemented item as an Item pointer from the DLL and return it to the main engine. Then I could add new sorts of items (e.g. new enemies, new pickups) to a level without recompiling the main engine or even having access to the source, just by writing a new DLL that includes the virtual Item interface, implements it and exports the MakeInstance function and is identfied in the level file. The only other things the DLL really needs to access is the Map and the various Item lists that are currently used for collision detection etc so I figure that I could include these units in each DLL then pass in pointers to the Map and List objects the main game creates. Is this all really plausible or are there horrendous pitfalls that are waiting for me down the road? Again, sorry this is such a lengthy post and please feel free to rip my thoughts to pieces. Just wondering what people think. Ta. Paul
Advertisement
Well I don't know about many pitfalls. But I'm trying to fix one right now. The application I'm working on takes a minute and a half to load because it has well over 200 DLLs. If you close the app and relaunch it right away, it loads in 11 secs. Windows caching is powerfull... but take care about the number of DLLs because it could affect load time, unless that's not a problem ;) Also, you might want to add a rebase command at post build step to make things faster...

position the batch to the dll folder
rebase -b 0x60000000 *.dll

But don't bother unless you have > 50 Dlls or load time gets ugly...
Cheer yalpe. What is rebase? Does it ship with compilers? Just tried it in a console on my work PC and doesn't recognise as a command.

Can't see it being problem for me anyway as all the LoadLibrary and indeed the first call of the MakeInstance function will be done on level load anyway. I could do with a bit of a delay there to make the game look more "professional" :) (some hope).
http://www.gamedev.net/community/forums/topic.asp?topic_id=397942

Check out this thread. Someone posted a very interesting link explaining what happens at load time.

There is also this one explaining rebase :

http://www.codeproject.com/dll/RebaseDll.asp

Rebase ships with any version of VS I think. Its in the bin directory somewhere. You might have to set your PATH env variable for it to work though.
Thanks again. Interesting stuff although I don't really think I need worry for what I am doing at the moment.

I'm using Borland free compiler at the moment as I unfortunately still have Win98SE (don't laugh) on my home computer so can't install VC Express. I guess I'll just have to let DLLs sort themselves out.

If it causes a major lag, I'll just write a progress bar and claim my game is working out complex NN-based AI or something.
Good god, man. Importing a DLL for every single item? What would be the point of this monstrous waste of resources?
Fair point. Just playing around with the idea really. Maybe just one DLL then? Please?
Making your application modular is commendable, but you don't need to use DLLs to do this. You can just have your different modules statically linked together at build time.

This will save a lot of startup time and make everything dramatically easier to set up.

Mark
Yeah, that is what I am doing at the moment really. I'm glad I said please feel free to tear this idea to shreds, because that appears to be what has happened.

Cheers all. Scrap that then. :)

You can use dynamically linked DLLs without any problems. Just few points that this conversation has brought up:

- 200 DLLs is far too much
- You don't need one dll per new thing.

My solution:

- 1 DLL for each engine subsystem (ie. graphics, sound, networking)
- A number of DLLs required for game entities, but also scene management etc

One DLL may contain lots of different kind of things, such as vehicles, characters, items. As the design is data driven, no new entities are needed so often.

- The base of everything here is a class factory. I made it in a way that I need to drop only one lib file to the dll-project and it is ready to be used as a part of the game engine.

This topic is closed to new replies.

Advertisement