2

I have tried to design a class diagram for my first game. But then I realized that there are some ugly parts.

First, there is reference from StateSystem to State and from State to StateSystem. The StateSystem object contains references to State instances and one of them is always current. StateSystem calls it's update and render functions. But every instance of State also has to have a reference back to StateSystem, so it can change state to another one. I'd like to know how to avoid the circular dependence in this case.

Secondly, I don’t know where to hold reference(s) to the Input object. Generally, all classes which belong to the UI (green classes) need a reference to the same instance (only existing instance) of Input due to mouse collision detection. Input contains stored information about pressed keys, mouse coordinates and so on. Should I store the reference in every object that needs it?

Moreover, what about TextureManager class? The only thing it does is store Texture instances via string IDs (and preparing it for OpenGL) and when needed, it returns a texture according to a given ID. Should I consider using, for example, the Builder pattern and let only the "director" object own the texture manager and create concrete textures for objects?

Improve this question
5
  • There's a couple ways to idealogically break the cycle. You can decide that "State" is completely passive and only "StateSystem" can modify it. Therefore, "State" has no outgoing references. Alternatively, you can use an interface for the StateSystem, and define the few calls that State can make on the StateSystem in the interface. Whether you provide the StateSystem object or a proxy to it does not change the behavior.
    – Berin Loritsch
    Jul 8, 2019 at 20:34
  • The first option seems not to be possible for me. The "State" cannot be passive in this way, because different states change the current state in different situations. Some states contain buttons for this purpose, some states check keys etc. The dependency inversion using interface limites the usage of StateSystem to a few methods, but the reference is still here. Isn't that a problem?
    – Jarek Večeřa
    Jul 8, 2019 at 21:40
  • I don't understand the need for State objects to be in charge of changing which one of them is current. This seems to be creating your issue. What about this is important for your design?
    – JimmyJames
    Jul 9, 2019 at 20:11
  • Hmm, that's true. There is no reason to make states responsible for changing current state, because the buttons, which really decide about that, are stored deeper in structure of components, so I would unnecessarily create another circular dependences. But buttons need the power to call StateSystem.changeState, don't they? So the answer is to make something like C#'s delegate which is equal to make interface with just few methods in it as Berin Loritsch suggested.
    – Jarek Večeřa
    Jul 9, 2019 at 23:05
  • Or second option I can think of is to return the fact, that state have to be changed through return values of method update. But there is a problem, what if there were another informations, that has to be returned and second one is already mentioned nested structure, I think it would be huge mess in the code, so how do you mean that State (or Button or whatever) can by completely passive?
    – Jarek Večeřa
    Jul 9, 2019 at 23:13

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.