code before scene:create

what’s the real difference between code before or within scene:create? wouldn’t it be no different to include other functions within scene:create?

I would keep scene:create for what it’s intended for - creating display objects.

Code outside scene:create should be stuff that is likely to run more than once - i.e. touch listeners, collision listeners. 

Say you have a function that updates your score display whenever points are scored, that would come above any of the composer functions. 

This is the basic structure I use for all my scenes:

[lua]


– LIBRARIES


local composer = require"composer" – import composer library


– DISPLAY GROUPS


local localGroup = display.newGroup()


– LOCAL VARIABLES


local scene = composer.newScene()

local v = {}


– OBJECT DECLARATIONS


local gfx = {}


– GAME FUNCTIONS, LISTENERS ETC.


local gameLoop = function (event)

  – THIS FUNCTION WILL RUN EVERY FRAME

end


– COMPOSER FUNCTIONS


function scene:create(event)

    localGroup = self.view

end

function scene:show(event)

    localGroup = self.view

    local phase = event.phase

    if phase == “did” then

      local previous =  composer.getSceneName( “previous” )

      if previous ~= “main” and previous then

          composer.removeScene(previous, false)

      end

      Runtime:addEventListener(“enterFrame”, gameLoop)

    end

end

function scene:hide(event)

    localGroup = self.view

    local phase = event.phase

    if phase == “did” then

      Runtime:removeEventListener(“enterFrame”, gameLoop)

    end

end

function scene:destroy(event)

    localGroup = self.view

end


scene:addEventListener(“create”, scene)

scene:addEventListener(“show”, scene)

scene:addEventListener(“hide”, scene)

scene:addEventListener(“destroy”, scene)

return scene

[/lua]

cheers! some of the tutorials I have looked at though put the touch and collision listeners in scene:create.

There are two things to consider (well three).

  1. Scope.

Some people put things inside scene:create() or scene:show() because it’s easier to define a local variable inside of scene:create() and have all the functions needed to access those variables contained in there.  Part of this reloading the scene, which segues to point 2.

  1. Scenes are Lua modules that get required.  When they are re-entered, things in the main chunk of the module do not get re-executed.  So if you initialize a variable outside of a scene function:

local score = 0

but you change that value, then reload the module, score will be what it was, not reset to 0.  Its this reason that many people find it easier to remove the scene and re-create it every time they need to re-enter the scene. 

For me, I rarely put functions inside of my scene:create() or scene:show() functions (though in a game I’m working on now, I do have a couple of functions there).  I put them outside of the functions and I reset my variables inside of scene:show()'s “will” phase, to move things back to their starting locations.

The third thing, which may be the best practice is to actually add your functions and variables to the scene object.  That way they can live outside of the scene:create() function but be scoped where it can be seen in both scene:create() and scene:show().

function scene.spawnMonster()

end

scene.score = 0

for instance.  Then inside of scene:show() you can then do:

self.spawnMonster()

self.score = self.score + 10

etc.

Rob

I would keep scene:create for what it’s intended for - creating display objects.

Code outside scene:create should be stuff that is likely to run more than once - i.e. touch listeners, collision listeners. 

Say you have a function that updates your score display whenever points are scored, that would come above any of the composer functions. 

This is the basic structure I use for all my scenes:

[lua]


– LIBRARIES


local composer = require"composer" – import composer library


– DISPLAY GROUPS


local localGroup = display.newGroup()


– LOCAL VARIABLES


local scene = composer.newScene()

local v = {}


– OBJECT DECLARATIONS


local gfx = {}


– GAME FUNCTIONS, LISTENERS ETC.


local gameLoop = function (event)

  – THIS FUNCTION WILL RUN EVERY FRAME

end


– COMPOSER FUNCTIONS


function scene:create(event)

    localGroup = self.view

end

function scene:show(event)

    localGroup = self.view

    local phase = event.phase

    if phase == “did” then

      local previous =  composer.getSceneName( “previous” )

      if previous ~= “main” and previous then

          composer.removeScene(previous, false)

      end

      Runtime:addEventListener(“enterFrame”, gameLoop)

    end

end

function scene:hide(event)

    localGroup = self.view

    local phase = event.phase

    if phase == “did” then

      Runtime:removeEventListener(“enterFrame”, gameLoop)

    end

end

function scene:destroy(event)

    localGroup = self.view

end


scene:addEventListener(“create”, scene)

scene:addEventListener(“show”, scene)

scene:addEventListener(“hide”, scene)

scene:addEventListener(“destroy”, scene)

return scene

[/lua]

cheers! some of the tutorials I have looked at though put the touch and collision listeners in scene:create.

There are two things to consider (well three).

  1. Scope.

Some people put things inside scene:create() or scene:show() because it’s easier to define a local variable inside of scene:create() and have all the functions needed to access those variables contained in there.  Part of this reloading the scene, which segues to point 2.

  1. Scenes are Lua modules that get required.  When they are re-entered, things in the main chunk of the module do not get re-executed.  So if you initialize a variable outside of a scene function:

local score = 0

but you change that value, then reload the module, score will be what it was, not reset to 0.  Its this reason that many people find it easier to remove the scene and re-create it every time they need to re-enter the scene. 

For me, I rarely put functions inside of my scene:create() or scene:show() functions (though in a game I’m working on now, I do have a couple of functions there).  I put them outside of the functions and I reset my variables inside of scene:show()'s “will” phase, to move things back to their starting locations.

The third thing, which may be the best practice is to actually add your functions and variables to the scene object.  That way they can live outside of the scene:create() function but be scoped where it can be seen in both scene:create() and scene:show().

function scene.spawnMonster()

end

scene.score = 0

for instance.  Then inside of scene:show() you can then do:

self.spawnMonster()

self.score = self.score + 10

etc.

Rob