Storyboard integration question.

[richard9]

Here’s how deletion works:

1. Storyboard tries to keep your scene exactly as you left it, if you return later. (That is, the scene is held as is) The only thing it can’t stop are timing objects (listeners, transitions, timers, etc)

a. You should manually remove things you don’t want when you come back. When you come back enterScene will be fired again, so stuff like bullets firing, that sort of thing.

b. You should manually remove things that are not safe for storyboard to remove. Runtime listeners, timers, and so on) Turn them on in enterScene, turn them off in exitScene. Easy-peasy. (Assume that the best storyboard can do is display.remove(object); object = nil

c. Generally you should only care about removing display objects (which Storyboard can do, most of the time) and variables/tables that you don’t want to stick around. There’s no point in niling out functions or setup code or requires unless you have a really good reason to do it.

2. If you manually purgeScene or destroyScene, storyboard will either destroy the scene object (purge) or remove the entire lua file (destroy) - well, destroy isn’t accurate, you can still call the file again later.

3. If you run low on memory or iOS decides it wants to for some reason, storyboard will run purgeScene. (Maybe you load up Infinity Blade, and it takes up all of your memory, that sort of thing)

[import]uid: 41884 topic_id: 35395 reply_id: 141422[/import]

[Aidin]

Thanks richard9, again for your thorough explanation.

I’m replying your last answer with numbers and alphabets that you used:

1- You mean that it keeps the “view” (or “scene”?) object of the scene, right? And if it’s destroyed, it will call the createScene and make it again.

A. I’m sorry, didn’t get you there.

B. I think I got you.

C. What do you mean there? Sorry, didn’t get you there either.

2. What do you mean by “destroy isn’t accurate and you can call the file later” ?

3. You didn’t answer my last question, is it okay to forward reference some local variables on top of my file and fill them later in the createScene and nil them in exitScene?

Thanks. [import]uid: 206803 topic_id: 35395 reply_id: 141460[/import]

[richard9]

Scenes

1. Everything is kept in memory when you switch scenes. You can just imagine it’s moved somewhere far offscreen.
2. If iOS or your app calls to purge the scene, the scene (yes, basically self.view) is removed as if a display.remove() call was made. This means if you try to go back to the scene after, createScene is called again. Any functions you execute outside of the scene functions are still there and NOT executed again.
3. If iOS or your app calls to destroy the scene, the entire lua module is unloaded and everything in it is lost. That means the scene, any functions or variables, etc. Revisiting a destroyed scene reloads the entire lua file from the beginning.

What to remove yourself?
Think of your scene like a level in Mario Bros. Do you want it to behave when you come back as if the game was paused, or as if the level was started over?

exitScene is where you want to do the things to (a) record important things like progress, score, etc. and (b) revert your scene from where it is to where it was, like remove all of the active bullets, return all the enemies to their start level configuration, move the player back to the beginning, and so on. And of course, it’s where you need to manually remove Runtime listeners and cancel transitions/timers.

Do I leave the rest of the lua file alone?
Yes. You shouldn’t be worried about nil’ing out functions or variables outside of the scene unless you have a good reason to know you won’t need them anymore. And it’s far more likely you’ll return to the scene later and need the lua file to still work.

“destroyScene” doesn’t delete your lua file from storage. It just removes the file from memory, meaning you would have to call it again on purpose for any of it to be accessible.

Can I forward reference?
Absolutely. Lots of people do it. This lets you access your objects in any scene too, which can be handy.

[code]local object1, object2 – ensures object1/2 are both local to this file!

function scene:enterScene(event)
object1 = {1, 2}
object2 = {3, 4}
end

function scene:exitScene(event)
if object1 then
print(object1[1], object1[2])
end
if object2 then
print(object2[1], object2[2]
end
object1 = nil
object2 = nil
end[/code] [import]uid: 41884 topic_id: 35395 reply_id: 141468[/import]

[Aidin]

Thanks for your reply.

I read and reread your posts several times but I’m afraid I still have some questions due to lack of experience working with it, so if you mind I have some more questions:

Thanks to you, I finally got it working but there are some bugs:

1. I create some objects dynamically in the game and in some conditions I delete and remove them but if game gets over, I need to go to game over screen instantly and since I don’t add these dynamically to the scene object, they still will be on the screen on the game over screen.

Since those objects register themselves upon creation to touch event and have physic bodies, what do I have to do for them? Do I have to just add them to the scene object?

And what should I do in normal cases when they are in the scene object and I want to remove them from the screen, do I have to remove them from the scene object as well?

2. My other problem lies with another objects I have that have text objects inside them. In their constructor code I have something like this for them:

 -- Text fields.  
 local levelTextField = display.newText(" " , 0, 0, native.systemFontBold, 16);  
 levelTextField.x = newMonster.x - 40  
 levelTextField.y = newMonster.y  
 levelTextField.originalX = levelTextField.x  
 levelTextField.originalY = levelTextField.y  
 levelTextField:setReferencePoint(display.TopLeftReferencePoint)  
 newMonster.levelTextField = levelTextField;  
 newMonster.levelTextField.setText = setText;  

and as you can see they register themselves inside the newMonster.

Problem is when I add the newMonster to the scene object and I change scene, the newMonster gets removed from the screen but these text objects that were inside it remain on the screen!

EDIT:
I could get it to work by adding those text fields manually:

 sceneGroup:insert(monster\_purple)  
 sceneGroup:insert(monster\_purple.levelTextField)  
 sceneGroup:insert(monster\_purple.GoalTextField)  
 sceneGroup:insert(monster\_purple.mouthTimerTextField)  

But I wanted a more feasible and object oriented way, like if I add the monster_purple, it would add all the things it has automatically. Is it possible?

3- When I test the screen transition in hybrid mode (in which you can see physic objects and sprites together), I can see that when sprites fade due to transition, their physic objects are on the screen and when transition finishes, they pop and suddenly disappear. Same thing happens when screen gets transitioned back, is it normal?

4- If I want to reload the game, can I call scene.reloadScene or I have to move to a temporary scene and transition back to current scene?

Thanks in advance. [import]uid: 206803 topic_id: 35395 reply_id: 141514[/import]

[richard9]

Apologies; I’m trying to be specific but it’s hard to do without sample code

1. Yes, that’s correct. If you don’t add those objects to the scene group (or to a displayGroup that is then part of the display group, etc.) you will have to remove them manually on either willExitScene() or exitScene().

I believe you also have to manually stop physics on exit but I don’t really have much experience using the physics library.

Anything that is part of the scene object will transition with it when you go to another scene (so fade out if you use a fade, disappear if you don’t use a transition, etc) You can display.remove() these objects yourself or via the scene object, either way is fine - ie: display.remove(myObject) is the same as display.remove(scene[34])

If you want to destroy everything connected to the scene though the fastest method is to just purgeScene() on exit.

2. This entirely depends on how you want the two objects to be joined. The way you have described is just a table reference ( a shortcut ). The two objects move completely independently. Which is fine, especially if you have some close relationship between them (ie: the text is the monster’s HP or something and you want a quick way to reference it).

If you want them to move together, you need to create a displayGroup instead and :insert() both objects into it.(Usually a lot of top-level displayObjects are groups, so you can expand later by adding health meters and so on to a simple sprite)

The problem you’re running into is that there is a difference between a table {} and a displayGroup(). They are both technically arrays, but displayGroups have special stage logic. That’s why you find the text object doesn’t behave right unless you insert it into the scene.

Best Method:

local monster = display.newGroup() monster.body = monstercode -- however you build it, display.newImage, a function, etc monster.string = textcode -- your text code, ie: display.newText

Also works, albeit differently

[code]local monster = monstercode
monster.text = textcode

local textGroup = display.newGroup()
textGroup:insert(monster.string) – now monster.string is ALSO textGroup[1]
self.view:insert(textGroup) – now all text objects in the group are part of the scene
– The monster pieces won’t move together but all of your text objects can exist and move with the scene[/code]

Usually when I build a monster I make a function like this:

[code]local function createMonster(details)
local monster = display.newGroup()
monster.hp = 100

monster.body = display.newImage(monster, “ugly.png”, 0, 0)
monster.hpDisplay = display.newText(monster, monster.hp, 0, 0)
– then set positioning of the display relative to the body

return monster
end[/code]

3. Not really sure I can help with this but a) make sure to stop/start physics yourself and b) try to use willEnter/willExit if there are timing oddities with the scene. (willEnter occurs before the scene is visible, willExit occurs before the scene is NOT visible)

