Cyclic dependencies

[Laurens]

Hi guys,

 

It's been a while for me. Recently finished my internship and can finally dedicate some time to Leadwerks again It's great to see how much this place has evolved in just a few months and the GDC demo was absolutely stunning!

 

Anyway, I will get to point

 

I am currently working on a class diagram for my Breakout clone, the game state management part to be precise. I read several articles regarding game state management (http://creators.xna.com/en-US/samples/gamestatemanagement, http://gamedevgeek.com/tutorials/managing-game-states-in-c/ and http://www.codeproject.com/KB/architecture/statepattern3.aspx) and found they all have cyclic dependencies.

 

For those of you not familiar with these articles, a quick explanation is in order. There is a StateManager and an abstract State, from which all other states (such as an IntroState or a GameState) derive. The StateManager obviously has references to a State but the State also has a reference to the StateManager so that they can push new states onto the stack themselves.

 

A this point my college professor starts to reverb in my head.

 

Cyclic dependencies are bad design!

Cyclic dependencies are bad design!

Cyclic dependencies are bad design!

 

I was wondering what you guys think of cyclic dependency in a state manager.

 

I though of a few ways around the issue as well:

 

1) Make the StateManager accessible through the GameEngine class or some sort, then push new states on the stack from a state using GameEngine::stateManager->push(new GameState()). I don't feel this is very OO. It feels more like a dirty hack.

 

2) Create a derived StateImplementation class that derives from State. Let the State have the reference to StateManager and let the StateManager have a stack of StateImplementation. Then derive other screens (IntroScreen, GameScreen) from StateImplementation. This would break the cyclic dependency but it would be the only purpose of the class and does not feel very clean either.

 

Thanks!

[Canardia]

You can do a state manager with a simple global variable:

int gamestate=0;

And then use if() statements in the main loop to do different "states" according to that variable.

 

Then you can also combine it with a level manager:

int gamelevel=0;

And make each state act differently based on the current game level.

[Laurens]

I thought of that before but the problem is that you can get a gigantic source file when the game grows larger, which is why I opted for the solution above. In practice it works fine really, I just dislike the fact it has a cyclic dependency. If this is a standard practice for this kind of problem however then "Cyclic dependency is bad design" is not as black and white as I think it is.

[Canardia]

"Good" coding style is not absolute. For beginners of programming a good coding style (and language) is different than a good coding style for game developers and also different for system developers.

 

For me good coding style is what executes fastest on the CPU, but that's not always the best option, as sometimes what is coded fastest or cheapest is higher priority, or sometimes what is generating the smallest code (but not fastest).

[Laurens]

Agreed. Although I feel this is more of a design issue than a coding style. What are other people doing in this situation?

 

Cheers!

[Canardia]

If you're not sure about something, then try it. If it works, then use it. Working means also that it's stable and performing well, and fulfills any other criterias you value.