LÖVE

I'm against. I don't think it adds enough to warrant the extra dependencies and dev time. I think the advantages miko and kyle have listed are overstated and would help only a minority of devs.

kikito wrote:I'm against. I don't think it adds enough to warrant the extra dependencies and dev time. I think the advantages miko and kyle have listed are overstated and would help only a minority of devs.

It's a very small library and the only dependencies are sqlite3 and Lua. It's implemented as a Lua module. In fact, rebuilding LOVE isn't even necessary - the only issue is that I don't have the resources to build a .so and whatever OS X uses. It'd be much, much more convenient if it was just included in the repo. Besides, LOVE already has a crazy amount of dependencies, what's one more? And who knows, maybe you'll come up with an idea that'd benefit from it. We should be opening doors, not keeping them closed because it's "too much work" when in fact... it's really not.

I am a heavy SQL user and can say that having an SQL system in a game framework would be a great thing.

Love has the library luasocket2 includeded because it's rather easy to use and it serves a vital function in games (multiplayer).

The way to include libraries that aren't in love is a little bothersome, but possible; Including extra binary libraries or requiring the user to install libraries via something like luarocks.

But, here's the crux of the issue;

The difference between luasocket2 and other libraries such as LuaSec(https) and lsqlite3 is that they are not easy to use, or even commonly used. On top of that, they add requirements to the makefile and will in the end (via binary or additional libraries) make the footprint larger. The love frameworks trys to give a user the bare essentals for making video games (thus libraires exist) and in my opinion, luasocket2 is one of the rare exceptions, due to the fact that it provides a networking interface.

But, as an SQL user, I would be very happy to have some extra libraries such as lsqlite3 and LuaSec, but totally understand why the developers don't want to bloat the framework.

Perhaps a compromise might be in order?

Why can't we add some compile flags to the engine to allow libraries to be included? e.g. --use-lsqlite3 and --use-luasec? Since any serious game developer is going to want to distribute the binary with the game anyway, why not have an easy way for developers to make alternate binaries with flags?

Kyle wrote:Besides, LOVE already has a crazy amount of dependencies, what's one more? And who knows, maybe you'll come up with an idea that'd benefit from it. We should be opening doors, not keeping them closed because it's "too much work" when in fact... it's really not.

Crazy amount? I don't think so. There's Box2D, GLee, LuaSocket, UTF8-CPP (which are included in the LÖVE source) and SDL, DevIL, FreeType, libmodplug, libvorbis, mpg123, OpenAL, PhysicsFS. Most of those libraries do something very specific and are required to get the functions of the current LÖVE modules. I also don't think it's about the amount of them, but if a dependency is actively used by LÖVE and the lovers (in a proper way, hopefully). Nobody says that a database interface would not be useful.

I'm not sure how the developers feel about just slapping the Lua module into it. Yes, I know there's LuaSocket, but that has been in there for a while. There were discussions about a network module and actual implementations are popping up now.

In the end, it's up to the developers if they decide to open this door for their project. I'm pretty sure they're aware what a database can do for LÖVE. You may be able to increase the chance to get this included by showing an example or even an implementation, though it's possible that this is work could get a simple no as an answer. I'm assuming you keep your expectations at a reasonable level.

Edit:

josefnpat wrote:Why can't we add some compile flags to the engine to allow libraries to be included? e.g. --use-lsqlite3 and --use-luasec? Since any serious game developer is going to want to distribute the binary with the game anyway, why not have an easy way for developers to make alternate binaries with flags?

Only Linux has a proper package system and there should be quite a few prebuilt binaries of Lua modules and their dependencies on the internet.

Boolsheet wrote:Only Linux has a proper package system and there should be quite a few prebuilt binaries of Lua modules and their dependencies on the internet.

I am not familliar with building stuff on os-x and windows. Are you telling me that windows and OS X don't use the makefile to build the framework?

Well, I don't think the official binaries for OS X and Windows were built with the autotools. You certainly can use the autotools on OS X and on Windows with Cygwin or MinGW, but I'm not sure what this has to do with it. The lover would still require all the target platforms or go with cross-compiling. (I'm under the impression that proper cross-compiling is a black art.) Your suggestion also requires that the Lua module is already present on the system or included in the LÖVE source. LuaSec comes with the OpenSSL dependency and I very much doubt that's going into the LÖVE repository.

Then again, the Lua module loader already solves this problem for us. The least painful way is distributing prebuilt binaries, I guess. Or not supporting that platform since the lover can't test on it...

Yes, I've thought of this, but I quickly realized that generally a proper relational database is like trying to subtly tail people in an australian road train, then again, I guess the same goes for box2d..

I think the less dependencies the better. Especially if we EVER plan on having proper releases on other devices like iOS, Android and the many other smaller indie kickstarted game consoles that keep coming out.

The more dependencies you add, the harder it would be to port to them.

Jasoco wrote:I think the less dependencies the better. Especially if we EVER plan on having proper releases on other devices like iOS, Android and the many other smaller indie kickstarted game consoles that keep coming out.

The more dependencies you add, the harder it would be to port to them.

Like I said, Android comes with SQLite built in. iOS is probably a similar situation.

My two cents because I see both sides:

• I can see reasons why SQLite would be useful in a game. Querying over a set of data (e.g. get all the ships owned by the enemy and with health < 10 that have shields disabled), transactions, etc. For every made-up use case I can come up with there are probably many more that arise in practice.
• A file-backed SQLite database takes a lot of the burden of loading/saving and maintaining consistency away from the developer.
• It's okay for the devs not to include a library if they feel it's not a common requirement. Every dependency adds complexity.
• Both iOS and Android provide SQLite database access to applications.
• SQLite would add about 400KiB to the binary.

Note: In my experience, it's much more difficult to manage an SQLite database on a remote installation (e.g. a smartphone or game install) than something like JSON or a document DB. Schema migrations are a PITA and they just feel very rigid. Your mileage may vary though.

Personally I vote (whatever weight that carries) not to include SQLite into Love. I'm sure the devs will be more than willing to help anyone who wants to include SQLite in their build of Love.