🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Suggestions wanted...

Started by
0 comments, last by null_pointer 24 years, 7 months ago
I wanted to learn more about C++ and DirectX, so I decided to try my hand at building a game library in C++ for Win32.
I wonder if anyone can give me suggestions about what classes (and methods) they would like to see (and would not like to see) in a library like that? Any suggestions/comments would be most welcome.

BTW, the library will have MANY different classes (well over 100). I'm only putting a few classes inside the DLL (CGame, CWindow, etc.), and then bundling the complete source for the rest with the library package.

This allows me to build very specialized classes without people complaining about me taking up too much memory. Users can add the supplied source to their own programs when they want to use the extra classes (i.e. any app that wants a title bar can add the TitleBar.h and TitleBar.cpp files to its project. Apps that don't want a title bar will not have any overhead because the TitleBar.h and TitleBar.cpp are not even in the project).

So, suggest as many classes (and methods) as you'd like!! Non-OOP ideas welcome too!

Thanks!

Advertisement
These aren't class ideas, but they are worth looking at:

Please don't use names following the MFC naming convention [ie. C followed by class name] because of the infinte potential name conflicts, inlcuding FUTURE classes library vendors(Microsoft in this case) will add. Notice that Borland uses T followed by class name, and other vendors have OTHER prefixes, so as to minimize the inconvieniences of mixing libraries.

Also, make sure and put ALL of your library into a namespace, so even if conflicts arise, the user has access to ALL classes to both libraries (even though it will be less convienient than no conflicts).

I myself am programming a more basic library: various tree containers in STL style, and have chosen to use a unique prefix AND a namespace, and then ANOTHER namespace that uses more common names. This lets the user include the first namespace in ANY case, but if he/she knows there is no conflict, they can include the second namespace (or just parts of it) to access the elements without needing the prefixes. Example:
namespace Vx // my company prefix
{
class VxTree;
class VxBTree;
class VxBinarySearchTree;
};
namespace VxPlain
{
typedef Vx::VxTree tree;
typedef Vx::VxBTree btree;
};

Anyway, good luck sir.

This topic is closed to new replies.

Advertisement