Game loop design decision

Sep 30, 2013 at 5:13pm
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 :)
Sep 30, 2013 at 5:51pm
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
	}
}

Sep 30, 2013 at 5:57pm
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.
Sep 30, 2013 at 6:04pm
Can we see any actual code? I agree that this sounds like an overall design issue.
Sep 30, 2013 at 6:09pm
@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 Sep 30, 2013 at 6:15pm
Sep 30, 2013 at 7:09pm
That also sounds like a design problem. Why is deep code responsible for making a decision that affects things at the shallow level?
Sep 30, 2013 at 7:31pm
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 Sep 30, 2013 at 7:31pm
Sep 30, 2013 at 7:32pm
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.
Sep 30, 2013 at 7:40pm
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.
Sep 30, 2013 at 7:44pm
On what condition does the game loop run? Surely it asks the next level down whether the game is over?
Last edited on Sep 30, 2013 at 7:44pm
Sep 30, 2013 at 7:52pm
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.