can I dynamically load a lua file? (e.g. load level23.lua, from within my main game storyboard file)

Solar2D General Questions/Discussion
#1

Is it possible to dynamically load a lua file? e.g. loading the next level?

Background:
* Have a storyboard based little game
* Was going to have a different storyboard file for each level, but then the dynamics/code is exactly the same, so I thought I would load the level background/objects from a separate file dynamically. E.g. I could have level_1.lua, level_2.lua, etc. And within these files they could create (in lua) their whole set of background / interaction objects etc, and pass back to the main game storyboard file as one display object
* Worked fine with a “require level_1”, but now trying to make this dynamic I may be hitting an issue

If it’s not possible any suggestions?

[import]uid: 140210 topic_id: 34498 reply_id: 334498[/import]

#2

You cannot dynamically load a lua file. If the contents of the lua file can be condensed to a table, it could be saved out as JSON data and you can have different JSON files for each level and read that in.

There is code in the community code area that makes saving and loading JSON data a snap (You don’t need to know JSON),

[import]uid: 199310 topic_id: 34498 reply_id: 137148[/import]

#3

thanks Rob - or perhaps if sticking to working in Lua code, then having a different Storyboard file for each level to build the background/interactive objects, and then inject the same level handling code into this. Is this an approach that is used frequently? What you suggested sounds ok for a basic game, but if you want different levels to have different unique objects/challenges that each require some specific coding to get that uniqueness then wouldn’t it fall down here?

PS. Any sample game source you know of where they have used specific lua code in each separate level to give each different level something unique/special? i.e. any example code where levels were built with Lua as opposed to using some Array/DataDriven/Json based approach. So I can see what their coding approach was [import]uid: 140210 topic_id: 34498 reply_id: 137149[/import]

#4

Yes, if the levels need to have separate behaviors that can’t be condensed to data, then it breaks down. But that doesn’t mean that you can’t program the unique logic either into modules that you would require or have in your main game’s code. They just have to be loaded at build time.
[import]uid: 199310 topic_id: 34498 reply_id: 137159[/import]

#5

Hi Rob - thanks again - so to clarify my understanding…

* So you can’t call the various level code dynamically, but you could have a level selector with an image/button for each level, which then hard codes the loading of level.
* In fact in terms of not having to inject the non-changing level code itself into each level background/object building code the following would work wouldn’t it:

  • storyboard - load level selector page
  • select / click on a particular level
  • load your background/interactive object level specific code & return it as a display object
  • goto the Storyboard main game page BUT passing in the levelDisplayObject in

Then you should get both:
* lua specific level background development
* only one file for the generic game level code, with no need to inject it into multiple level lua files

[import]uid: 140210 topic_id: 34498 reply_id: 137162[/import]

#6

I’m having a bit of difficulty following your conditions.

You can “require” various modules. They are loaded at build time (or run time in the simulator). You cannot require anything once the app is compiled (no dynamic loading).

You can put all your per level logic in external modules, but they have to be loaded at build time, making one big app.

Things like backgrounds, avatars, graphics, sounds, etc, could be coded into a lua table for each level and your game could look up its resources in the table and use those resources to draw the level. That table data could be saved into various level files and loaded in on demand. No executable code can be called this way.

[import]uid: 199310 topic_id: 34498 reply_id: 137166[/import]

#7

thanks Rob - so re “You can “require” various modules. They are loaded at build time (or run time in the simulator)”. I wasn’t aware of this. So from a production/device point of view, no matter how smart you think you are only “requiring” modules when you need then, they are ultimately all loaded at start up then in production hey? But then if you truly want level specific behaviour that requires code, then there is really no way around the fact you’ll have to have one big app correct? (i.e. all code loads up when you start the app on the device) [import]uid: 140210 topic_id: 34498 reply_id: 137167[/import]

#8

thanks Rob - so re “You can “require” various modules. They are loaded at build time (or run time in the simulator)”. I wasn’t aware of this. So from a production/device point of view, no matter how smart you think you are only “requiring” modules when you need then, they are ultimately all loaded at start up then in production hey? But then if you truly want level specific behaviour that requires code, then there is really no way around the fact you’ll have to have one big app correct? (i.e. all code loads up when you start the app on the device) [import]uid: 140210 topic_id: 34498 reply_id: 137168[/import]

#9

That’s my understanding. [import]uid: 199310 topic_id: 34498 reply_id: 137170[/import]

#10

understood Rob - but in my scenario I was pushing complexity a little beyond this to where actual lua coding is required, i.e. specific code per level to capture unique items in that level only… [import]uid: 140210 topic_id: 34498 reply_id: 137179[/import]

#11

