Jump to content
  • Advertisement
Sign in to follow this  
Drakk

How to design a framework?

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

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 this post


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


Link to post
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....):
Your game class does nothing but, well, control the main course of the game. It will take care of setting things up in general, and then it will take care of letting the mainloop run. It will take care of dispatching important system events like input, window resizing, etc. This is your headquarters so to speak. A headquarter needs something to operate with. It needs desks, chairs, people, phones. The headquarter just supplies the environment, but it would be empty without all these objects/people. The headquarters will need something to manage all that. A manager. You would have a manager, to manage all the furniture. You would have a manager to manage all the employees. In game terms, these managers could be your "GameComponents". The game gives them once per frame a chance to update themselves, and possibly draw themselves. What they update and what they draw is of no concern to your game. The game just makes it possible for them to do their work in some environment provided by the game. The game/headquarters makes this possible by providing services like water and electricity. These are your GameServices. Your components make use of the services provided by its host. Typically a video device driver could be a service. Or a multi-threading paged terrain downloader could be a service. When the component needs a terrain patch, it asks the service to go download the patch and signal the component when the patch has become available. The componentn can then use it.

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 this post


Link to post
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 this post


Link to post
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).

Share this post


Link to post
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!