C++: Advice for creating a 'screen' and 'object' system

[tom64]

Hi all, I am thinking to create a system for screens and objects.

Screens are just the pages in the application. eg. When the app loads you see the 'welcome' screen, then after that you see the 'menu' screen.

Objects are just things that store data and do stuff which you put inside your screen.

Now, I'm guessing both screens and objects will be 'classes'. The screen class will get details about its size, color, etc.

After creating the objects (which is just a blueprint), I would then 'add' the object to a particular screen. Then when the screen loads by gotoScreen(screenName) the screen would create instances of those objects and those objects would begin to do stuff.

How I might do it: I'm thinking maybe a linked-list in the screen class that stores what objects that screen will need to create. But how do I do that? Do I need to pass a pointer of the object to the linked list? And then how would the screen class then use that pointer to 'create' an instance of that object?

And then if say I wanted to 'clear' the screen after I go to the next screen (deleting all of the object-instances/data/etc being used by the previous screen - except the blueprints of course - as I may want to load that screen again), how do I do that??

Objects are also capable of 'creating' instances of objects as well as new variables that allocate memory. Those would also need to be destroyed when the screen gets cleared.

Any advice on the best way to go about this?

Thanks,
Tom.

[eXpl0it3r]

To me it sounds, like you don't have a good grasp of OOP in general and thus I really suggest to read up on the topic with a good book, it's not an easy topic, but it's one of the basis of C++ and thus very important to have a good understanding of it.

There are also heaps of tutorials and articles about "Screens" and "Objects", but they are also often called "States" and "Entities". Based on a SDL tutorial, I've written a SmallGameEngine, which should demonstrate how one could handle different states. Then there's also a nice tutorial on SFML's wiki.

Once you got a good understanding on OOP and more importantly how classes work in C++, it will be much easier to understand how to go about Entity systems.

[tom64]

But I do understand OOP. I just don't understand the syntax to store objects in the list and have that list/screen-class then 'create' that object as an instance, and then how to safely destroy everything.

Surely it can't be that hard..

[Eritey]

But I do understand OOP. I just don't understand the syntax to store objects in the list and have that list/screen-class then 'create' that object as an instance, and then how to safely destroy everything.

Surely it can't be that hard..

It may not be hard to do but it'd require a lot of explaining and code examples which many people don't have the time to provide.

After reading the OP, I might be wrong with this, I believe you want to create a state manager like system to handle changing from state to state. The one that eXpl0it3r created and linked in his post is a perfect example. You have a superclass that will contain all the methods and variables required for each state. Such as, draw, update, init etc.

You then can create child classes of the superclass and create override methods of each method you might require. Inside these child classes would be information related to each state, entites, logic etc.

You could then do for example.

MainGame game;
MainMenu menu;

statemanager.addState(game);
statemanager.addState(menu);

stateManager.changeState(GameState::type::MainGame);
 

I'm no where near the best C++ programmer on this website but I hope my explanation helps you understand what you need to create. If it still doesn't, go look at the example eXpl0it3r posted.

[eXpl0it3r]

But I do understand OOP. I just don't understand the syntax to store objects in the list and have that list/screen-class then 'create' that object as an instance, and then how to safely destroy everything.

Surely it can't be that hard..

If you wouldn't just ignore essential parts of my post, then you'd have checkout the given link and would've noticed, that I was also referring to classes in general. STL containers are really not that hard to understand with the right book at hand.

[tom64]

If you wouldn't just ignore essential parts of my post, then you'd have checkout the given link and would've noticed, that I was also referring to classes in general. STL containers are really not that hard to understand with the right book at hand.

I did check those links out. I appreciate your help. Though I have little idea what 'STL container' is.

You could then do for example.

MainGame game;
MainMenu menu;

statemanager.addState(game);
statemanager.addState(menu);

stateManager.changeState(GameState::type::MainGame);

I was thinking something more like:

screen_create(name,size,color,etc)
object_create(name,etc,...)
place_object_in_screen(objectname,screenname,x,y)
etc.

[Eritey]

Not really sure why you'd want to do that but its possible, it might be;

   

        GameState screenCreate(sf::String, sf::Vector2f size, sf::color)
        {
                newState = gamestate;

                newState.setTitle(String);
                newState.setSize(size);
                newState.setcolour(colour);

                return newstate;
        }

        Entity newEntity((sf::String, sf::Vector2f size, sf::color)
        {
                newEntity = Entity;

                newEntity.setTitle(String);
                newEntity.setSize(size);
                newEntity.setcolour(colour);
        }

        GameState::addEntity(Entity newEntity)
        {
                entityList.push_front(newEntity));
        }

        gamestate tempState = screenCreate("New Window", sf::vector2f(100,100), sf::colour:green);

        entity tempEntity = newEntity("New Entity", sf::vector2f(50,50), sf::colour::orange);

        tempState.addEntity(tempEntity);
       

Is that what you'd want too do?

Inside each gameState might be this;

std::list<Entity*> entityList;

[tom64]

Basically yeah, just I would make it a bit more simpler, for retards like myself. 

[The Terminator]

I'm gonna go ahead and talk from experience here. All of my games run exploiter's engine, it is fast and easy to understand. It's easily modifiable and will pretty much fit your every need. I would highly suggest reading through his code, then try to make a few example games with it. It sounds to me that you're wanting to rush into game development and not learn proper c++. I find it hard to believe you're trying to get into engines and state managers without even knowing want STL is. Anyways, [/rant] Read through the link of books, or check out some YouTube videos of STL containers.

[Eritey]

Basically yeah, just I would make it a bit more simpler, for retards like myself. 

I don't you can make it any more simple than it already is, that is a very very basic example.

[tom64]

Oh no, I definitely don't want to use someone else's code to do this. I believe I can do this myself. I was just curious what opinions/techniques/ideas others might have.

I'm totally okay to make stuff from scratch. I'm relatively new to C++, but I think I know about 90-95% of it. I'm just a little unsure about instances/pointers/etc. But I should be able to manage.

[FRex]

I'm relatively new to C++, but I think I know about 90-95% of it.

This is the dumbest thing I seen all day, maybe even all week.

[Eritey]

I'm relatively new to C++, but I think I know about 90-95% of it.

The amount of questions you've asked this week proves this statement is incorrect.

[tom64]

 

[Eritey]

Instead of attempting something large like the project you have in-mind, why don't you start off small? Create an entity class, play around with it and understand how C++ does then. Then from there you will have enough knowledge to approach the idea in your OP.