• 13
• 18
• 19
• 27
• 10

How to design a framework?

This topic is 2517 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I'm working with C++ and the SFML library.
I made basic games but VERY unorganized, pretty much all in the one header file. No OOP, no classes, well, very few.

I wanted to make a "game engine" or something similar, just a framework. Well organized, not sure how to go about doing it, this is the problem i ran into.

 int main() { myGameEngine myGame; while(1) { myGame.MasterLoop(); } } 
I would have code like this, and the "masterloop()" would be located elsewhere obviously. Let's say I wanted to have an "entity" class that controls monsters/items/etc. How would I store these "ents" and there data, so that the "myGameEngine" class can reach them? (assuming there in a differnt class). Example:

 class Entity { public: void GetEntityType() private: sf::Sprite EntSprite; }; 

I understand I can have the "gameengine" class inherit the class, but this doesn't seem "organized". I'm sorry if im to vague. Nothing feels right,
What's the best way to break up parts of a game (2D - SFML)?
Thanks!

Share on other sites
First of all I would like to say hello, it's my first post .
Now for the framework. You could implement the MasterLoop inside the MyGameEngine class, and store classes like entites in some kind of data structure (ie. List). My approach would be very XNA like - The MyGameEngine could have a method called Update witch would be bassicaly a MasterLoop and calls to Update methods for the entities. This Update methods would handle the game/entites logic. As for Drawing it could be pretty much the same, the main class calls Draw methods from all entities it has. That way in the main function you have something like: myGame.Update() and it handles all the basic nessesary stuff. So the entity class should have some basic fields, like a model/sprite. Then you could create ie. a monster class witch would inherit from entity and implement it's logic (AI, collisions etc.).
As for the data structure a good approach is a scene graph (http://en.wikipedia.org/wiki/Scene_graph) that by its construction gives you quite nice order and logic.

I hope this helps a little, sorry for my English btw

Share on other sites
Hi.

While I am not a big fan of XNA, I do however like their "GameComponent" and "GameService" approach alot. Might I suggest you look into this? I am not sure if you're familiar with C#. If so, you could download Reflector (which enables you to disassemble managed code, and step into its sourcecode). The game/component/service architecture in XNA could be an excellent starting point for you.

One way to look at it (certainly not the only way....):

An example could be a manager that manages monsters. Make it a class. With several methods like: Initialize(), Uninitialize(), Update(), Draw(). Those update an draw methods get called by the game every single frame. The manager then starts updating and drawing all monsters that it is managing. Monster would be a class. The manager would hold a list of Monster-objects. You see how the game doesn't necesarrily have to know about monsters? The game just "provides" something for the monsters to be able to exist. You will need to think of what your game needs to provide. Make managers for most stuff. Feed those managers stuff to manage.

Then, looking at another side. Your framework could define a basic class for Monster. You could subclass that for example: FlyingMonster, SwimmingMonster, etc. Within each subclass you would handle the specific movement rules for that subclass. Your manager doesn't really need to know how to move the monsters. They know it themselves. The manager might just tell them that they can move from there to there but no further than that. It gives them some rules. Instead of subclassing all your game objects, like monsters, bullets, I could advise you too look into object composition, instead of object subclassing. This could be a vital design decision in your framework.

One of the dangers of writing a framework is that often you might find yourself wanting too much. What purpose does this framework fulfull? Keep asking yourself this. Is this a framework for just this game, or would you like to make more games with it? Would it serve as a general framework, allowing for alot of things you dont always use, or does it just, and only just that, provide what this one game requires? Usually one speaks of a framework when you intend to deliver a flexibile component structure. When you're talking of just getting your game object oriented, you're not necesarilly speaking of a framework, merely an OO-paradigm.

Share on other sites
Thanks for the information. I've tried alittle more using the ideas above. But getting to the techincal side of it. I have this for example:

 #ifndef _INCLUDE_ENGINE_H #define _INCLUDE_ENGINE_H #include "INIReader.h" #include "AudioManager.h" namespace NNEngine { class CNNGameEngine { public: CNNGameEngine( void ); ~CNNGameEngine( void ); void Load( void ); void Unload( void ); void RunLoop( void ); // Interfaces AudioManager *audioManager; private: }; } #endif 

I'd have quite a few "interfaces" that are loaded onto the heap in the "load()" and deleted on the "unload()". I would use this class like so:

 #include "../Engine/includes/Engine.h" #include <iostream> int main() { std::cout << "Trying to add a sound file...\n"; NNEngine::CNNGameEngine MyTestGame; MyTestGame.audioManager->AddSoundEffectToList( "derp","derp.wav" ); std::cout << "Added derp.wav labeled as derp to the precache/ram\n"; system( "pause" ); return 0; } 

Does this seem like a probable way of doing this?

Share on other sites
Hidden
To me, an engine is a collection of classes that work together. The way you have it there, your Engine is the main class, which contains links to all your other classes (through interfaces).

Personally, I would probably have NNEngine as a namespace that all these classes belong to.

Then in your Game/Logic/Controller class you have a way to register an AudioManager class.

That way you end up with something like

 #include "some/path/to/engine/include.h" using namespace NNEngine; int main() { CNNGameEngine MyTestGame; AudioManager MyAudioManager; MyTestGame.LoadAudioManager(&MyAudioManager); MyAudioManager.LoadSoundEffect("blah", "path.wav"); MyAudioManager.Play("blah); } 

Obviously not a full example, but this is how I tend to do things in my engine (passing pointers around for classes for interaction).