Basic lua + love file structures + dependancies

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
User avatar
timmeh42
Citizen
Posts: 90
Joined: Wed Mar 07, 2012 7:32 pm
Location: Cape Town, South Africa

Basic lua + love file structures + dependancies

Post by timmeh42 » Fri Mar 23, 2012 2:50 pm

Okay, noob question here. Up until now I've been programming all my stuff in one fat, cluttered main.lua file. However, I see everyone using separate files and calling functions from them in the main.lua file. What is the proper way to structure these files, and how exactly do you execute functions from the files? I also see people using arrays of functions or some-such, what are these?

User avatar
TechnoCat
Inner party member
Posts: 1611
Joined: Thu Jul 30, 2009 12:31 am
Location: Denver, CO
Contact:

Re: Basic lua + love file structures + dependancies

Post by TechnoCat » Fri Mar 23, 2012 3:25 pm

timmeh42 wrote:What is the proper way to structure these files
There is no "correct" way. It is up to you, but I see a convention somewhat similar to this a lot:

Code: Select all

\
| README
| LICENSE
| main.lua
| conf.lua
+ img
  | image.png
  | cat.png
+ lib
  + HardonCollider
  | middleclass.lua
+ lua
  | menu.lua
  | actor.lua
+ snd
  | bark.ogg
+ maps (I mean really, whatever other folders you think you need)

User avatar
trubblegum
Party member
Posts: 192
Joined: Wed Feb 22, 2012 10:40 pm

Re: Basic lua + love file structures + dependancies

Post by trubblegum » Fri Mar 23, 2012 3:37 pm

The proper way to do it is to declare a table as a local inside a .lua file, and then return it, like so :

Code: Select all

local def = {}
return def
If you declare a global in the include, it will go into the global scope of your program, so try and avoid it.

Now there are differences of opinion on how you should define stuff in the table. I like to do it all inline, but some prefer to define values after the table is initialized :

Code: Select all

local def = {
   load = function(this) -- doing it inline-style
      return setmetatable({}, {__index = this}) -- this function returns an instance. yours can do whatever you want them to do
   end, -- don't forget the comma
   update = function(this, dt)
   end,
}
-- or declare stuff outside of the table, as you might prefer
def.draw = function(this)
end

return def
If that all goes in object.lua, then when you do object = require('object'), it executes the code in object.lua as a function, which returns the table you declared.
object is set to the returned def table, so object.load is the load function, update is the update function, etc, and if I call object:load() it will return a new instance of object.
As you can see from the first example, yours doesn't need to do that, but it's often a useful thing to do.

One way to look at it is :
"require(modname) is a function which is called in the global scope, and it's code is stored in the file modname"

Lua functions are just a data type, like string, number, and table, so they can be stored wherever you want them, moved around, overridden, compared, and even (although it's not usually a good idea) used as table indices.

Edit : just noticed I'd done the thing I told you not to do :oops: fixed

Post Reply

Who is online

Users browsing this forum: Sky_Render and 16 guests