4. reloadScene is the same as exit/enter I believe, but there’s no transitions. If you want it to fade-in/fade-out I think you need to use gotoScene() to another scene and then back as you suggest. [import]uid: 41884 topic_id: 35395 reply_id: 141532[/import]

[Aidin]

Thanks for the answers but would someone please answer my questions specifically that I asked in the first post of this topic?

In addition to those I have another question:

Since we are supposed to create and initialize objects and variables in createScene, then the scope of objects will be limited and other parts of code cannot see those. If I make them outside those functions, it may be against rules of Storyboard API since it will not have control over them. Tutorials that I’ve seen made everything global to solve this but we know better than that.

Thanks.

[import]uid: 206803 topic_id: 35395 reply_id: 141394[/import]

[Aidin]

To make things easier to answewr, here are my questions in numbers:

1- Since we are supposed to create and initialize objects and variables in createScene, then the scope of objects will be limited and other parts of code cannot see those. If I make them outside those functions, it may be against rules of Storyboard API since it will not have control over them. Tutorials that I’ve seen made everything global to solve this but we know better than that.

2- If we create a certain number of objects in one scene and remove all of those objects later on in that scene, do we need to still add them to the storyboard’s scene object?

3- I have some functions that help on maintaining logic of the game, like changing waves and updating HUD, what do I have to do them when I’m integrating Storyboard API ?

