Forums » Impact Engine » ImpactDB

Something I've been developing for one of my games and I was curious if it would come to use for anyone else. If so, then I may just continue it's development a bit further.

Simply put, this is a plugin that stores/retrieves data from the plugin itself. The data is stored in an array and, with the functions it provides, you are able to instantly retrieve, add and modify this data from in-game.

It works in a method VERY similar to MySQL queries and such, just a LOT simpler. Each database that you create has as many columns as you want, that may be titled whatever you like.

If there is a decent interest in this plugin, I am willing to go further and develop this to have its own web-interface for easier data editing. I've already got functions for getting/retrieving and modifying data; all that remains is adding/deleting data.

I figure that this would have a lot of use for people who aren't too fond of incorporating any other external DB with their game as it requires 3rd-party functions and such. The joy of this DB would be that it is all internal and fast, and by using a plugin like Prefix you can change where your data files are stored, therefore allowing you to store them outside of the root directory which is inaccessible by anyone without server access.

sounds brilliant!

Sounds great, I'd like to see a demo. Especially if you develop the web interface for managing data.

be nice to store it in local storage as well with some obsfucation ..

I'm curious where the data will actually be stored - either it's stored in localStorage (or maybe one of the other *storage backends in the browser) or it's on the server, in which case it either runs as its own process (and all the foibles of getting through firewalls on non-standard ports) or it runs through PHP or Node.js or similar, which does seem to limit its usefulness :/

I'm glad to see there's an interest in this idea. It's definitely something that I will get running - I'll post a demo of it on Git when I have most of the functions complete and it has full functionality.

@paulh
Encrypting the data would be a unique concept, in terms of obfuscating it in local storage. When I get the demo done, we can always look over the final product and possibly add a function for it.

@Arantor
The files are stored server-side, one file per database, and are only read once when your game loads. Once they are read, the data is stored as a single array that is easily read, broken up and searched through by the functions that come with the plugin to return the exact value you are searching for. The only time that the data is ever saved/read again is if you edit the data, add to it or modify it, in which case you're still only editing the arrays. There is another function which will actually save the data back into the data-files.

So as far as it being slow, or taking awhile to read, it reads the data as fast as your browser can open a standard txt file, and saves faster than MySQL. There are no extra processes that are needed to run this, it is purely an ImpactJS plugin, that only uses Ajax/PHP to read/save the data when you need it to... I guess in that case, it would only be slow if you are constantly saving the data, but even then all you're doing is saving a basic data file on the server so unless your database is HUGE... it shouldn't be slow at all.

Using a file based storage, you say? What happens with two concurrent writes? Proper exclusive locking? What about authentication? Can a user poison another user's data?

Also, do note that MySQL is not the only solution for persistent storage, and it certainly can be tuned. That said, I'm very happy using MongoDB for my persistent storage for such things, because that IS faster than even using file based storage, seeing how it's memory-mapped and all ;)

And how does that work out when you're using Node.js as your main platform? Please don't tell me you're forcing it to create a PHP session on top of Node.js... because there is no way on earth it's going to be faster that way.

I'm sorry if I sound really snarky, I'm just very wary of any time anyone ever writes such things because invariably it ends up being a mess.

Its all good, I understand that people may have there doubts. As far as how it all would work, yes it would be with a php call but that is simply to write the file when saving the data. Until then, all data stays internal as various arrays and such. The main reason being that I am writing this to serve a simple purpose that doesn't require constand saving. It is not meant for any 'communication' whatsoever and therefore would not have concurrent writes.

The basis for this system is just to store gamedata, such as item values, entity properties, level information, etc... not anything that needs to be fussed with constantly but basically a place to store data in ONE place versus hardcoding it into entities and levels and such. This way, to change a value of an entity, such as health or something for the while game, I can open one file and change multiple entities at once versus navigating to multiple different files and searching for the variable.

The reason behind this is for games that are very item-dependent or stat and setting driven. I'm sure there could be thousands of other uses as well, but thats up to anyone else thats interested in the system.

As far as another way to write the data, I'm open to any suggestions - I've got this attempt on pause at the moment, but I do plan on continuing the work on it to see what I can come up with. As it stands, it is already fully featured minus the ability to save new data with the code. In other words, if you build the data file manually, you can pull any information from it instantly, ^^

It is not meant for any 'communication' whatsoever and therefore would not have concurrent writes.

Um, if you're running this on a webserver with two people playing the game, how would that not have concurrent writes for any kind of saving? Unless you somehow uniquely identify each user? Even then, what's to stop people poisoning (accidentally or otherwise) others' game data?

I'm not even talking about an RPG of sorts, but if you have this going on in a production web server, you're going to run into this problem.

If you're going to use the system to save users data, then yes, there would be multiple concurrent writes all the time, but I'm not planning this for user data. As I said, I am only planning this for mainly reading static data.

I understand what you're saying, and I am completely aware of that fault but there isn't much that can be done against it. Thats why I'm proposing this be a system for simple static data... it would take a while to explain my full intent for this system.

hmm, if you're going online, why not just use Parse? saves a ton of time, is reliable and there's no re-inventing the wheel

json localstorage arrays or mongoDB
case closed? :-D

@Heartless49
I'm not sure why you can't just use the other solutions mentioned. Are they missing something that your spec needs? Personally, I'm a fan of local storage, for which impact has a great plugin. For server-side stuff, mongo is just as much of a joy to use. I agree with you that SQL feels a bit old-school, messy, ugly. But with those alternatives in place, how necessary is it for you to create your own scheme?