Change to a prevous state

[robersend]

Is there a way to change to a previous state without having it call preload and create?

[Get_Bentley]

Hello,

 

I'm not entirely sure what you mean here, are you trying to call a previous state but only call the update function in the previous state?

 

If you could clarify a bit im sure it would help everyone help you out. Thank you.

[tsphillips]

Why do you want to skip preload and create?

 

You could have two copies of a state, one with preload and create defined, and the other without.  I'm not sure why one would want to do that, though.

 

Here is one basic set of states that works well for basic games:

 

- Preload State: call preload to load the assets into the cache, then call create to change to the Menu State.

- Menu State: call create to create the menu objects, one of the menu objects (for example, a button) links to a function that changes to the Play State.

- Play State: call create to create the game objects, update can have basic game logic.  When the game ends, go back to the Menu State.

 

To change states, call game.states.start("STATE_NAME").

 

All of that said, if you have a very simple game, you do not need to use different states at all.  The whole game could be in a single state.

 

Tom

[robersend]

I want to go back to a previous level but i don't want to create the enemies I had already killed there. I've managed to do it with flags, but i want to know if there's a more elegant way of doing so

[drhayes]

In a game I'm working on I store what enemies have been killed in a big object. Every enemy has a unique ID. When the map is loaded, each enemy literally checks that big object to see if they should kill themselves because the player killed them before.

[robersend]

Well, that's more or less what i said about the flags (you can't advance to the next map until you've completed the current one)

[aceofpack]

You can store the enemies in a global object which is accessible across states. For what you suggest, still sounds like you'll need a property on the enemy to say if it's dead or not

//My enemy group defined early, perhaps after game is definedgame.enemyGrp = game.add.group();//Add your permanent enemy pool at this point prior to the main game statefor (var i = enemyCount - 1; i >= 0; i--) {	var enemy = game.enemyGrp.create(PosX, PosY, 'enemy-sprite');	enemy.dead = false;};//Then kill an enemy at some point in the main game state game.enemyGrp.forEach(function(enemy){ 	//Check if they die and remove them - or just set them to dead so they can't be utilised 	enemy.dead = true; }); //Move to next state... then back again you can still loop through the existing group (unless they've been removed) since it's globally attached to the game object //You can set them all to alive again in create functiongame.enemyGrp.forEach(function(enemy){ 	enemy.dead = false });

[drhayes]

Fair enough, I didn't provide enough info. My solution's a little more complicated than "store some flags", though.

 

Enemies come in the object layer of my tilemaps. I wrote a custom webpack loader that rewrites the tilemaps object layers, looking for entities. It assigns these entities an ID that is a base64 encoded value made up of the following properties, pipe-separated: map filename, layer name, object name (its type, more or less), index in the layer. That way I can move the objects around positionally and not corrupt any players' saved games as I patch the game once it's released.

 

Each class that cares about restoring its state across saves and checkpoints call a "track" method on the Checkpoints plugin. "track" subscribes the entity's "onRestore" method to the restore signal on the checkpoints plugin and gives the object a "state" property. The entity's new "state" property is an object where it stores whatever state it cares about. This "state" property is an alias for an object in the checkpoints plugin keyed by the entity's ID assigned by the webpack loader. That way all game state is centralized but still available per entity as this nice "this.state" property that is only available to the entity.

 

That onRestore signal gets fired on player death, when moving across maps, etc. Each object that tracked itself thus can update its state based on whatever information it stored in its "state" property... aliased as this global object. Lots of objects do all kinds of semi-complicated things on restore; having the function be a part of the entity makes that pretty flexible.

 

When the player checkpoints (a save point, enters a new map) the current state is stored as the old state. If the player dies we restore the old state and throw away the current state. This gets us "put the gems back where they were when the player took them", "restore enemy to life", that kind of thing.

 

When saves happen there's an entirely different plugin that tries to put things in various places: localStorage, remote... when I package the game in Electron I'll probably stick some File writing in there to serialize the game state but it's nice to store in localStorage for easy testing on the web.

 

I like this solution because, now that I've got it right, it's completely automatic. Everything just works, even as I move maps around and release new versions. So far my beta users haven't had any problems with losing their saved games. I've also got an easy way for them to send me their saved games and I know I'll get the game back in the state they were looking at if/when something goes wrong.