4- I have some timers that run some functions on occasions, like a enterFrame event listener or a timer that infinitely calls update to my HUD function, do I have to alter them?

5- What about touch event listeners, such as touch event listener, do they have to change to get incorporated inside Storyboard?

Thanks guys. [import]uid: 206803 topic_id: 35395 reply_id: 141398[/import]

[Aidin]

@rmckee282002,

Thanks, I’m actually using that skeleton code but as I mentioned in my numbered last post, I still can’t get my head around where some of my codes should go inside those events.

People did a great job explaining what Storyboard needs but as I mentioned, there are parts of my code that I’m not sure what I have to do.

It would be great if someone would kindly answer my numbered questions.

Thanks. [import]uid: 206803 topic_id: 35395 reply_id: 141401[/import]

[russm305]

Insert display objects in CreateScene, Functions in EnterScene…

http://developer.coronalabs.com/reference/index/scene-template

I believe the there are still some bugs in Storyboard so just insert your code where it says to and see what errors it spits out. Than you can work on fixing the individual problems until you have it working perfectly. Else you may post your code it will be easier for people to see what you need to put where.

ques1. Yes display objects in createScene, I believe other parts of code will see this

• If we create a certain number of objects in one scene and remove all of those objects later on in that scene, do we need to still add them to the storyboard’s scene object? No you must display.remove and set object = nil

3- I have some functions that help on maintaining logic of the game, like changing waves and updating HUD, what do I have to do them when I’m integrating Storyboard API ? Copy/paste the functions into each individual enterScene (dont forget to removeScene). Use data storage like ICE(now GGDATA) will store values between scenes

4- I have some timers that run some functions on occasions, like a enterFrame event listener or a timer that infinitely calls update to my HUD function, do I have to alter them? No, just make sure you shut them off in exitScene

