Step of scenes

[Pin-Hua Tien]

Hi, I found that step of each active scene is running in order.

For example, there are 2 active scenes -- sceneA, sceneB

sceneA.events.emit('preupdate')

sceneA.events.emit('update')

sceneA.update()

sceneA.events.emut('postupdate') 

sceneB.events.emit('preupdate')

sceneB.events.emit('update')

sceneB.update()

sceneB.events.emut('postupdate')

It seems that game objects in sceneB only could see the final status of game objects in sceneA, not the status of previous state.

Is it possible to run step in this order?

sceneA.events.emit('preupdate')
sceneB.events.emit('preupdate')
sceneA.events.emit('update')
sceneB.events.emit('update')
sceneA.update()
sceneB.update()
sceneA.events.emut('postupdate')
sceneB.events.emut('postupdate')

[Richard Davey]

Hi,

Yes, good point. However, even in your modified version objects in SceneB will still only see the final state of objects in SceneA, and not the other way around (because the postUpdate in SceneB could well change something that sceneA didn't notice when it ran its own update)

If you have an object in SceneA that really needs to do something based on an activity in SceneB then you could have it listen for the SceneB events and update itself? Depending on what you want to happen depends how workable this is, but for anything outside of Arcade Physics it should be perfectly fine.

Cheers,

Rich

Photon Storm Ltd.

http://www.photonstorm.com

Skype: richard.davey

Twitter: @photonstorm

Registered in England and Wales.

Company ID: 8036404

VAT Number: 136 4333 27

--
You received this message because you are subscribed to the Google Groups "Phaser 3 Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phaser3-dev+unsubscribe@googlegroups.com.
To post to this group, send email to phase...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/phaser3-dev/a859fb84-4050-4efb-90be-0757c9d059ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pin-Hua Tien]

Sorry, I might not explain clearly about "the status of previous state".

sceneA.events.emit('preupdate')
sceneB.events.emit('preupdate')

// now game objects of sceneA could get the status of all game objects in all scenes after 'preupdate' event

sceneA.events.emit('update')
sceneB.events.emit('update')

// now game objects of sceneA could get the status of all game objects in all scenes after 'update' event
sceneA.update()
sceneB.update()

// now game objects of sceneA could get the status of all game objects in all scenes after scene.update()

sceneA.events.emut('postupdate')
sceneB.events.emut('postupdate')

For example, to slow down and change the direction of the game object which has the fastest speed. I could -
1. calculate speed of all game objects during 'preupdate' event in each scene
2. in 'update' event, or scene.update() function, I could get the fastest game object then change it. Do nothing if fastest game object is not in current scene.

But this flow is harder to implement if step is running in this order

sceneA.events.emit('preupdate')

sceneA.events.emit('update')

sceneA.update()

sceneA.events.emut('postupdate') 

sceneB.events.emit('preupdate')

sceneB.events.emit('update')

sceneB.update()

sceneB.events.emut('postupdate')

P.S. Put all related game objects in a scene is another way to solve it.

[Richard Davey]

It's probably worth mentioning that Scenes actually step in the reverse order. If you had SceneA, B, and C they'd actually update like this:

SceneC

SceneB

SceneA

This doesn't solve the issue of splitting the events up, but it does mean that in common cases where the top scenes are likely to be things like UI layers, or in-game modals, those events get processed first before it gets to the game scenes beneath them.

You can also do something like this in SceneA:

var sceneC = this.scene.get('SceneC');

sceneC.sys.events.on('preupdate', this.updateLocal);

Which would allow you to feed the results of a change in SceneC into SceneA before it updates itself.

The reason I wouldn't like to step each scene piece by piece is that I'd need to iterate all scenes 4x more often than we do currently. Although to be honest, part of me thinks that wouldn't be too bad, because you aren't likely to ever have that many active Scenes at once in reality.

Anyone else care to comment on this? It could be changed relatively easily and wouldn't impact the public API to do so.

Cheers,

Rich

Photon Storm Ltd.

http://www.photonstorm.com

Skype: richard.davey

Twitter: @photonstorm

Registered in England and Wales.

Company ID: 8036404

VAT Number: 136 4333 27

--

You received this message because you are subscribed to the Google Groups "Phaser 3 Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phaser3-dev+unsubscribe@googlegroups.com.
To post to this group, send email to phase...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/phaser3-dev/7688c103-5fdf-430c-a303-5d90965d76a6%40googlegroups.com.

[Chris Andrew]

Would it be overkill to make something like that configurable? I like the sound of it, but I'm also absolutely fine with the event driven approach given that it's covered in an example or documentation.

To unsubscribe from this group and stop receiving emails from it, send an email to phaser3-dev...@googlegroups.com.

To post to this group, send email to phase...@googlegroups.com.

[Richard Davey]

While we could offer it as a config option we'd then have constant branching (as it picks which method you wanted), added on top of the iteration that already exists.

Photon Storm Ltd.

http://www.photonstorm.com

Skype: richard.davey

Twitter: @photonstorm

Registered in England and Wales.

Company ID: 8036404

VAT Number: 136 4333 27

To unsubscribe from this group and stop receiving emails from it, send an email to phaser3-dev+unsubscribe@googlegroups.com.

To post to this group, send email to phase...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/phaser3-dev/39d0eacc-b9a3-41fc-9d23-011448b8c8f9%40googlegroups.com.

[Chris Andrew]

Ah, if you use an if statement to check a value. You could potentially just swap the function (on a setter call) that updates each scene, but perhaps that's a bit convoluted.

I personally wouldn't worry about the performance implications of Pin-Hua Tien's proposed order though, as you say yourself, it doesn't seem realistic for a game to need very many scenes. :)

[Richard Davey]

To be honest I'm happy to wait and see what the consensus is on this after launch.

3.0.0 isn't the end goal, it's the starting line really. We can change whatever we want as long as the community deems it sensible and we do it carefully.

Photon Storm Ltd.

http://www.photonstorm.com

Skype: richard.davey

Twitter: @photonstorm

Registered in England and Wales.

Company ID: 8036404

VAT Number: 136 4333 27

To unsubscribe from this group and stop receiving emails from it, send an email to phaser3-dev+unsubscribe@googlegroups.com.

To post to this group, send email to phase...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/phaser3-dev/d6289020-c620-4821-8d6d-c1b8b820a5c5%40googlegroups.com.