Question: can I perform the same thing but with a delay?
I know there are different variations of Scheduler.schedule() functions, but they all require something like an object.
I assume using a thread sleep in a task given to Scheduler.performFunctionInCocosThread() will block the UI thread.
The reason for asking for a delay is that sometimes I need to perform some game logic in the future.
The reason for it to be done in Cocos2d thread is that I want it to be in the message queue rather than a worker thread so to avoid possible multi-threading issues.
The reason for without having a Cocos2d object is that let’s say I use the current running scene as the object, then the delayed logic will not be performed if a scene switch happens before the delay is completed.
My question require that “without using an object”. Are you talking about an update() function outside any object?
Otherwise, the assumption of having a update(dt) method assumes there is an object long lived throughout the whole delayed execution process (which sometimes is not true, e.g. when scene transits).
I don’t think there’s a single way people do it - it is up to personal taste somewhat, and also up to the particular game.
I am a fan of calculating everything required, then rendering it - so my logic is executed each frame.
Each entity tends to have its own logic - so a ‘chasing baddy’ entity would have a method which calculates the direction it needs to move to get to the Player, and so at the end of the update() method its now location, rotation, etc. is calculated.
Finally it updates its sprite.
The overall game logic I have in a GameController class which is instantiated instead of the HelloWorld layer in the default application - this controller is responsible for creating everything and setting the game going, handling pausing etc.
It is my GameController’s update() method that calls most of the other classes ‘update()’ methods too - so I have a guaranteed sequence of updates being run (e.g. I need my player to update first then other entities can update )
Quoting one of your earlier answers to another question of mine, I guess that you are talking about having a custom class with an update() function, then schedule that update function with the scheduler, and thus the update function will be called periodically. Is that what you meant?
Then it means I should make sure the object lives across the time range of delayed execution (which is doable).
That’s what I do, anyway! Not saying it’s the best way, but by having my Controller as a singleton that controls everything, and exists throughout, works for me.
(being a singleton means I can access its methods from any class using GameController::getInstance()->someMethod();
Though I know some would argue that Singleton’s are bad, and might prefer IOC or some other pattern, I believe this case is a good one for the pattern (& I’m not a good enough C++ programmer to know alternate ways!)
Thank you so much for your reply, @Maxxx. I think it makes sense. Since the game controller is the central piece, I think it’s fine to use singleton here.