RPG Maker + SQLite

Started by azdesign, September 12, 2012, 08:16:07 am

Previous topic - Next topic

azdesign

I just wondering, is there is such rpg maker games/plug-ins which is using SQLite to store its custom database ? Because I think this is very effective rather than storing data in a variables. It doesn't need a server, stored in local folder, just need a gem to work. The scenario of my project requires a custom data to be stored, well it can be achieved without sqlite, but I think, data stored in database are more "mannered".  :)
~ Check out my deviantart http://my-az-design.deviantart.com/ ~

Memor-X

technically how RMXP uses it's database is effective as it is, when you make a change to the database, it's saved in the .RXDATA files, when the game starts up, it imports the data from these files into class variables so in a sense the .RXDATA files is a database of sorts, from my experience, so many problems arise from live I/O data feeds, it's best to import all the data from the file(s) and store it in variables

i do kinda understand your point but i only see it with mass editing and importing, a number of times i wished i could use my SQL Generation Program to create database entries for RMXP without having to do them all manually in the GUI since i use a slight mod in the program to help populate the Blizz-ABS Config file (got to love loops which generate line of code for you)

anyway, it is possible, RMX-OS does it....i think, i know it does it for user logins but it used a server i think, havn't looked into it that much.

azdesign

Data stored in scripts are hassle. Consider that I want specific item holds several status ailments. As the number of items grow, I need to add more and more of those items inside the script, but that wont be happen if I just create database for it. I've made many websites and apps before and having that experience, I can say that database are just cannot be separated. It is a need. Well, this SQLite I mentioned has very interesting feature, which is serverless and its database file can be saved anywhere without any install/setups (to access it at least). The point is how clients doesn't have to install additional software.

It is possible, the API stored in a gem and all I have to do is to use it. I'll try this and XML to see which one is easier/better. After that I might create the script and post it here later. Anyway thanks for sharing :D
~ Check out my deviantart http://my-az-design.deviantart.com/ ~

Blizzard

Technically the .rxdata files are databases, they just aren't using an SQL server nor are they in a format that is used in SQL. Instead, they are binary serialized object storages. They arrays you get are structured in a way that you can access each object through it's ID as index in the array which is convenient. But anything beyond that has to be done with plain old iterations (e.g. if you want to get a list of items that inflict a certain status effect).

But let me explain why an SQL database here is unnecessary. First let me separate the object oriented model (basically every OO language out there including OO databases, I'll get to that) and relational model (SQL databases and tables that represent data in a different way).
Single-user applications should use simpler ways of storing data. This includes either simple binary serialized files, XML, JSON, human readable formats, etc. Marginally you could use an object oriented database that stores stuff into a special format and has a special query language for data access and filtering, but let's not go too deep into this topic because the practical usefulness is really limited as you actually only get the downsides of both OO and relational models.
Multi-user applications benefit from properly structured data. The relational model helps here as lot because the data is minimized, there are no duplicates (at least in theory, but it's sometimes used in practice for performance reasons, let's not go too deep in there either) and the data model is well defined so every application actually connecting to this database can easily represent this data in different ways either using the OO model or in a completely different way. The main advantage here is that data can be interconnected between different users. If you would save stuff on a file-per-user basis, you would have a hard time connecting data between users or you would require special files for interconnected data. See where this is going? If you have a file for every user's save data and a special file for the buddy lists between players, you're already gearing towards a relational model (e.g. with tables to represent data, because tables could almost be seen as files). If a player deletes a buddy, you would only have to change one file in that case. Otherwise you would have to open both files and change the buddy list of both players. While that may not seem like much of a problem, there is the problem of concurrency. What if one of the players was currently saving his progress? Suddenly you get a whole new set of problems (which is called concurrency, SQL database handles that in various ways) for which normal files are simply not suited. But sadly, this advantage of using a relational model obviously introduces a lot of complications such as relational-OO conversions of data when loading/saving stuff (the database has a relational model with tables and such while in the application you have to use objects to represent data because the relational model is difficult to use in programming and data representation in programs).

RMX-OS is an example of this. Many users connect to one server and their data is actually interconnected. It makes sense to use a database here instead of just a lot of files that would complicate things way too much in the end. The more files you would have to keep track of, the more difficult it gets. SQL databases on the other hand offer you a simple, opaque way to work with the interconnected data without having to think about concurrent access or duplicate data.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

azdesign

September 13, 2012, 08:36:12 am #4 Last Edit: September 13, 2012, 08:37:15 am by azdesign
I understand clearly what you mean. How database in single user app isn't bring much benefits.

It just, when I made everything custom, for example there are more stats for character, every item has different effect for those new stats. Having a high specific stat will allow user to wield specific equipment, which can be obtained by combining ore, leather, etc. But when you look at the editor, there is nothing about the custom data. You cannot create, modify and delete that new item through there. The only way to change it, is to edit the script manually, to manually assign every variables, behavior and connections that item has. For example script for bestiary and quest log. You have to manually input every event description, goals, monster to hunt, etc in the script. And you have to do it through script.

The point is : I could make those data stored in the SQLite file, then I create a simple PHP page as its "editor". It would really ease my work and everyone using someone's custom script to add more items, add more stats, more quest log, monster book, add and modify any custom data. The game retrieve item data from database but, still saving game progress, items owned, current level, party, etc using standard save method.

Well, I'll just try it to find out :D
~ Check out my deviantart http://my-az-design.deviantart.com/ ~

Blizzard

You can still do that using just a simple .rxdata file as other scripters did.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.