5- What about touch event listeners, such as touch event listener, do they have to change to get incorporated inside Storyboard? No
[import]uid: 75779 topic_id: 35395 reply_id: 141399[/import]

[russm305]

Okay edited my reply, hope that helps [import]uid: 75779 topic_id: 35395 reply_id: 141404[/import]

[Aidin]

Thanks for the answers:

1. No they will not because it will be local to that function.

2. I don’t want them to run at the start, so I should not put them in enterScene. I have some functions that I need to call depending on certain situations. My question is does Storyboard need to know about these?

Wish we had a thorough explanation along with a complex example about Storyboard rather than trying to learn it as it’s some kind of black magic left from ancient aliens. [import]uid: 206803 topic_id: 35395 reply_id: 141410[/import]

[richard9]

1. You’re both right, sort of.
   a. Objects made in createScene are local to the scene, as you say.
   b. Objects inserted into the sceneGroup (self.view) can’t be addressed by their names but *do* exist as self.view[#] (since self.view is just a displayGroup. This scene is accessible in any of the scene functions.
   c. You can use non-index words to make this easier if you *really* need to access it:

-- inside a scene function local group = self.view group.jumptwice = display.newText(group, "hi there!")

That text object is now both group[1] and group.jumptwice.

d. You can create whatever you want inside createScene(), but it won’t be attached to anything unless you insert it into the group. This is important because if you delete a scene, go to another scene, etc. only the attached objects will behave according to the scene’s rules.

3. Storyboard doesn’t have any real magic to it (apart from a lot of hard work). It’s basically a big displayGroup that behaves on specific timing. It otherwise obeys all of the regular laws of Lua.

a. Structure is something of a personal taste thing with code in general, let alone storyboard. Generally you’ll want to have all of your functions outside (before) the scene code. That way you can try and keep your scene code clean and just executing things.

b. You only need to use scene functions that you use. The template is great, but if you don’t need exitScene for anything you can drop that code safely, for instance. I think createScene is the only one specifically required (because you need to actually “make” the scene)

c. The key thing to remember is scope. If you call a function inside a scene, that function needs to be known at that point in the code, which means either writing the function beforehand or localizing the variable first. This is the same whether or not you use storyboard. [import]uid: 41884 topic_id: 35395 reply_id: 141414[/import]

[russm305]

1. What works for me is to forward declare all my objects and functions local before the createScene, than just call them as globals whenever I need them.

3)Yes put functions in enterScene, storyBoard will not call the function until you tell it to.

@Richard good tip about putting all the functions outside the code than calling as needed, sounds better than just forward declaring [import]uid: 75779 topic_id: 35395 reply_id: 141416[/import]

[Aidin]

Thanks richard9,

Thanks for the explanations and your thorough answers:

1- What if I do some local declaration on top of my scenes and in each scene event, i.e. createScene and whatnot, just access them and call constructor on them and in the extiScene event just nullify them with assigning nil to them, is it acceptable?

(I’ve seen this behavior in Corona’s storyboard sample that comes with the simulator) [import]uid: 206803 topic_id: 35395 reply_id: 141420[/import]

[richard9]

Here’s how deletion works:

1. Storyboard tries to keep your scene exactly as you left it, if you return later. (That is, the scene is held as is) The only thing it can’t stop are timing objects (listeners, transitions, timers, etc)

a. You should manually remove things you don’t want when you come back. When you come back enterScene will be fired again, so stuff like bullets firing, that sort of thing.

