I am working on a screen manager for a miniature game engine, and so far I cannot find a proper solution to managing screen objects without using the 'blob' for each one of the screens. Is blob tolerable in such circumstances where I need a list of renderable objects in one controller?
I would consider using the MVC pattern in this situation. Otherwise, if you're not careful, it's very easy to end up with a bunch of spaghetti code where the screen code is reaching into the game code, and vice versa.
I have recently coded something you might call a "screen manager".
I started with the idea that, whatever game I make, the render system is going to be pretty much the same in terms of how to render (how to manage the hardware). The thing that changes is what is rendered, and how to draw it (do I want a box or a circle or a bitmap.. representing what... etc).
So basically the "game state" is responsible for knowing how to render itself, and should do so when given a render surface from the screen manager or graphics system (It should also be responsible for other things like knowing how input, physics, etc act upon itself).
I implemented it with a singleton for the GraphicsSystem object, which was called something like this:
GameState gs;
Graphics::System().Init(DOUBLE_BUFFER, 640, 480);
...
while(still_looping) {
...
// When it is time to render:
Graphics::System().RenderGameState(&gs);
}
And how, you ask, does the Graphics::System() singleton know how to render the game state? It knows because the game state is inherited from a listener exposed by the graphics system...
//within GraphicsSystem.h...
class BaseRenderer
{
public:
virtual void Render(BITMAP *render_surface) = 0;
};
//GameState defined with:
class GameState : public BaseRenderer
{
public:
void Render(BITMAP *render_surface);
...
You can do this with nearly all the subsystems... (probably not timing, as it is needed in the game loop).
Why singletons? Well, it is C++ and I'm assuming there is only 1 screen, or graphics subsystem to render with. I'm not sure if you are using multiple screens, or a mobile phone or a console. The other way I would do it is to have the graphics system as static global variables in a separate file, giving them file scope only, and having accessor functions in that file (my old C way of doing things).
The key though is encapsulation. Let your screen manager manage the hardware. Let your game state dictate how itself should be expressed.
If this misses the point, please clear up your question and I can edit the answer.
Related
I am planning on making a 3D scene editor app using c++ and open gl. And I have to keep track of the current loaded project and different scenes it contains also the user preferences and other things. The best solution I can think of is to wrap them in a context class which will be a singleton. Is there a better way of doing this?
Not a good idea, probably. One reason is technical. The actual OpenGL context's lifetime is limited and is far shorter than app itself, usually related to surface you're outputting to. You would need to initialize context after your visualizing window is ready and de-initialize it before window is gone. Trying to do so when window gone may end to undefined behaviour depending on platform. In some cases you might need several contexts.
Another reason is, it doesn't look like proper separation of responsibilities. User settings aren't part of context, but some may affect only a single render pass (out of plural). You likely would have Preferences, Renderer which would be an interface to Context manager, Geometries, Textures (or materials) separate, an Scene Manager as well (think of scene tree in Blender or DAZ studio, each item in scene can have separate user settings, regarding how to visualize them).
I'm developing a 2d fighting game in c++ (for learning purposes) and I'm having a hard time figuring out how to properly implement game logic. For a quick overview of my current architecture, I have component classes that act as data holders and I have 'systems' which are just functions designed to act on those components. I have a scene class which holds an array of fighters that are currently in game and this scene is passed to individual sub-systems which then can freely act on fighter components, updating fighters state:
//Add a fighter object to array of fighters and set starting position
scene.CreatePlayerFighter(160.0f, 0.0f);
scene.CreateAIFighter(80.0f, 45.0f);
gameWolrd.Init(scene);
Renderer.Init(scene, window);
AI.Init(scene);
//etc...
//Game loop
while (true)
{
Input.Update(scene);
Physics.Update(scene);
AI.Update(scene);
//etc....
window.ClearBuffers();
Renderer.Update(scene, colorShaderProgram);
window.SwapBuffers();
}
Again, inside each sub-system (Renderer, AI, Input, etc.) all fighter components are being passed into system functions and spit back out with new values which are then inserted back into fighters:
void Physics::Update(Scene& scene)
{
for (Fighter& fighter : scene.fighters)
{
//Update fighter position based on fighter's current velocity which has been set by input
TransformComponent newFighterPosition = System::MoveFighter(fighter.GetComponent<TransformComponent>(), fighter.GetComponent<VelocityComponent>());
//Insert new TransformComponent to update fighter's position
fighter.Insert<TransformComponent>(newFighterPosition);
}
}
This current architecture has the advantage of being loosley coupled in that I can add and remove systems very easily without effecting the fighter class or it's components directly. The problem is everything is hopelessly serial, as my scene is passed into each sub-system one by one to update fighters. I mention this problem because one of my thoughts to implement a game logic layer was to have higher level classes just call specific game engine system functions directly like physics.MoveFighter(TransformComponent, VelocityComponent, float amountToMove); where I can add additional parameters to give the user at the game logic layer level more control. Of course doing things this way means system functions would be called and invoked in any order the user of the game logic saw fit. Would there be a way to still implement a game logic layer in this way and maybe queue up all calls and reorder them to run correctly within the game engine? Or would there be a better way to try and implement game logic within my current architecture?
As I see your goal, you could just store movementFactor field in fighter, and allow to change it from game logic layer. In Physics class delta is then mul-ied by that field. If you use component like system you probably do not want to update components manually, only operate with data.
Logic update order is a complex problem: imagine a chicken falling on an egg. It happens that in the same frame chicken touches the egg and egg is ready to show us new little chick. What should be executed first? That depends on what is updated first: physics or eggs, and on the fact whether reactions apply immediately. The best scenario (most fair usually) would be for them not to apply immediately, but form a stack of objects (components) state changes, for them to be resolved independently after the action phase.
Also make sure you do not want to stick with existing entity system like entityx.
I am at the start of my cocos2d adventure, and have some ideological questions to ask. I am making a small space-shooter game, am I right to use the following class structure?
Scene
Background Layer
Infinite parallax background
Game Layer
Space ships
Bullets
Control Layer
Joystick
Buttons
and a followup question — what is the best practice in accessing objects from other layers? For example, when the joystick is updated, it must rotate the space ship and move the background. Both of these are in other layers. Is there some recommended way to go about this or should I simply get the desired objects by Tag and operate on them?
Cocos is a big singleton-based system, which may not appeal to some developers but is often used in Cocos apps and is the fundamental architecture of the framework. If you have one main scene and many subsequent layers added to that scene, and you want controls from one layer to affect sprites or logic on other layers, there really is nothing wrong with making your main scene a singleton and sending the information from the joystick layer back to the scene to handle for manipulating other layers or sprites. I do this all the the time and this technique is used in countless Cocos tutorials in books and online, so you can feel that you aren't breaking too many rules if you do it this way (and it's also quite easy to do).
If you instead choose to use pointers in one layer to send data to other layers, this can get you into a lot of trouble since one node should never own another node that it doesn't have a specific parent-child relationship with. Doing so can cause crashes and problems with the native Cocos cleanup methods when you remove scenes later, and potentially leak memory. You could use a weak reference in such a case instead, but that is still dependent on one layer expecting another layer to always be around, which may not be the case.
Sending data back to the main game scene to then dispatch and use accordingly is really efficient.
This seems like a perfectly reasonable way to arrange your objects, this is a method I use.
For accessing objects, I would keep an explicit reference to the object as a member variable and use it directly. (Using tags isn't a bad option, I just find it can get a little messy).
#interface Class1 : NSObject
{
CCLayer *backgroundLayer;
CCLayer *contentLayer;
CCLayer *hudLayer;
CCSprite *objectIMayNeedToUseOnBackgroundLayer;
CCNode *objectIMayNeedToUseOnContentLayer;
}
Regarding tags, one method I use to make sure the tag numbers I'm assigning are unique is define an enum as follows:
typedef enum
{
kTag_BackgroundLayer = 100,
kTag_BackgroundImage,
kTag_GameLayer = 200,
kTag_BadGuy,
kTag_GoodGuy,
kTag_Obstacle,
kTag_ControlLayer = 300
kTag_Joystick,
kTag_Buttons
};
Most times I'll also just set zOrder and tag properties of CCNodes (i.e. CCSprites, CCLabelTTFs, etc.) the same, so you can actually use the enum to define your zOrder, too.
Im in the middle of creating my first iPhone game - I have a background in OOP and in particular C++ so I had some questions with regards to how best to logically setup layers while maintaining functionality.
Currently I WANT for my game to have three main layers:
HUDLayer (All static objects on the screen are here - game controls, User score, pause button etc.)
PlayLayer (The Player, the main game loop and all of the game logic here)
Level Layer (The level images and the level physics objects that the player interacts with, and the background music specific to this level)
Notice I used the word WANT here - because for the life of me im constantly having to move logical objects around just to work within what appears to be Cocos2d's and spacemanagers structure.
Below are just some of the issues that I'm facing
I would like for my PlayLayer to be the scene thats loaded by the director - but if I do that then all of the HUDLayer objects get covered behind the PlayLayer, and dont stay in place like they should, hence the HUDLayer is my scene and I have had to do that just to make it work
I would like to play the background music (via simpleAudioEngine playBackgroundMusic) in the LEVEL layer because I want different levels to have different music. So far the ONLY way I have gotten background music to work is to have it in the TOP most layer i.e. in this case the HUDLayer
Because of the fact that I have to use an instance of the SpaceManagerCocos2d object to create physics bodies - it seems like my level layer has to be killed and just incorporated within my PlayLayer otherwise im having a nightmare of a time attempting to detect collisions between the player and the level.
Am I missing something very obvious here? is there a core understanding of layers that Im just not getting? More and more I feel like im being pushed by the framework to build the whole game inside of a single class and just to use layers as scenes.
Is anyone else having these problems? Am I approaching the architecture of the game wrong? Any help would really be appreciated.
Thanks in advance guys!
Well, each game is different. There are many good discussions on the cocos2d forums about architecture, some people prefer to use an MVC approach, some like using an Actor metaphor to contain physics objects, etc.
Here's my approach:
Use two CCLayer objects (GameLayer and HUDLayer) as child nodes of one CCScene (GameScene). These are the "view" objects.
Create a GameController singleton that can make changes to the game state (also stored in GameController, or in a separate file.) You could also subclass CCScene and call that your controller.
GameLayer is in charge of rendering the graphics of the game level and all actors in it; it also handles getting game input via touch events.
HUDLayer is placed at a higher z-index than the GameLayer and obviously has all of the CCSprite objects for the HUD and buttons.
Interaction between the HUDLayer and the GameLayer is managed via the GameController.
GameController does all of the state changing and game actions.
That's just my approach because it worked for my current game, and it by no means is the definitive answer.
I'd suggest that you look into using an Actor paradigm for your physics objects -- SpaceManager does a decent job, but you don't necessarily always want physics objects to extend CCSprite.
I'm new here, and have a question about opengl in Qt4, which I've been learning over the last few months.
Particularly, I'm seeking advice on the best way to compose a scene in a good object-oriented fashion using the QGLWidget. I'd ideally like every item in my scene to be sub-classes of a super 'Entity' class. Then in my main QGLWidget I can sort the entities and render them accordingly.
I noticed though that certain openGL functions (like bindTexture) need to be called from the QGLWidget (or the widget's QGLContext). At the moment I'm passing a pointer to the QGLWidget that controls my main viewport to each entity and storing it so that I can gain access to those functions. Is this a good idea?
Any advice would be gratefully received, or even directions to good websites/books that might be of help. I've got the Blanchette/ Summerfield book but the OpenGL section is quite short and most of the examples on the Qt website are pretty simplistic.
Thanks,
Dan
I agree with Vime: You're building a scene graph, and there are a number of classical approaches for designing its object hierarchy. Check out "3D Game Engine Design," by Dave Eberly, for details on one such engine, and look at OGRE for another example.
Since only one GL context can be active at a time on a particular thread, consider storing the QGLWidget pointer as a static class member to save effort:
class MyGLWidget : public QGLWidget {
// ...
public:
static inline MyGLWidget *GetActiveWidget() {
return ms_activeWidget;
}
protected:
static __declspec(thread) MyGLWidget *ms_activeWidget = 0; // uses MSVC extension
inline void SetActiveWidget() {
ms_activeWidget = this;
}
};
void MyGLWidget::paintGL() {
SetActiveWidget();
// ...
}
Then in your entity classes you can simply call MyGLWidget::GetActiveWidget() on the few occasions when you need to call QGLWidget member functions, and not need to copy a (probably invariant) pointer all over the place.
You are building something that is usually called "scene graph". In our engine scene graph objects need no access to QGLWidget. It's enough if you create your OpenGL objects inside void initializeGL() and render everything inside void paintGL().
There is a slightly higher level Qt/OpenGL example called Boxes. It can be found from qt/demos/boxes folder in Qt 4.6 installation.