Scene Vs Screen ?

Getting Started Newbie Questions
#1

HI guys plz excuse my ignorance on this one I have totally confused myself over the past few days trying to sort his out.

Firstly is Scene and Screen the same thing? 

I have begun a first draft game and have a main.lua and a game.lua

On the main.lua I have a few images and a button (iOS). In the corona simulator I select run and it runs my main screen .  Im having trouble understanding what I need for code on that button so it opens the game screen. At this stage the game screen has a background only but when I press the [play game] button on the main screen nothing happens. I tell a lie the print command works that the button was pressed/released but thats all. I can’t work out how to goto the game screen after pressing the button.

Hope someone can get me past this lack of understanding moment.

david (big-db)

main.lua

 [lua] widget = require(“widget”)

widget.setTheme( “widget_theme_ios” )

require(“game”)

local composer = require( “composer” )

local scene = composer.newScene(“game”)

–Function to handle button events

local function handleButtonEvent( event )

   composer.gotoScene(“game”)

if ( “ended” == event.phase ) then

    print( “Button was pressed and released” )

 end

 end

– Create the button object

local testButton = widget.newButton

{

    left = 70,

    top = 300,

    label = “Play Game”,

    onEvent = handleButtonEvent

}

[/lua]

game.lua

 [lua]  iImage = display.newImage(“slateBG.png”) [/lua]

#2

game.lua need to be a proper composer scene if that is what you have chosen to use as your scene manager

#3

The terms can somewhat be used interchangeably. But really they probably shouldn’t be.

Think of a scene like in a movie or a TV show. Let me use Star Wars as an example. You see a portion of the movie that shows the Millenium Falcon flying through space, then the movie cuts to show Han Solo and Chewbaca inside the Millenium Falcon.  Those are two different scenes, but you watched them on the same screen.

But in a computer game or app, you’re scene will typically be a single screen of information, so it’s easy to interchange them. I’d rather screen be used to describe the physical content area.

As for your project, it’s best to not have any buttons and such in main.lua, just have it go to a menu.lua scene that has your visible UI. Then your button can go to your game.lua scene.  But as @sgs stated scene’s have to be proper scenes. I always start with the basic template.  In fact I just have a file called template.lua and copy it to each scene and then use that file to build the scene.  You can get the code for the base template scene here:

https://docs.coronalabs.com/api/library/composer/index.html#scene-template

Rob

#4

Hello Rob.

Thanks for that. The template file has given me more insight. Very much appreciate it. I can see this learning will be a slow process but if I can concentrate and work with the forum group I am sure I will have some success.

db

#5

@anon63346430

thanks for the input. Must admit I tried for a while to understand the composer manager stuff. Its a bit to deep for me early leanings. Appreciate the reply and I am sure this will not be my only call for help.

db

#6

@david874, we have a ton of resources on using Composer.  In addition to the API documentation, there is the guide:

https://docs.coronalabs.com/guide/system/composer/index.html

Then there is the Getting Started guide. Chapter 4 specifically covers converting a non-scene managed game to Composer based:

https://docs.coronalabs.com/guide/programming/index.html

It really helps to understand how display.newGroup() works since that’s really what a Composer scene object is at its core. It helps to have faith that it works if you follow the rules Composer will work. I see too many people who have objects that don’t remove working to hand remove them when the only reason is they didn’t put the object in the scene’s display group.  

Then there are four basic principles regarding scenes.

  1. Scenes need to be created if they don’t exist. If they have never been created, then they will have to be created. You need to know when your scene is requested to be built, so your scene gets an event when the scene needs to be created. You should create any display objects here that are always going to be part of the scene, the user interface, buttons on a menu scene etc. You should not start spawning enemies or start the game here since the scene can be created and cached if you desire well before you ever show it.

  2. A scene will always be shown before your users can see it. So your scene will be notified when it’s shown… twice.  Many developers will want to know before the scene is shown and others will want to know when the scene is completely on the screen. And some will care about both. So you can tell the difference, we use a member of the passed in event table called event.phase that will either be the string “will” or “did” to indicate if the scene is about to be shown (and previously created)  or the scene is completely on the screen.

The “will” phase is a good time to create your player and enemies, but don’t start them yet. If you’re restarting the scene, and it already exists, you may want to reset things like object positions, score values, etc.  The “did” phases is the appropriate time to start everything, animations, physics, timers, spawning future enemies, moving backgrounds etc. This is a good time to start the background music for the scene.  The time between the “will” and “did” phase is any time you’ve set up to transition the scene on screen.

  1. When changing scenes, the current scene will be notified… twice… that it’s in the process of hiding. Like showing a scene, there will be two calls with event.phase either being “will” and “did”. The “will” phase is the time you will cancel timers and transitions, pause or stop physics, etc.  The scene will transition over any defined transition time, and when done you will be notified with a “did” phase. There really is not a lot that you will want to do here, but if you want to remove the scene, you can do it now.

  2. Scenes can be destroyed. Generally, this will happen if you explicitly decide to remove the scene using composer.removeScene(), though a scene not showing can be removed based on settings like when memory gets low and a scene is not being shown. When a scene is removed, your scene will be notified that it’s about to be destroyed.  There really isn’t much work to do here if you’re letting Composer manage your display objects because it will remove them for you. About the only thing to do here is unload any audio that you may have loaded during a “create” event. Everything else should have already been handled.

