Game loop design decision

I have a simple game loop.
1
2
3
4
5
6
7
8
while(true)
{
	//round initialisation stuff
	while(true)
	{
		//capture input, make pieces move, blah blah
	}
}

I am faced with the decision of what is the best way of restarting the game. The problem is, the condition for restarting a game is very, very deep inside the game's logic. So returning returning... is not an option, or at least, it ain't gonna be pretty.

So one of my considerations is to use a goto label, like so:
1
2
3
4
5
6
7
8
9
while(true)
{
	//round initialisation stuff
	while(true)
	{
		//capture input, make pieces move, blah blah
	}
	restart_round:
}

This seems to be the cleanest solution, since it allows me to fully reset the 'state' of the round, by first having all the destructors(pertaining to the round's objects) called, and then the constructors and other initialisation stuff.

Are there any subtleties that I am missing regarding this solution? Are there any clean alternatives that could be suggested?

Obviously, I will need to document this behaviour well since it is not typical. Lastly, I kindly ask to stay on topic, I do not want to start a goto(good^evil) debate :)
How about

1
2
3
4
5
6
7
8
9
while(true)
{
	//round initialisation stuff
        restart_round = true;
	while(restart_round)
	{
		//capture input, make pieces move, blah blah
	}
}

These nested loops shouldn't be in the same function anyway (it's poor design because you will eventually get a very long function), so you will be able to easily return from the 'inner' function to the 'outer' function.
Can we see any actual code? I agree that this sounds like an overall design issue.
@L B

Maybe I did not make it entirely clear. The nesting is not part of the game loop function per se. It is implemented in different classes, most of the logic lies in decentralised classes interacting with each other. The game loop is very high-level, it just triggers code that is implemented somewhere else. So what I meant by "deep" is, the logic lies deep inside the function of a function of some class. Even if I restructure the loop as you suggest, I still need a clean way of restarting the system from a far away class.

Is that more clear?
Last edited on
That also sounds like a design problem. Why is deep code responsible for making a decision that affects things at the shallow level?
Well, in every other case it is not responsible for making decision at a "shallow" level. But there is a particular scenario, when one piece is placed on top of another, the game needs to restart. So, I have behaviour of pieces(one stacking on another) that affect the game loop(resetting the round). I am open to other suggestions, if you can think of an alternative way of achieving this(reset)?
Last edited on
At the shallow level is there not a way to detect that two pieces have the same position? Or, alternatively, is there not a way to detect that he player has tried to place one piece onto the other? Player interaction is generally handled at the shallow level anyway.
At the moment I have the minimal amount of knowledge shared between classes. That being said, there is a way for the gameloop to find this out, but it is not pretty, and it is rather convoluted. This is why I tried to come up with an alternative solution.
On what condition does the game loop run? Surely it asks the next level down whether the game is over?
Last edited on
It runs forever.
Yea, I think you just pointed out the crux of the problem[facepalm]. I will need to fix that, I suspect that when I do, it would be easy to see if the game needs to restart or not. I am marking this as solved.

Thanks.
Topic archived. No new replies allowed.