I'm making a multiplayer action game. 'addons'
will be downloaded from the server you connect to. Of course you could download a set of files manually, but that has some issues:
- you need more code to verify all the files a specific server requires
- if several addons modify the same resources, you will either need to re-download them repeatedly, specifically check for conflicts and add caching code, or add filesystem abstractions like...well, PhysicsFS...which Love already has.
Other suggested solutions involve using some Lua compression code. Of course, it can be done. That has however some downsides too:
- It is slower than native implementations
- It would either require you to add additional code from your part to extract ALL those files (possibly conflicting with other addons/archives)
- Should a bug be found in the decompressor, everthing that uses that lib would have to be manually updated. ...as opposed to simply being fixed in the next love release.
- It would make a mess of your filesystem after a few of such addons
- It would make it virtually impossible to remove the addons you don't want anymore without corrupting the other addons
Yes, some of you will tell me that it is possible to solve all of those issues. It will however require you to add additional code, probably too specific for you game, and many people will have to code similar workarounds and hackish code over and over again.
So my question is why do all this if there is a more elegant and efficient solution? Love uses PhysicsFS internally, which was basically designed to do this. it already implements archive and directory mounting (which love2d uses) so we simply exposed that.
Here is what we already implemented:
- mount/umount archives (using whatever mountpoint you want)
- archives can only be loaded from locations provided by conf.lua
- automatic mounting of archives from 'conf.lua' (those can not be umounted and can be loaded from wherever you want)
Its not yet complete, our TODO list:
- globbing for automount (and to expose in love.filesystem in addition to enumerate or to replace it)
- maybe add restrictions to where an archive can be mounted (but is it really needed?)
- review the C++ code we already have and make it a bit better
There is currently only one known issue, love.filesystem.lines() doesn't play nice with mounted archives. If you call it on a file in a mounted archive, you won't be able to umount it. I will try to fix this tomorrow.
For everyone interested in trying it out: hg clone https://bitbucket.org/atheros/love-mount
Now we will be focusing on adding more real-world examples to show you the benefits of being able to mount other archives and hopefully catch all the bugs in the process we didn't encounter yet.