I have put the object into the scene.view. Otherwise, it’ll show nothing on the screen?
I think my problem is cannot get Level to reload images of level1 ?
@panc software
Sorry but i don’t see that JSON could help me now. What i know is JSON processes string, but my images are loaded fine. So i think i don’t have problem with string variable…
Maybe you could explain your point some more?
Thanks for the link. I’ll definitely use it for saving score, options, etc.
I printed out the texture memory when the game is on level1 and 2, and they showing the exact same value. Confuses me even more, i thought they should be different?
I did some forward declaration for variables and functions outside the scene:createScene().
I’m sure that i created all display object inside the scene and put them into the group, but i still need that line though.
I used collectgarbage() on each level and it fluctuates regularly. So i thought it’s okay…
Just wondering,
[package.loaded[loadLvl] = nil ] will clear the reference only while the object is still in memory? And that object will stay there until the app is closed? Is that mean on 100th level, the memory still keep the previous 99 objects?
I would recommend Storyboard for this. Back in the day, when I first started using Corona I didn’t understand scene managers and what they do (Director then eventually Storyboard) and my first app’s code is a disaster because I had to try and build all of these different “scenes”. Once I made myself learn Director (then eventually Storyboard after it came out), it was a huge enlightenment.
When using a scene manager (and I’m going to be using Storyboard only going forward for various reasons), you have a separate .lua file for each scene. In my apps that includes:
Basically menu calls levelselect which calls the appropriate level for the game. Just a note, main.lua is not a scene, it basically calls your first scene. splash.lua would be optional if you want an intro or not. You could go straight to your menu scene if you want.
levelcomplete.lua would likely go back to your game.lua or the next levelX.lua if you’re using multiple files for your levels. If the player looses, then the game level would go to gameover.lua and after gameover.lua you would go back to menu.lua.
It can get a bit tricky if you want to have a pause in your game where you save the existing level’s state, and then get back to the menu in which case you would need a resume button that would skip level select and go back to your game level.
I would recommend building a simple app using multiple scenes before you get into more complex things, like maybe a menu, a level of game and a credit scene to get an idea of how they work.
There are multiple tutorials on using Storyboard available. You can start here:
Thanks Rob for the detailed explanation and the comprehensive answer.
I do appreciate your time doing that. It gave me a very good idea about the storyboard usage. I will start playing with storyboard to build multiple screens and see how they work…
Here is my take on your question. I would definitely use storyboard to transition between scenes in the game, exactly as Rob describes it. Concerning the level files, you have two ways of going.
First way: If your levels differs in game logic and gameplay from each other in a major way, you can make the level files storyboard scenes. But I personally do not think this is the best design.
Second way: Levels with common gameplay call (require) a lua-file that contains the content of that level. The level-file is not a scene, but merely contains tables with words, image file names, etc. The specific things for just this level. The gameplay is most likely same across many levels and is using a single storyboard scene.
If your game contains many types of gameplay, you could arrange it in this way:
gameplayTypeA.lua (a storyboard scene) -\> calls levelA1.lua, levelA2.lua, etcgameplayTypeB.lua (also a storyboard scene) -\> calls levelB1.lua, levelB2.lua, etc
You are right… my game is the same across the levels because it is just simple try to practice. The only change is the speed for enemies and background etc…
I am interested to know more about the thing you explained. How can I implement your idea? my game is as follows :
main.lua --> start.lua – > game.lua ( all of them are storyboard scenes)
i want to do this way :
main.lua --> menu.lua --> levelselect.lua – > then goes to the game with parameters passed of speed and background pic etc but the code is mostly the same
In your levelselect.lua you could have something like this. It calls gama.lua
local storyboard = require "storyboard" local levelList = {"level1", "level2", "level3"} -- Set your current level, maybe with a button... local currentLevel = levelList[1] local options = { effect = "slideLeft", time = 800, params = { levelSentToGame = currentLevel } } storyboard.gotoScene( "game", options )
In game.lua you need to take care of the variable (besides all other storyboard code…):
function scene:enterScene( event ) local params = event.params local currentLevel = params.levelSentTOGame -- This is the level passed from levelselected.lua print( currentLevel) local myLevelData = require(currentLevel) -- This gets the data in "level1.lua" end
You will in this case make sure the data in levelX.lua returns a table…
I hope this gives you an idea how you could arrange it.
For my game(s), I make one file that has all of the gameplay and such inside of it, and load a single “data file” that gives level data. Something like this, since people are doing arrow notation :). I’ll just include the main file, the levelselect, and the game:
[lua]
main.lua -> levelselect.lua -> [save selected level as a value] --> maingame.lua [
Loads file corresponding to the saved value
Changes internal values like enemy speed, platform positions, time limit, etc according to loaded data
Sets up and performs level
]
[/lua]
If you do it this way, you can make a single change to maingame.lua and you won’t 'ave to go to each level and change it. That’s a nightmare, believe me - you’ll find yourself making millions of redundant changes 20 times every time you want to change something.
Yep - the only difference is mine works even if you don’t use storyboard (I’m old-school and still use SceneManager… I probably ought to port over some day).
there are always few ways to do the same thing Thanks for giving more explanation to this issue.
Jensto,
i was able to send one variable only to game scene only such as currentLevel by making it global variable in levelselect.lua and send it as storyboard.gotoScene( “game”, currentLevel ) then read it from game.lua as for example local level= currentLevel
i was not able to send the options as parameters. i was getting error "attempt to index local ‘’ a nil value ‘params’ in game.lua line :
local params = event.params
i tried to remove the local word but still not luck :)
actually i did not get this working ? can you explain why what do mean by :
local options =
{
effect = “slideLeft”,
time = 800, params = { levelSentToGame = currentLevel }
}
At the end I introduce the idea of having a “mydata” module (mydata.lua) that is a table that holds your data you want assessable from everywhere. It’s like global data without the inherent problems of global variables.
Though generally speaking, main.lua isn’t a scene and you never really go back to it. However, various events are best programmed in main.lua (like the android key listener, accelerometer, system events, etc.) and those functions may run at any time and could benefit from things your scenes are doing. This mydata method solves that.
As Rob says, it is never recommended to use global variables. Things can get really ugly and very hard to debug if by mistake use the same variable name in another module or scene.
Concerning the params you would like to send the hole options table. In that way you can control the transition AND send the parameters.
Check out the documentation for gotoScene also. The example code supplied with corona do not show parameter passing…
(When I test new stuff I always make a little test project to mess around in. Then you don’t have screw up your main project and have the possibility to toss the code if it is no good.)