So digest on that for a bit, look at the Composer Guide and read through the Composer chapter of the Getting Started guide and see if you have a better feel for scene management.

Rob

#7

game.lua need to be a proper composer scene if that is what you have chosen to use as your scene manager

#8

The terms can somewhat be used interchangeably. But really they probably shouldn’t be.

Think of a scene like in a movie or a TV show. Let me use Star Wars as an example. You see a portion of the movie that shows the Millenium Falcon flying through space, then the movie cuts to show Han Solo and Chewbaca inside the Millenium Falcon.  Those are two different scenes, but you watched them on the same screen.

But in a computer game or app, you’re scene will typically be a single screen of information, so it’s easy to interchange them. I’d rather screen be used to describe the physical content area.

As for your project, it’s best to not have any buttons and such in main.lua, just have it go to a menu.lua scene that has your visible UI. Then your button can go to your game.lua scene.  But as @sgs stated scene’s have to be proper scenes. I always start with the basic template.  In fact I just have a file called template.lua and copy it to each scene and then use that file to build the scene.  You can get the code for the base template scene here:

https://docs.coronalabs.com/api/library/composer/index.html#scene-template

Rob

#9

Hello Rob.

Thanks for that. The template file has given me more insight. Very much appreciate it. I can see this learning will be a slow process but if I can concentrate and work with the forum group I am sure I will have some success.

db

#10

@anon63346430

thanks for the input. Must admit I tried for a while to understand the composer manager stuff. Its a bit to deep for me early leanings. Appreciate the reply and I am sure this will not be my only call for help.

db

#11

@david874, we have a ton of resources on using Composer.  In addition to the API documentation, there is the guide:

https://docs.coronalabs.com/guide/system/composer/index.html

Then there is the Getting Started guide. Chapter 4 specifically covers converting a non-scene managed game to Composer based:

https://docs.coronalabs.com/guide/programming/index.html

It really helps to understand how display.newGroup() works since that’s really what a Composer scene object is at its core. It helps to have faith that it works if you follow the rules Composer will work. I see too many people who have objects that don’t remove working to hand remove them when the only reason is they didn’t put the object in the scene’s display group.  

Then there are four basic principles regarding scenes.

  1. Scenes need to be created if they don’t exist. If they have never been created, then they will have to be created. You need to know when your scene is requested to be built, so your scene gets an event when the scene needs to be created. You should create any display objects here that are always going to be part of the scene, the user interface, buttons on a menu scene etc. You should not start spawning enemies or start the game here since the scene can be created and cached if you desire well before you ever show it.

  2. A scene will always be shown before your users can see it. So your scene will be notified when it’s shown… twice.  Many developers will want to know before the scene is shown and others will want to know when the scene is completely on the screen. And some will care about both. So you can tell the difference, we use a member of the passed in event table called event.phase that will either be the string “will” or “did” to indicate if the scene is about to be shown (and previously created)  or the scene is completely on the screen.

The “will” phase is a good time to create your player and enemies, but don’t start them yet. If you’re restarting the scene, and it already exists, you may want to reset things like object positions, score values, etc.  The “did” phases is the appropriate time to start everything, animations, physics, timers, spawning future enemies, moving backgrounds etc. This is a good time to start the background music for the scene.  The time between the “will” and “did” phase is any time you’ve set up to transition the scene on screen.

  1. When changing scenes, the current scene will be notified… twice… that it’s in the process of hiding. Like showing a scene, there will be two calls with event.phase either being “will” and “did”. The “will” phase is the time you will cancel timers and transitions, pause or stop physics, etc.  The scene will transition over any defined transition time, and when done you will be notified with a “did” phase. There really is not a lot that you will want to do here, but if you want to remove the scene, you can do it now.

  2. Scenes can be destroyed. Generally, this will happen if you explicitly decide to remove the scene using composer.removeScene(), though a scene not showing can be removed based on settings like when memory gets low and a scene is not being shown. When a scene is removed, your scene will be notified that it’s about to be destroyed.  There really isn’t much work to do here if you’re letting Composer manage your display objects because it will remove them for you. About the only thing to do here is unload any audio that you may have loaded during a “create” event. Everything else should have already been handled.

So digest on that for a bit, look at the Composer Guide and read through the Composer chapter of the Getting Started guide and see if you have a better feel for scene management.

Rob