Jump to content
  • Advertisement
Sign in to follow this  
Wurstinator

Scene management

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

Hi,
I am working with C++ but this problem is mostly language independant.

So, I am at the beginning of creating a small game to get used to SFML. One thing which has always been hard for me is to write my classes such that they are mostly independant and easy to manage.

For example, my first idea to run the game was:
There are scene classes and visual classes, deriving from SceneBase and VisualBase respectively. They always exist in pairs of two and represent things like the title screen, the main menu or the ingame screen.
The scene classes are responsible for handling data, user inputs and general game logic like collision detection.
The visual classes are responsible for managing sprites, texts and drawing those on the window.

Then there is a main loop which keeps running until the game ends. It has two local pointer variables of type SceneBase* and VisualBase* which, obviously, point to the objects of the current scene and visual.
It would look something like this:

while (window is open)
update scene
update visual
draw visual on window
end while

As I said, the scene controls its own data so I would have to pass that data to the visual somehow. And of course, a VisualTitleScreen object would need a SceneTitleScreen, not just any SceneBase. So the issue with my idea is that I would have to reinterpret_cast the SceneBase pointer. And I have been told: if you have to use reinterpret_cast in your program, you are doing something wrong :)

So, I am not satisfied with this solution and I am looking for another one.


If I made myself not clear or someone is looking for a tl;dr:
I am looking for good ways to manage data, game logic and visuals of different "scenes", meaning things like the title screen, the main menu, a world map or a battle screen.

Share this post


Link to post
Share on other sites
Advertisement
I am not familiar with MVC, or rather, I was not until now.

Well, partially that MVC pattern and what I had in mind overlap but they also have differences, as far as I can tell from the article.

Model and controller would be combined and more importantly, all three modules would change frequently.

Share this post


Link to post
Share on other sites

I am looking for good ways to manage data, game logic and visuals of different "scenes", meaning things like the title screen, the main menu, a world map or a battle screen.

 

I think you're looking for a state machine, or some derivative.

 

"SceneBase" is poor naming: You should just have a Scene class (the base is implied), with a virtual run method, to execute whatever logic is actually required for that scene.

 

Although, in general, most of your logic would be executed on the entities in the given scene (which would have their own virtual run method), so the default implementation of run could just be:

virtual void run(){
    for (int i = 0; i < entities.size(); ++i)
        entities[i]->run();
}

And most of your scenes would just be instances of Scene, with entities created in the constructor, following some XML scene description, like:

for (int i = 0; i < scene_files.size(); ++i){
    Scene* scene = new Scene(scene_files[i]);
    scenes.push_back(scene);
}

Or something along those lines.

 

*Edit: Sorry for the ugly code blocks - I can't seem to space them out.

Edited by Goran Milovanovic

Share this post


Link to post
Share on other sites
Yes, the scene approach I wanted to make and state machines are very similar. State machines are more complex and powerful though which is not something I need for this small project. Let me clarify: I would like to seperate game logic from graphics entirely. The classic approach of a state machine and similar design patterns always uses scenes/states as a combination of both, usually providing an update() and a redraw() method.

Share this post


Link to post
Share on other sites

Instead of a redraw method, you should have a pointer to visual data, which the Renderer can use to actually draw the object in question, rather than having the object draw itself.

void Renderer::draw(std::vector<GameObject*> objects){
    for (int i=0; i < objects.size(); ++i){
        Visual* v = objects[i]->visual;
        this->setDrawColor(v->color);
        this->drawShapeAt(v->shape, object[i]->position);
    }
}

Fairly simplistic example, but that would be the general set up.

 

If you're working in 3D, using a graphics library like OpenGL, you'll probably want to have things like Mesh and Material, which the renderer could use to set the proper state, and draw the relevant objects.

Share this post


Link to post
Share on other sites

Here's what my in-progress engine is working with at the moment:

 

GameState: (analogous to your "scene")

    Input Manager:

    Resource Loader

    Various logical objects (like a map class, some entities, whatever)

    //etc...

    Scene:(analogous to your "visual" methinks)

        List of Renderable objects, where a renderable is something like:

            Vertex information

            Material Information

        Light Information

        Matrix information

        //etc...

 

 

Basically, the gamestate maintains a list of logical entities, provides them to various physical (renderable) entities that know how to create and/or maintain their own geometry/shader data, and sends a packing of the renderable entities to the renderer.

 

The renderer takes renderable entities (and associated scene information) and renders.

 

Game state management always turns into a FSM (or something even more complicated), because thats just the type of problem that has to be solved.  However, the concept of divorcing rendering from logic is totally orthogonal.

 

You can't completely separate rendering from logic, because your rendering has to know about your logic.  You can however decouple it the other way around.  For example, I have a MapMesh class that knows how to construct a mesh of the game map, along with all relevant material data.  The game map knows absolutely nothing about rendering, and the MapMesh simply takes that as a reference.

Share this post


Link to post
Share on other sites
@ Goran: That would not solve the problem, it would only postpone it. I would still have to pass the data from one object to another somehow. @ SeraphLance: I guess that will be the way I have to do it. It isn't exactly what I was hoping to achieve but it is probably as close as I can get. Thanks.

Share this post


Link to post
Share on other sites

Modularity doesn't mean "pass no data, ever", it's about barriers, and well defined data that is passed over them.

 

As SeraphLance said, you can't separate things completely; Those systems have to interact.

Share this post


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