LibGDX restarting game and static variables

Newbie & Debugging Questions
#1

In my pirate game, if there’s a game over or a win, I create a new instance of the game, but I have a quick question. I don’t think I’m doing it correctly, and I’ll post code if needed, but the question is this: If I create a whole new instance of the game, should static variables be reset? Because how I have it right now, they do not. Basically, my createNewGame method consists of disposing of everything, then re-instantiating the whole thing.

So basically, here’s my game loop:

private void gameLoop() {
	inputHandler.handleInput(this);
	audioHandler.handleAudio(this);

	if (GamePlayHelper.gameOver) {
		setUpNewGame();
	}
}

The last thing that setUpNewGame() does is call the create() method. Is that supposed to reset all the static variables too? I feel like I have to be doing this incorrectly, unless I actually do have to reset every single static variable manually, which I don’t understand if I’m creating a whole new instance of the game.

Class variables are reset correctly, but MOST of those are set in the constructor, but not all of them.

The code for the whole “myGame” file (not too big) is here

The imageLoader is not disposed of because for some reason if I do, the ground tiles don’t render.

#2

static variables live outside the livecycle of an instance and therefore are not reset. they are managed in scope of the class. best would be to avoid static variables completely and pass around a GameContext instance with that values as member variables.

1 Like
#3

Ok sweet! But, why don’t they get reset? How does program 1 keep set static variables when I reset to program 2? Does java just keep those in the memory in my computer? I guess I don’t understand why their not reset upon a new instance. If they’re managed within the scope of a class, why are they not reset when I create a whole new instance of the game? if game over (create a new instance). How is this different than killing the game and restarting it?

#4

a class is only the concept of an instance - similar to a blueprint. an instance of a class is a concrete manifestation of that concept. when the jvm is started with a jar, it loads the classes that your app is made of. this is the time when also the static variables are initialized. this is before an instance of a class is created. when you create an instance, the member variables are initialized. the static variables are not touched here and are in reality not part of the instance, but only of the class. this is the reason why all instances of a class share the same values for static variables and why values written to them from one instance can be seen in other instances. when you create a completely new instance of a class, in reality you are just creating another copy based on that blueprint and you will still see all the static variables like in the first one, since they are not copied to the new instance, but still are the same memory locations in the class definition itself.

1 Like
#5

Ok that makes sense. But two more follow up questions: 1. Why, when creating a new instance of the game, it doesn’t wipe EVERYTHING out and restart it how the program is written in the first place? Shouldn’t that wipe out all the memory of the current game instance and start another one? I guess I dont understand why the static variable values are kept in memory if I dispose of everything and start a new game. If I say:

if (gameOver) {
disposeOfEverything();
Re-instate new Game();
runNewGame();
}

this doesn’t wipe the memory of the static variables and reset them to their inital values?

Also, question 2: ( I haven’t really tried yet), but if I set these static variables in the constructor of said classes, it should work correctly right?

#6

with new, you create a new instance. an instance is not a new memory allocation of a class, but a new memory allocation of an object that is constructed based on the blueprint of that class. since static variables are part of the class itself, they live in the memory that is allocated for the class once the class definition is loaded by the jvm’s classloader.

if you set the static variables in the constructor, they would be reset for each new instance, yes. but this is usually a very bad habit, since nobody would expect this. you can get away with it for something like a singleton game instance, but it will bite you, if you make this a habit for other things as well.

best would be to avoid static completely, design the dependencies of you components carefully and just pass in the instances you need to access in the constructors of your objects.

1 Like
#7

Awesome answer, thank you! For the most part I really really tried to avoid static variables, but had to use them for certain things. Thanks for the advice on not setting them in the constructor either.