Multiple LOVE files

[99999999]

I was only introduced to Love in the past week, and I've been seeing it's utility ever since.

One thing I was wondering about was the automatic folder searching. I've developed and distributed some very large casual games, and one of the big no no's, is that you can't put all your eggs into one basket. In particular when you have a game split to multiple logical sections (levels, etc..) you don't want to keep the data for a previous level in memory. Especially if nothing between the two is shared.

So it would be super awesome if the idea multiple LOVE files in the love directory could be loaded/unloaded via the love game engine. As I see it in 0.5.0 that isn't a supported (yet?) behaviour.

[TechnoCat]

I'm under the impression that if you want to remove a variable from memory you can just remove all references to it and lua will do the garbage collection. I could be wrong/misunderstanding though.

[subrime]

You could have a system like this:

Code: Select all

loadsection={'data/level1/load.lua','data/level2/load.lua','data/level3/load.lua'}

local level=1
while level>0 do
  dofile(loadsection[level]))
-- have fun...
 level=select_level() -- however you want this to happen
end

[bartbes]

Except for dofile not working together with love.filesystem (though that might be intended?)

I was wondering why you'd need this, there should be no difference between multiple files in a .love and multiple files on your filesystem. Note that LÖVE never parses the zip, or anything like that, it just reads from it and only reads in the data it needs. I'm not sure about how PhysicsFS (the underlying system) handles zips, but I don't think it loads them to memory.

[99999999]

Actually there is a very good reason for needing this. When distributing my games, it is common for the game executable to be encrypted via any number of wrapping tools. (i.e. Armadillo from www.siliconrealms.com). These wrappers load the entire decrypted binary into memory at once. As a result if using love with an attached game binary, (as described in the distribution section,) the entire game would be loaded into memory. This slows down the initial loading process of the game, as the entire contents of the game will be decrypted into memory.

Obviously I can't just ship the game as a .love file either, as just encrypting the normal love.exe in the same distribution would have no protection effect.

The best case solution would be that the game's code would be in the encrypted executable, and the resources would be (unencrypted,) in the directory for the game. Either in .zip/.love files, or even just in multiple directories.

[bartbes]

The only way you can do this with love.filesystem (and thus with 0.5.0) is putting all the resources etc in the write dir.

[99999999]

Yes again not a particularly acceptable form of distribution. I guess it's time for me to start building and working on this problem myself.

[bartbes]

However, in 0.6.0 you can load images and sounds from memory too, so you should be able to use the standard io lib provided by lua.

[subrime]

Except for dofile not working together with love.filesystem (though that might be intended?)

Ah, I forgot that I already fixed love to work using:

Code: Select all

-- standard dofile and require lua functions are denied access to the 
-- filesystem (for security) so make them use the allowed paths
local base='code/'
function dofile(f) return love.filesystem.include(base..f) end
function require(f) return love.filesystem.require(base..f) end