Include lsqlite3 in 0.9.0 or later

[Kyle]

I'd like to suggest adding SQLite3 support to LOVE. I'm sure everyone knows, but SQLite is a flat-file database system, and it's extremely light and flexible. It'd make a good addition to LOVE. I can already add it myself just by dropping a DLL in the LOVE folder and requiring the module, but it limits me to Windows only because I don't have Linux or a Mac to build on.

Also, maybe it'd encourage whoever's doing the Android port to reflect it, since Android has SQLite support built-in!

[slime]

Why? Serialized Lua tables, JSON, and XML aren't good enough? I can't name a single game (in general, not just made with LÖVE) that uses a client-side SQL database.

Also,
https://bitbucket.org/rude/love/issue/83/sql-db-module
https://bitbucket.org/rude/love/issue/3 ... de-sqlite3

[Kyle]

Why? Serialized Lua tables, JSON, and XML aren't good enough? I can't name a single game that uses a client-side SQL database.

Nope, I don't think they're good enough, honestly. Those are all text formats and half of them are bloated (XML being the main offender.)

Specifically for my game, I'm using an SQLite database to store tons of generated information (an entire galaxy.) If you give someone the tools, there'll be a use. I don't think it'd be too difficult to add, either. This library makes it quite easy and straightforward. I'm asking mainly because I'd still like to support Linux and OS X, but I can't compile for either. Not easily, anyway.

It doesn't need to be a new module in LOVE, it can just be included much like LuaSocket. Some games also use LOVE for the server, since it's a nice API and environment already, and it works well enough if you just disable graphics.

[slime]

Why? Serialized Lua tables, JSON, and XML aren't good enough? I can't name a single game that uses a client-side SQL database.

Nope, I don't think they're good enough, honestly. Those are all text formats and half of them are bloated (XML being the main offender.)

Specifically for my game, I'm using an SQLite database to store tons of generated information (an entire galaxy.) If you give someone the tools, there'll be a use.

have you looked into binary serialization? That's what every other game, engine, and framework does when they don't want bloated plaintext data.

[Kyle]

Why? Serialized Lua tables, JSON, and XML aren't good enough? I can't name a single game that uses a client-side SQL database.

Nope, I don't think they're good enough, honestly. Those are all text formats and half of them are bloated (XML being the main offender.)

Specifically for my game, I'm using an SQLite database to store tons of generated information (an entire galaxy.) If you give someone the tools, there'll be a use.

have you looked into binary serialization? That's what every other game, engine, and framework does when they don't want plaintext data.

Yes, I have. It's not going to work for my game. I don't want to recreate SQLite when SQLite has already been made. What I'm after is the automatic file setup. It's a good system already.

[slime]

Why won't it work for your game when it works for every other one? Why don't other games use SQL(ite)?

[Kyle]

Just forget it, then. I'm not going to sit here and argue with you if you can't already see the benefits. I'll just add it myself.

[slime]

I'm just looking for a more well-researched proposal than "I think it should be in LÖVE because I could use it in my game", especially since it's been proposed and denied multiple times before.

[miko]

I'm just looking for a more well-researched proposal than "I think it should be in LÖVE because I could use it in my game", especially since it's been proposed and denied multiple times before.

I am also for sqlite3. Obvoius advantages are:
- possibility to save game states, without worrying about file location and/or OS issues (like different paths)
- relational queries (SELECT ... WHERE ... ORDER BY ...) could realy ease the game development (like statistics, history, near-by objects, owned by player etc.)
- indexed data (i.e. fast access even with lots of data)
- easy to backup/restore data, and transfer it to other machine.
- it is really small for what it gives back, and it is a standard SQL
- you could use another way of programming with Entity Systems

[Kyle]

I'm just looking for a more well-researched proposal than "I think it should be in LÖVE because I could use it in my game", especially since it's been proposed and denied multiple times before.

I am also for sqlite3. Obvoius advantages are:
- possibility to save game states, without worrying about file location and/or OS issues (like different paths)
- relational queries (SELECT ... WHERE ... ORDER BY ...) could realy ease the game development (like statistics, history, near-by objects, owned by player etc.)
- indexed data (i.e. fast access even with lots of data)
- easy to backup/restore data, and transfer it to other machine.
- it is really small for what it gives back, and it is a standard SQL
- you could use another way of programming with Entity Systems

It's also a lot faster than XML, and writing a binary format yourself is stupid when there's already a great library to do that for you - it even adds relational queries like Miko mentioned. And since everything is in one file, backups and moving are a snap.

And not all of us have the time to sit down and write efficient ways to access and use our binary data. SQLite is tried and tested already.

It'd really be a great addition.