koobas.hobune.stream
Local database method?
In our upcoming game we have about 100 levels with different characteristics (some are mini-games, some give more points than others, some unlocks others etc). So far I've been storing the values in an array which is structured via a class and built upon start. It works fine but I was wondering if there's a more clever way (iterate through an external xml at start perhaps?).
One benefit I'm looking for is to have a table structure of the database to be able to edit and view it in an external program. What would be easiest to use in this case?
Anybody who has experience in handling information with lots of data for Unity? - Not looking for code but only advice in which direction to go.
It's not possible to add bounties anymore to questions right?
@save it's probably worth opening a thread on the forums for the advice thing.
@ChrisD Yeah you're right, this ends up in a quite broad topic.
You could try using SQLite. Especially if you're coding using Javascript (or if you're not, if you can throw your javascript into the plugins folder and not have any other plugin scripts call it), it's fairly easy to integrate SQLite into your projects. You may have to copy some DLLs around to get it working, but it's pretty easy. Do some more research if you want to implement it in C#, as apparently there's a little bit more moving stuff around to get dependencies to work.
As someone with zero knowledge of database stuff, it took me an hour or two to figure out how to get everything compiling, then a few more hours to learn how to play with SQL databases, but it wasn't TOO painful. I'm using this code:
http://forum.unity3d.com/threads/28500-SQLite-Class-Easier-Database-Stuff
and I think this post was helpful to get things set up? I should make a good guide on the wiki...
http://forum.unity3d.com/threads/7866-Unity-and-Sqlite
At any rate, then it's easy to mess around with your database (which in SQLite's case is just stored as a local file) with this program:
Of course, you HAD to go and comment about a wiki page, so I had to make one ;) At any rate, here you go!
http://www.unifycommunity.com/wiki/index.php?title=SQLite
Please, though, if you want to try this out (and haven't already messed around with any of the SQLite stuff), if you could follow the instructions exactly and let me know how it works, it'd be super-helpful. I built the instructions around starting with a blank project, but of course I've also installed various SQLite stuff as part of trying to get things to work in different ways, so if you could confirm that the instructions work on a virgin machine, it would be super-helpful for the guide.
You're welcome! I figured I should do it while it's still fresh; I'm just starting up with it myself, and I figured it'd be best to extend and share the GUI stuff I've been building before it gets loaded up with a bunch of stuff that's my-application specific. I'm also really glad it works with a clean build - maybe I'll figure out how to put it together in C# (since my project is mostly in C#, and I don't want to waste compile time by having a bunch of code in my Plugins folder..)
What do you mean, exactly, by 'in a build, access the database'? Are you talking about getting and setting entries in the database as your program runs? I suppose the dbAccess class isn't really fully fleshed-out, and has no nice Update function lying around, but to read individual data in your application, you'll want a script with a dbAccess variable, and then you'll make calls on that dbAccess object to access your variable. So you never have access to a singular database object in your game; ins$$anonymous$$d, you've got scripts that have accessor objects that allow you to run SQL commands on your database, whether it's with pretty commands like dbAccess.SingleSelectWhere(...)(I added an example usage to the comments in the code) or whether it's with the ugly but general purpose dbAccess.BasicQuery(...). But please clarify if that's not what you mean. Although, now that you mention it, at least a link to the $$anonymous$$SDN references about IDbCommand may be useful to help figure out how values are returned by the commands.
Thanks so much for looking more deeply into this than I have! I wouldn't have thought to make an actual build, and it turns out the current instructions weren't actually compiling into something that worked. It turns out that what I thought was pretty basic in Javascript is a bit more finicky than I originally thought. I've updated the wiki, including a $$anonymous$$or update to the code. On the plus side, by importing $$anonymous$$ono.Data.SQLite ins$$anonymous$$d of SQLiteClient, it can find the DLL and you don't have to move it yourself.
As for full builds, on the downside, I did find that in order to get builds to work properly, you need to go download sqlite3.dll from the SQLite people and put that into your plugins folder. It results in me getting a license error, since I only have Indie, but it still seems to run just fine. Not surprising, maybe, since in the editor, you don't have to have sqlite3.dll in your project folder for everything to work. And, lo and behold, it doesn't stop me from compiling a stand-alone build that works (but that build only works if I have sqlite3.dll in my project's Plugins folder).
But, you don't have to do any manual moving. So long as you have sqlite3.dll in your project's Plugins folder, it'll spit out a working application. However, I haven't looked into how you'd go about packaging that with an existing database to read from - my example application creates a new database the first time it's run, and from then on, it's persistent across sessions. So it's ideal for savegames, or I'm using it to import outside databases from a different application, but you may need some sort of external installer which will package the stand-alone build together with any initial databases you'd like the program to load from on it's first run.
So it's working smoother than ever now, but I need to ask some questions of my own I guess to figure out this license/build issue...
I did figure out an alternate work-around for putting SQLite3.dll in the plugins folder and getting a licensing error. If you copy sqlite3.dll into the same folder as the .exe file of your build, your application will find it and run correctly.
