Jump to content
  • Advertisement

Wurstinator

Member
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

105 Neutral

About Wurstinator

  • Rank
    Newbie
  1. Wurstinator

    Scene management

    @ 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.
  2. Wurstinator

    Scene management

    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.
  3. Wurstinator

    Scene management

    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.
  4. Wurstinator

    Scene management

    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.
  • 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!