game tabs?

Getting Started Newbie Questions
#1

Hello, 

When setting up a game the tabs I’ve seen are moving from L to R, build.settings, config.lua, main.lua, menu.lua.  After that it gets a little iffy, I’ve seen game.lua, mydata.lua, GGData.lua, play.lua, ogt_lmdata.lua, json.lua, and some others I can’t recall at the moment.

I heard lua was suppose to be very easy language for beginner, but there really isn’t a lot of help out there not like what you can get for python or java.  I looked that the Lua 5.3 Reference Manual, I would rather get root canal than try to figure that stuff out.  Not for beginners.

This forum seems to be all there is, aside from some  out dated info on the net.

Would you be able to steer me in the correct direction?

Thank you

#2

Hey!

I’d recommend thinking of the Lua 5.3 Reference Manual as just that, a manual that provides specific answers to specific Lua programming questions. You won’t find much general app/game development related help there. For Corona related tutorials, I’d recommend that you have a look at https://docs.coronalabs.com/tutorial/index.html

Now, out of those files that you mentioned, build.settings, config.lua and main.lua are Corona related files. The other files are libraries written by other people that serve some specific functions, but using them is completely voluntary. As you read through the tutorials, you should be able to find out what those three files do.

#3

Just to be fully transparent, Corona uses a modified version of Lua 5.1. You will learn things in the Lua 5.3 reference manual that may not work here. I’d stick with the 5.1 manual if it’s there.

Next, we have a great “Getting Started Guide”, just go to https://docs.coronalabs.com and click on the big “Getting Started” button in the top left corner of the page.

Let me get you started with your question:

When setting up a game the tabs I’ve seen are moving from L to R:

These three are the core Corona files:

build.settings – When you build for a device like iOS or Windows Desktop, you’re likely going to need to provide some settings specific for that device. For instance, iOS uses a file called Info.plist that hold various settings for iOS. You can, in build.settings, set up those Info.plist values.

config.lua – This file tells Corona how you want your virtual screen setup. You define the width and height of your virtual screen, if it’s centered or top-left oriented and a few other settings that manage that configuration.

main.lua – This is the main entry point for your application. This file must exist and it’s where we start running your program. Many developers will put some setup code here and then use “scene” management to go to screen specifically designed to just a specific game, like show a menu, allow the user to manage user settings, etc. Other’s will build their entire app in main.lua. It’s better for your sanity to break down your project in to logical modules. One big main.lua is hard to maintain.

Starting here, you’re starting to look at various files created by the specific template/game developer. I can speculate as to what these are, but at this point, these names are really developer provided but generally describe what they do.

menu.lua – It’s logical for most games, to show a menu screen at the start, giving the player an opportunity to configure settings, view a tutorial on how to play, see credits on who made the game, etc. This starting screen is frequently named " menu.lua" since it’s the main menu and it’s the first visual thing presented to the user. Corona has a “scene” management library called composer that lets you easily create different screens. menu.lua is likely a composer based scene that shows a bunch of buttons. 

game.lua – Since you’re likely to have a button in your menu that says “Play”, you will usually have a scene module that draws the core part of your game, the background, the user interface, perhaps puts obstacles or pickups on the screen, puts the main actor on the screen and starts off all the action. Naming this  game.lua is a very common practice. You would likely put your game logic here as well.

mydata.lua – You will find at some point you will want to pass data around between different modules. There are multiple ways to do it and as you start your adventure, you will learn about global variables that are visible to all modules and you will be tempted to go that route. Don’t. Except under specific conditions, globals are considered bad and they are sources of bugs for new developers. If you go to the “Tutorial” link provided by @XeduR, there is a tutorial called “Goodbye Globals” and is really a must-read for new developers. That tutorial shows you how to use a data module that can be included in your other modules that behave like globals, but don’t have the headaches of globals. Many developers will call this mydata.lua.

GGData.lua – I believe this is a library from Corona developer Glitch Games and is their data saving and loading code that makes saving and loading settings. Different developers will use these third-party library files.

play.lua – This seems like it’s an alternate version of the game.lua file. Perhaps the developer chose to use that name, or it contains extra game logic code. 

ogt_lmdata.lua – This is another third-party library file., I don’t have a clue what it does, but the “mdata” might hint that it has something to do with metadata.

