Sign in to follow this  

A DLL-based approach for my game

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

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

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Good god, man. Importing a DLL for every single item? What would be the point of this monstrous waste of resources?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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. :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Yeah, I suppose that is more what I was thinking than literally a DLL per type of item. I was thinking of having lots of items in a DLL and a way of the DLL registering the items it could export when it was loaded.

As I said, I do take the perfectly good points above about waste of resources but I just really like the idea of being able to add in a completely new sort of end-of-level boss or pickup to a level without having to recompile the engine.

I know next to nothing about this but, surely this is how modding works on commercial games? It is really more of academic interest to me since I doubt my 2D platform side-scroller is ever going to exactly take the world by storm. So far it has failed to even take my house by storm.

I was also thinking last night that I don't really want all the Map code and so on replicated in each DLL. Then I thought - aha. Put it all in a DLL. So my current thinking is to have one sort of API DLL that supplies all the common framework to the engine and the other DLLs, so I presume this would only be loaded once for all the components, then, as Demus79 suggests, have a compile-time linked lib file to link this DLL with the main game and each of the other DLLs.

I think this is a bit like when I first went C to C++ and went loopy with classes for a few months. Ah, happy days. I'm sure in a few months I'll look back on this DLL-loopy stage and laugh.

Share this post


Link to post
Share on other sites
Modding is made possible by leveraging data-driven design. Modders create new resources such as map files, models, sounds, scripts, etc. in order to modify the game. Changes to the actual compiled software are not necessary.

Share this post


Link to post
Share on other sites
Quote:
Original post by Yalpe
Gone loopy with patterns yet? ;) http://www.dofactory.com/Patterns/Patterns.aspx


Funnily enough, I've just fininshed reading Design Patterns (Gamma et al). Very interesting read indeed. I suppose in a small way I am already using Factory in the context above. I certainly want to look at Visitor next time I am writing a script compiler although haven't quite got it all settled in my head yet.

@rpg_code_master, it is certainly another way to approach things. I've written quite extensive text-adventure scripting languages before but never really tried to apply this to DirectXy graphics projects. I tend to find it hard to rein myself in and end up trying to rewrite C++ (failing miserably, obviously) but it is certainly worth a thought.

Share this post


Link to post
Share on other sites
Quote:
Original post by EasilyConfused
@rpg_code_master, it is certainly another way to approach things. I've written quite extensive text-adventure scripting languages before but never really tried to apply this to DirectXy graphics projects. I tend to find it hard to rein myself in and end up trying to rewrite C++ (failing miserably, obviously) but it is certainly worth a thought.

There is not need to try and re-write C++. Check out Lua or C# as scripting languages. They are very powerful and extremely well documented. Also, a game with graphics or a game without graphics should have no bearing on the choice for using a scripting language or not. Graphics are simply a method of outputting the game's information. Using a scripting language will make the actual managing and creating of the game easier.

Share this post


Link to post
Share on other sites
I was sometimes also thinking about .dlls for my small engine. Why did I stop?
1.) It is not commercial right now
2.) Lib's are easier to integrate than .dlls
3.) You can not use STL ( std::list<cResource*> m_ResourceManager )

On the other hand, if you have to recompile a dll you can also recompile a lib don't you? Sure, .dlls are more reusable to 3rd persons, but if you are coding alone it has no sense.

Share this post


Link to post
Share on other sites
DLLs enable reusable code. What would you say for instance, if you wanted to use your engine, but wanted to use a different graphics API with it? By using a DLL to store the actual inner API code, even if you are coding alone, would make your task ever so must easier.

Share this post


Link to post
Share on other sites
Quote:
Original post by rpg_code_master
DLLs enable reusable code. What would you say for instance, if you wanted to use your engine, but wanted to use a different graphics API with it? By using a DLL to store the actual inner API code, even if you are coding alone, would make your task ever so must easier.

I would say "recompile with the other API".

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by rpg_code_master
DLLs enable reusable code. What would you say for instance, if you wanted to use your engine, but wanted to use a different graphics API with it? By using a DLL to store the actual inner API code, even if you are coding alone, would make your task ever so must easier.

I would say "recompile with the other API".

I'd say that is far too awkward. If the engine was hard coded to use OpenGL, and you had that dotted about all over the place, then replacing that with DirectX or another console API would far to inconvenient. You would be better having a custom API and using that in the engine then having the OpenGL code, DirectX code etc... in a DLL, hence supplying the inner API code.

Share this post


Link to post
Share on other sites
Quote:
Original post by rpg_code_master
Quote:
Original post by Sneftel
Quote:
Original post by rpg_code_master
DLLs enable reusable code. What would you say for instance, if you wanted to use your engine, but wanted to use a different graphics API with it? By using a DLL to store the actual inner API code, even if you are coding alone, would make your task ever so must easier.

I would say "recompile with the other API".

I'd say that is far too awkward. If the engine was hard coded to use OpenGL, and you had that dotted about all over the place, then replacing that with DirectX or another console API would far to inconvenient. You would be better having a custom API and using that in the engine then having the OpenGL code, DirectX code etc... in a DLL, hence supplying the inner API code.

You're confusing dynamic binding with modularization. Whether the graphics stuff is in a DLL or in its own set of object files has nothing to do with whether its interface is abstracted enough to be implemented with a different API.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
You're confusing dynamic binding with modularization. Whether the graphics stuff is in a DLL or in its own set of object files has nothing to do with whether its interface is abstracted enough to be implemented with a different API.

Yes, I see. Good point!

Share this post


Link to post
Share on other sites

This topic is 4201 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this