b. You should manually remove things that are not safe for storyboard to remove. Runtime listeners, timers, and so on) Turn them on in enterScene, turn them off in exitScene. Easy-peasy. (Assume that the best storyboard can do is display.remove(object); object = nil

c. Generally you should only care about removing display objects (which Storyboard can do, most of the time) and variables/tables that you don’t want to stick around. There’s no point in niling out functions or setup code or requires unless you have a really good reason to do it.

2. If you manually purgeScene or destroyScene, storyboard will either destroy the scene object (purge) or remove the entire lua file (destroy) - well, destroy isn’t accurate, you can still call the file again later.

3. If you run low on memory or iOS decides it wants to for some reason, storyboard will run purgeScene. (Maybe you load up Infinity Blade, and it takes up all of your memory, that sort of thing)

[import]uid: 41884 topic_id: 35395 reply_id: 141422[/import]

[Aidin]

Thanks richard9, again for your thorough explanation.

I’m replying your last answer with numbers and alphabets that you used:

1- You mean that it keeps the “view” (or “scene”?) object of the scene, right? And if it’s destroyed, it will call the createScene and make it again.

A. I’m sorry, didn’t get you there.

B. I think I got you.

C. What do you mean there? Sorry, didn’t get you there either.

2. What do you mean by “destroy isn’t accurate and you can call the file later” ?

3. You didn’t answer my last question, is it okay to forward reference some local variables on top of my file and fill them later in the createScene and nil them in exitScene?

Thanks. [import]uid: 206803 topic_id: 35395 reply_id: 141460[/import]

[richard9]

Scenes

1. Everything is kept in memory when you switch scenes. You can just imagine it’s moved somewhere far offscreen.
2. If iOS or your app calls to purge the scene, the scene (yes, basically self.view) is removed as if a display.remove() call was made. This means if you try to go back to the scene after, createScene is called again. Any functions you execute outside of the scene functions are still there and NOT executed again.
3. If iOS or your app calls to destroy the scene, the entire lua module is unloaded and everything in it is lost. That means the scene, any functions or variables, etc. Revisiting a destroyed scene reloads the entire lua file from the beginning.

What to remove yourself?
Think of your scene like a level in Mario Bros. Do you want it to behave when you come back as if the game was paused, or as if the level was started over?

exitScene is where you want to do the things to (a) record important things like progress, score, etc. and (b) revert your scene from where it is to where it was, like remove all of the active bullets, return all the enemies to their start level configuration, move the player back to the beginning, and so on. And of course, it’s where you need to manually remove Runtime listeners and cancel transitions/timers.

Do I leave the rest of the lua file alone?
Yes. You shouldn’t be worried about nil’ing out functions or variables outside of the scene unless you have a good reason to know you won’t need them anymore. And it’s far more likely you’ll return to the scene later and need the lua file to still work.

“destroyScene” doesn’t delete your lua file from storage. It just removes the file from memory, meaning you would have to call it again on purpose for any of it to be accessible.

Can I forward reference?
Absolutely. Lots of people do it. This lets you access your objects in any scene too, which can be handy.

[code]local object1, object2 – ensures object1/2 are both local to this file!

function scene:enterScene(event)
object1 = {1, 2}
object2 = {3, 4}
end

function scene:exitScene(event)
if object1 then
print(object1[1], object1[2])
end
if object2 then
print(object2[1], object2[2]
end
object1 = nil
object2 = nil
end[/code] [import]uid: 41884 topic_id: 35395 reply_id: 141468[/import]

[Aidin]

Thanks for your reply.

I read and reread your posts several times but I’m afraid I still have some questions due to lack of experience working with it, so if you mind I have some more questions:

Thanks to you, I finally got it working but there are some bugs:

1. I create some objects dynamically in the game and in some conditions I delete and remove them but if game gets over, I need to go to game over screen instantly and since I don’t add these dynamically to the scene object, they still will be on the screen on the game over screen.

Since those objects register themselves upon creation to touch event and have physic bodies, what do I have to do for them? Do I have to just add them to the scene object?

And what should I do in normal cases when they are in the scene object and I want to remove them from the screen, do I have to remove them from the scene object as well?

2. My other problem lies with another objects I have that have text objects inside them. In their constructor code I have something like this for them:

 -- Text fields.  
 local levelTextField = display.newText(" " , 0, 0, native.systemFontBold, 16);  
 levelTextField.x = newMonster.x - 40  
 levelTextField.y = newMonster.y  
 levelTextField.originalX = levelTextField.x  
 levelTextField.originalY = levelTextField.y  
 levelTextField:setReferencePoint(display.TopLeftReferencePoint)  
 newMonster.levelTextField = levelTextField;  
 newMonster.levelTextField.setText = setText;  

and as you can see they register themselves inside the newMonster.

Problem is when I add the newMonster to the scene object and I change scene, the newMonster gets removed from the screen but these text objects that were inside it remain on the screen!

EDIT:
I could get it to work by adding those text fields manually:

 sceneGroup:insert(monster\_purple)  
 sceneGroup:insert(monster\_purple.levelTextField)  
 sceneGroup:insert(monster\_purple.GoalTextField)  
 sceneGroup:insert(monster\_purple.mouthTimerTextField)  

But I wanted a more feasible and object oriented way, like if I add the monster_purple, it would add all the things it has automatically. Is it possible?

3- When I test the screen transition in hybrid mode (in which you can see physic objects and sprites together), I can see that when sprites fade due to transition, their physic objects are on the screen and when transition finishes, they pop and suddenly disappear. Same thing happens when screen gets transitioned back, is it normal?

4- If I want to reload the game, can I call scene.reloadScene or I have to move to a temporary scene and transition back to current scene?

Thanks in advance. [import]uid: 206803 topic_id: 35395 reply_id: 141514[/import]

[richard9]

Apologies; I’m trying to be specific but it’s hard to do without sample code

1. Yes, that’s correct. If you don’t add those objects to the scene group (or to a displayGroup that is then part of the display group, etc.) you will have to remove them manually on either willExitScene() or exitScene().

I believe you also have to manually stop physics on exit but I don’t really have much experience using the physics library.

Anything that is part of the scene object will transition with it when you go to another scene (so fade out if you use a fade, disappear if you don’t use a transition, etc) You can display.remove() these objects yourself or via the scene object, either way is fine - ie: display.remove(myObject) is the same as display.remove(scene[34])

If you want to destroy everything connected to the scene though the fastest method is to just purgeScene() on exit.

2. This entirely depends on how you want the two objects to be joined. The way you have described is just a table reference ( a shortcut ). The two objects move completely independently. Which is fine, especially if you have some close relationship between them (ie: the text is the monster’s HP or something and you want a quick way to reference it).

If you want them to move together, you need to create a displayGroup instead and :insert() both objects into it.(Usually a lot of top-level displayObjects are groups, so you can expand later by adding health meters and so on to a simple sprite)

The problem you’re running into is that there is a difference between a table {} and a displayGroup(). They are both technically arrays, but displayGroups have special stage logic. That’s why you find the text object doesn’t behave right unless you insert it into the scene.

Best Method:

local monster = display.newGroup() monster.body = monstercode -- however you build it, display.newImage, a function, etc monster.string = textcode -- your text code, ie: display.newText

Also works, albeit differently

[code]local monster = monstercode
monster.text = textcode

local textGroup = display.newGroup()
textGroup:insert(monster.string) – now monster.string is ALSO textGroup[1]
self.view:insert(textGroup) – now all text objects in the group are part of the scene
– The monster pieces won’t move together but all of your text objects can exist and move with the scene[/code]

Usually when I build a monster I make a function like this:

[code]local function createMonster(details)
local monster = display.newGroup()
monster.hp = 100

monster.body = display.newImage(monster, “ugly.png”, 0, 0)
monster.hpDisplay = display.newText(monster, monster.hp, 0, 0)
– then set positioning of the display relative to the body

return monster
end[/code]

3. Not really sure I can help with this but a) make sure to stop/start physics yourself and b) try to use willEnter/willExit if there are timing oddities with the scene. (willEnter occurs before the scene is visible, willExit occurs before the scene is NOT visible)

4. reloadScene is the same as exit/enter I believe, but there’s no transitions. If you want it to fade-in/fade-out I think you need to use gotoScene() to another scene and then back as you suggest. [import]uid: 41884 topic_id: 35395 reply_id: 141532[/import]