Hi Greg,
I think with a little clever planning, and careful coding, you can mesh the suggestions made throughout this thread into a workable solution that doesn’t involve “dynamic lua loading”. For example, take a pencil and paper (my favorite way to brainstorm ideas, despite all the digital tools and trinkets) and ponder, “how can I combine such a function of method into something that can be shared between levels/purposes/behaviors?” Can you create functions that accept many different arguments and then pick apart those arguments to suit a “common purpose”? Can you combine 5 unique functions that share a few common traits into 1 function? Etc. etc. Not only does that ultimately simplify your code, but it organizes things too.

You might also investigate an object-oriented approach. Corona dev Omid Ahourai has posted an OOP method on his blog here (there are other approaches if you search online, but this one is very current): http://www.ardentkid.com/blog/

Brent [import]uid: 200026 topic_id: 34498 reply_id: 137182[/import]

#12

You cannot dynamically load a lua file. If the contents of the lua file can be condensed to a table, it could be saved out as JSON data and you can have different JSON files for each level and read that in.

There is code in the community code area that makes saving and loading JSON data a snap (You don’t need to know JSON),

[import]uid: 199310 topic_id: 34498 reply_id: 137148[/import]

#13

thanks Rob - or perhaps if sticking to working in Lua code, then having a different Storyboard file for each level to build the background/interactive objects, and then inject the same level handling code into this. Is this an approach that is used frequently? What you suggested sounds ok for a basic game, but if you want different levels to have different unique objects/challenges that each require some specific coding to get that uniqueness then wouldn’t it fall down here?

PS. Any sample game source you know of where they have used specific lua code in each separate level to give each different level something unique/special? i.e. any example code where levels were built with Lua as opposed to using some Array/DataDriven/Json based approach. So I can see what their coding approach was [import]uid: 140210 topic_id: 34498 reply_id: 137149[/import]

#14

Yes, if the levels need to have separate behaviors that can’t be condensed to data, then it breaks down. But that doesn’t mean that you can’t program the unique logic either into modules that you would require or have in your main game’s code. They just have to be loaded at build time.
[import]uid: 199310 topic_id: 34498 reply_id: 137159[/import]

#15

Hi Rob - thanks again - so to clarify my understanding…

* So you can’t call the various level code dynamically, but you could have a level selector with an image/button for each level, which then hard codes the loading of level.
* In fact in terms of not having to inject the non-changing level code itself into each level background/object building code the following would work wouldn’t it:

  • storyboard - load level selector page
  • select / click on a particular level
  • load your background/interactive object level specific code & return it as a display object
  • goto the Storyboard main game page BUT passing in the levelDisplayObject in

Then you should get both:
* lua specific level background development
* only one file for the generic game level code, with no need to inject it into multiple level lua files

[import]uid: 140210 topic_id: 34498 reply_id: 137162[/import]

#16

I’m having a bit of difficulty following your conditions.

You can “require” various modules. They are loaded at build time (or run time in the simulator). You cannot require anything once the app is compiled (no dynamic loading).

You can put all your per level logic in external modules, but they have to be loaded at build time, making one big app.

Things like backgrounds, avatars, graphics, sounds, etc, could be coded into a lua table for each level and your game could look up its resources in the table and use those resources to draw the level. That table data could be saved into various level files and loaded in on demand. No executable code can be called this way.

[import]uid: 199310 topic_id: 34498 reply_id: 137166[/import]

#17

thanks Rob - so re “You can “require” various modules. They are loaded at build time (or run time in the simulator)”. I wasn’t aware of this. So from a production/device point of view, no matter how smart you think you are only “requiring” modules when you need then, they are ultimately all loaded at start up then in production hey? But then if you truly want level specific behaviour that requires code, then there is really no way around the fact you’ll have to have one big app correct? (i.e. all code loads up when you start the app on the device) [import]uid: 140210 topic_id: 34498 reply_id: 137167[/import]

#18

thanks Rob - so re “You can “require” various modules. They are loaded at build time (or run time in the simulator)”. I wasn’t aware of this. So from a production/device point of view, no matter how smart you think you are only “requiring” modules when you need then, they are ultimately all loaded at start up then in production hey? But then if you truly want level specific behaviour that requires code, then there is really no way around the fact you’ll have to have one big app correct? (i.e. all code loads up when you start the app on the device) [import]uid: 140210 topic_id: 34498 reply_id: 137168[/import]

#19

That’s my understanding. [import]uid: 199310 topic_id: 34498 reply_id: 137170[/import]

#20

understood Rob - but in my scenario I was pushing complexity a little beyond this to where actual lua coding is required, i.e. specific code per level to capture unique items in that level only… [import]uid: 140210 topic_id: 34498 reply_id: 137179[/import]