I want to display game objects once and then call them in different scenes.I don’t have any idea about this that’s why I haven’t tried any code.I have read storyboard to composer migration api but I didn’t get anything.
I want to display game objects once and then call them in different scenes.I don’t have any idea about this that’s why I haven’t tried any code.I have read storyboard to composer migration api but I didn’t get anything.
This is really a question about well structured code and code reuse. If you are properly implementing composer scenes (much preferred over storyboard for a new project) you really should not be creating game objects and using them in multiple scenes.
Create a lua file which can return an object, for example a character, with a collection of parameters to define the object’s state. Check out the API document for good examples. One of those parameters should be the parent display group. Other parameters will include where on the screen the object is and so on.
Ideally, you would set up everything for your scene in either the create() event or the “will” phase of the show() event. Later, you will remove them all in the “did” phase of the hide() event or the destroy() event. Which you choose will depend on whether the objects really can be reused between multiple calls of that scene or that they should all be removed completely. Note: If you are creating physics bodies for the scene you will want to completely remove them and recreate in the “will” phase of show() because they are well known for being difficult to place back to their original location.
The purpose of creating lua files which let you call one function to create your objects is simple code reuse. I recommend a code layout like this…
-- main game character library local colourlib = require("colours.lua") local lib = {} local function newMainCharacter( parent, x, y, shirtColour ) local group = display.newGroup() parent:insert( group ) group.name = "main character" -- do other stuff here return group end lib.newMainCharacter = newMainCharacter return lib
You would load this module as any lua module is loaded and then call the newMainCharacter() function, passing in the scene-specific parameters. Of course, the scene’s own .view display group would be the first parameter for this example.
This is really a question about well structured code and code reuse. If you are properly implementing composer scenes (much preferred over storyboard for a new project) you really should not be creating game objects and using them in multiple scenes.
Create a lua file which can return an object, for example a character, with a collection of parameters to define the object’s state. Check out the API document for good examples. One of those parameters should be the parent display group. Other parameters will include where on the screen the object is and so on.
Ideally, you would set up everything for your scene in either the create() event or the “will” phase of the show() event. Later, you will remove them all in the “did” phase of the hide() event or the destroy() event. Which you choose will depend on whether the objects really can be reused between multiple calls of that scene or that they should all be removed completely. Note: If you are creating physics bodies for the scene you will want to completely remove them and recreate in the “will” phase of show() because they are well known for being difficult to place back to their original location.
The purpose of creating lua files which let you call one function to create your objects is simple code reuse. I recommend a code layout like this…
-- main game character library local colourlib = require("colours.lua") local lib = {} local function newMainCharacter( parent, x, y, shirtColour ) local group = display.newGroup() parent:insert( group ) group.name = "main character" -- do other stuff here return group end lib.newMainCharacter = newMainCharacter return lib
You would load this module as any lua module is loaded and then call the newMainCharacter() function, passing in the scene-specific parameters. Of course, the scene’s own .view display group would be the first parameter for this example.