   Engine Design
  Hello!I know I've been pestering you all with design questions, but, sure enough, I have a few more!I fleshed out a messy but cooperative engine for SDL and began developing more specific features for a project of mine. After examining a few small problems I encountered and some brainstorming, I thought I'd concentrate my effort on a much more versatile engine I could easily reuse for any kind of game that SDL can support (namely 2D games).At the moment, I'm calling this engine of mine XEngine. I did a few very quick relational diagrams outlining the classes involved, which are all prefixed with an 'X'.Anyway, this engine will have the same modular feel to it as the system I was developing earlier has. Here are my questions.I want to make this engine more versatile and reuseable... and perhaps give it to other people (beginners) to play around with. Although I'm using C++ to create it and a multitude of classes, should the interface presented to the user consist of only functions and methods, or should the user actually work with classes that belong to the engine?In my  outlining, I've underlined classes that the user would actually make use of, like XSprite, XJoystick, and XAudFmt. For example, the user could load a sprite and manipulate it's properties by simply instantiating an XSprite object. The alternative would be something like an AddSprite() or CreateSprite() function and a set of accompanying functions to manipulate the sprite.Which design is more acceptable? I have to admit, I very much favor the user making use of the actual classes that the engine has to offer. I'm sure I could incorporate some sort of protection to prevent the user from instantiating classes that she shouldn't, including integral component classes like XGraphics and XTimer.Also, the engine I've fleshed together so far uses a generic, abstract object class to represent any and all game objects. Upon instantiation, all objects of this generic class register themselves with the engine, which handles updating them and maintaining a useful list and information. I like this approach, but it would mean that people who use XEngine would have to derive all of their game objects from this generic object: XObj.I know some newer languages like C# actually incorporate this sort of idea into the language. I mean, all C# objects are derived from System.Object. Is this a good approach? Does it make sense for users to derive all of their game objects from an XObj class?I could just as easily include functions to register and unregister objects with the engine, but it could be difficult to implement because there would be no base type to work with.I think I prefer deriving from a generic object. What do you think?Well, those are my two big questions. If there are any other issues with design that are worth mentioning, please do! This will be my first comprehensive engine.Thanks in advance!   
Quote:Original post by GenuineXPAt the moment, I'm calling this engine of mine XEngine. I did a few very quick relational diagrams outlining the classes involved, which are all prefixed with an 'X'.I know this isn't a question of yours, but if I were using your engine, I'd prefer that it was enclosed in a namespace.Quote:In my  outlining, I've underlined classes that the user would actually make use of, like XSprite, XJoystick, and XAudFmt. For example, the user could load a sprite and manipulate it's properties by simply instantiating an XSprite object. The alternative would be something like an AddSprite() or CreateSprite() function and a set of accompanying functions to manipulate the sprite.I tend to favor the latter approach. And, if createSprite() returned a smart pointer, it would make it even easier for beginners to use.Quote:I'm sure I could incorporate some sort of protection to prevent the user from instantiating classes that she shouldn't, including integral component classes like XGraphics and XTimer.You can simply expose functions that work with those classes. Ie., the client doesn't even have to have the class declaration.Quote:Also, the engine I've fleshed together so far uses a generic, abstract object class to represent any and all game objects. Upon instantiation, all objects of this generic class register themselves with the engine, which handles updating them and maintaining a useful list and information. I like this approach, but it would mean that people who use XEngine would have to derive all of their game objects from this generic object: XObj.What exactly does "game objects" include?;  I'm sorry that I didn't reply for awhile. Thank you for the response.I think what I'm really aiming for is more of a class library-engine hybrid of sorts.I've packed all of my classes into the XLib namespace. I plan to include some useful functions within this namespace to make working with my classes easier, but I think I'd rather use some of the classes directly.It would be nice to see something like this become helpful to beginners, but I only had beginners in mind because this is my first engine of sorts and I don't know how comprehensive or powerful it'll be! :-PI know the term "game objects" is a bit nebulous. Basically, "game objects" encompasses any objects that should be updated by the game cycle and have a logical representation in the game world. For example, the user might derive an Enemy class from XObj and then from that a BigMonkey class. Because all XObj objects register themselves with the engine upon instantiation, the user only needs to create a BigMonkey and it is automatically updated, drawn, and included within the game.What I want is to be able to create certain objects and merely change their properties and values without having to bother with the intricacies of updatinig and drawing.I hope this makes sense. Thanks for the feedback, stylin! :-) Any other comments or ideas are greatly appreciated! Thanks again!   ;  I do have another question! :-)I'm trying to find a good balance between namespaces and classes. Every part of this engine/library is defined within the XLib namespace. I want to include some functions and classes within deeper namespaces as well.At the moment, the class XJostick resides within the XInput namespace (so the full "path" would be XLib::XInput::XJoystick). It didn't seem to make any sense to create a XInput class to manage other input classes, so a namespace seemed perfect. I also want to introduce another input component though: XKeyboard.Now, it doesn't quite make sense to me to create a XKeyboard class. Afterall, there's only one keyboard. I could, however, create an abstract XKeyboard class that contained nothing more than static members. On the other hand, I could just group some useful functions for working with keyboard input within a namespace.I think I'm leaning toward a namespace, but what do you think would make more sense? I eventually want to be able to use a statement like: XLib::XInput::XKeyboard::CheckKey( XLib::XKEY_ENTER )I could simply define a key enumeration within the XLib, XInput, or XKeyboard namespace.An XJoystick can easily be instantiated and used to represent... well, a joystick! I've been able to use my gamepad through this class and am very pleased with it. With a joystick object, you can simply check to see if buttons are pressed or grab the values of different axes. I'd like to use a similar approach with the keyboard. (That is, checking to see if certain keys are pressed, like above.)   