json.lua – this could be a third-party library that parses JSON data to help manage content found online through third-party API services and helps you change it from Lua tables to JSON data and back. If that’s what this is, we have an internal JSON library API’s and this shouldn’t be there. Perhaps the developer started this before we added JSON (but that was like 8 years ago) or perhaps they are overriding our existing json.* API’s. Or it could be a poorly named file that has game data information in it. Without seeing it, we can only speculate. If you’re using a template, perhaps the template depends on it. If you’re creating your app from scratch, don’t include this, it’s likely only going to lead to problems.

Rob

#4

Hey!

I’d recommend thinking of the Lua 5.3 Reference Manual as just that, a manual that provides specific answers to specific Lua programming questions. You won’t find much general app/game development related help there. For Corona related tutorials, I’d recommend that you have a look at https://docs.coronalabs.com/tutorial/index.html

Now, out of those files that you mentioned, build.settings, config.lua and main.lua are Corona related files. The other files are libraries written by other people that serve some specific functions, but using them is completely voluntary. As you read through the tutorials, you should be able to find out what those three files do.

#5

Just to be fully transparent, Corona uses a modified version of Lua 5.1. You will learn things in the Lua 5.3 reference manual that may not work here. I’d stick with the 5.1 manual if it’s there.

Next, we have a great “Getting Started Guide”, just go to https://docs.coronalabs.com and click on the big “Getting Started” button in the top left corner of the page.

Let me get you started with your question:

When setting up a game the tabs I’ve seen are moving from L to R:

These three are the core Corona files:

build.settings – When you build for a device like iOS or Windows Desktop, you’re likely going to need to provide some settings specific for that device. For instance, iOS uses a file called Info.plist that hold various settings for iOS. You can, in build.settings, set up those Info.plist values.

config.lua – This file tells Corona how you want your virtual screen setup. You define the width and height of your virtual screen, if it’s centered or top-left oriented and a few other settings that manage that configuration.

main.lua – This is the main entry point for your application. This file must exist and it’s where we start running your program. Many developers will put some setup code here and then use “scene” management to go to screen specifically designed to just a specific game, like show a menu, allow the user to manage user settings, etc. Other’s will build their entire app in main.lua. It’s better for your sanity to break down your project in to logical modules. One big main.lua is hard to maintain.

Starting here, you’re starting to look at various files created by the specific template/game developer. I can speculate as to what these are, but at this point, these names are really developer provided but generally describe what they do.

menu.lua – It’s logical for most games, to show a menu screen at the start, giving the player an opportunity to configure settings, view a tutorial on how to play, see credits on who made the game, etc. This starting screen is frequently named " menu.lua" since it’s the main menu and it’s the first visual thing presented to the user. Corona has a “scene” management library called composer that lets you easily create different screens. menu.lua is likely a composer based scene that shows a bunch of buttons. 

game.lua – Since you’re likely to have a button in your menu that says “Play”, you will usually have a scene module that draws the core part of your game, the background, the user interface, perhaps puts obstacles or pickups on the screen, puts the main actor on the screen and starts off all the action. Naming this  game.lua is a very common practice. You would likely put your game logic here as well.

mydata.lua – You will find at some point you will want to pass data around between different modules. There are multiple ways to do it and as you start your adventure, you will learn about global variables that are visible to all modules and you will be tempted to go that route. Don’t. Except under specific conditions, globals are considered bad and they are sources of bugs for new developers. If you go to the “Tutorial” link provided by @XeduR, there is a tutorial called “Goodbye Globals” and is really a must-read for new developers. That tutorial shows you how to use a data module that can be included in your other modules that behave like globals, but don’t have the headaches of globals. Many developers will call this mydata.lua.

GGData.lua – I believe this is a library from Corona developer Glitch Games and is their data saving and loading code that makes saving and loading settings. Different developers will use these third-party library files.

play.lua – This seems like it’s an alternate version of the game.lua file. Perhaps the developer chose to use that name, or it contains extra game logic code. 

ogt_lmdata.lua – This is another third-party library file., I don’t have a clue what it does, but the “mdata” might hint that it has something to do with metadata.

json.lua – this could be a third-party library that parses JSON data to help manage content found online through third-party API services and helps you change it from Lua tables to JSON data and back. If that’s what this is, we have an internal JSON library API’s and this shouldn’t be there. Perhaps the developer started this before we added JSON (but that was like 8 years ago) or perhaps they are overriding our existing json.* API’s. Or it could be a poorly named file that has game data information in it. Without seeing it, we can only speculate. If you’re using a template, perhaps the template depends on it. If you’re creating your app from scratch, don’t include this, it’s likely only going to lead to problems.

Rob