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:

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!

0

Share this post

Link to post

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

0

Share this post

Link to post

Share on other sites

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.