ฝัง
- เผยแพร่เมื่อ 18 ต.ค. 2024
- With the SQLite plugin unavailable for Godot 4 (temporarily), implement LiteDB for storing game data in GDScript & C#. Single file database, so no need to implement a full server-based database.
LiteDB page: www.litedb.org/
LiteDB NuGet package page: www.nuget.org/...
LiteDB Studio: github.com/mbd...
Nice tutorial. Glad somebody finally did some kind of SQL + Godot tut
Thanks! Indeed, a game is definitely a place you might not always want a fixed schema :D
This video is relevant to my interests.
22:30 - you just magically pull that up out of nowhere! Actually launching the viewer is what I have been trying to figure out all day... I know this video is a lil' old, but if you could explain how that works, I'd be eternally grateful!
EDIT: ah, I figured it out... had to go to the Code -> Tags -> Releases in the repo and download the executable. I was trying to run it having cloned it... silly me. Nevermind. Helpful video otherwise though! I am just getting started trying to use nosql and this is a handy reference for getting started :)
Yeah, it's just a little separate app, which I have since found to regrettably be a little buggy. But the link to it is in the description 😊. It is lacking in being obvious from the LiteDB page though, I sometimes go back to searching for it explicitly 😅
@@Holonet01 I have things working fairly smoothly now, concerning viewing the database content through the app and actually inserting/querying/deleting in the code! Hooray :)
Something I noticed is that if I try to store a List in the database, it becomes a System.Object[] when I pull it back out... do you know if there is any way to easily rectify that? That type change disrupts my code in other areas.
You have the code when you pull it back out? My first thought, if in C#, is that it needs to be cast/converted, being a strongly typed language. Also, are you literally passing in a list of "object" and not a class you've created or existing type? I haven't tried that, but that would be a bit weird, I think.
As a side note, this video shows how to pass the data between C# and GDScript if you really need that, but if you don't, then it's more straight-forward to just stay right in C# and talk to the database every time you need it. The Final Fantasy 6 / LiteDB tutorial is an example of that way of doing it. Shoot if you have other questions though.
@@Holonet01 technically what I have is a transfer object - a class with just a handful of class variables - that I am sending to an Insert() method call to be written to the database. Those class variables have types of List.
When I then Query the data back from the database, I think what happens is the surface level data is retrieved as a List, but if that List contained further List objects, THOSE objects are represented as Object[] upon querying. Same goes for if I had stored a dictionary containing a list, it is now a dictionary containing an array.
I have a bit of middleman code between my query and the rest of my program responsible for going through and recursively re-assigning the Object[] to List, which seems to be working. It's not too bad, though it is a bit of a chore.
Great Tutorial thank you~
No probs =D
Its a lot like working with SQLite - thank you!
Yep! I'm sure the same process could be applied. What actually drove me to figure this out/make this video was wanting a simple database, but the SQLite Godot plugin is only for 3.x. Picked LiteDB because I wanted to be more familiar with it, and also have a flexible schema, since over the course of making a game, there's a slight chance things will change xD
Wow, great to see such tutorial!
Thanks very much!
Thank you!
With unique names on nodes, are they game wide or just scene wide?
Just scene. I imagine game-wide would probably be problematic, as the editor would need to check to be sure you didn't duplicate a name, and when the game is run, the node with the name would have to be loaded in the scene tree or it'd throw an error, and to handle that, I think they'd need to force it to autoload or something, etc...
If you're trying to access something like that, there are a few ways that make sense depending on the purpose, if there are multiple, etc... You could get an instance of the scene, and then get a property/singleton/whichever, or you'll see me use static variables a lot, and set their values in the Ready() method. This works fine if you only have 1 of the thing you're after.
nice vid! :D
Thanks much!
Why are you doing get_node(".") instead of this? Also why not just use %Stats and %HPLabel?
Good questions! Regarding get_node("."), I don't believe "this" is a GDScript keyword, but that should be fine if it came up in one of the C# scripts. As for just directly using %Stats or %HPLabel, they are on the Player 1 scene. The player is saved as its own packed scene, and it doesn't work to grab a unique name within a packed scene (or "nested" scenes might be another way to think of it).
Additionally, I think this is by design and how we would want to do it. Example being if you're in a manager script and you have generalized code to manipulate the "HPLabel" object by name, then you'd create any characters with the same naming convention, but if you tried to do get that HPLabel object in a scene with multiple characters, it would return multiple results if grabbing that name without specifying within which character first. One "could" certainly just get said characters and iterate, but I imagine this setup makes it harder to create a non-unique name.
@@Holonet01
"I don't believe "this" is a GDScript keyword"
Actually its self, I always get that confused because I don't much like python syntax but in either case self is in fact a keyword that does that. Also there is no reason to do get_node(".") anyway since all calls intrinsically refer to self if they don't refer to a static function call.
"As for just directly using %Stats or %HPLabel, they are on the Player 1 scene. The player is saved as its own packed scene, and it doesn't work to grab a unique name within a packed scene (or "nested" scenes might be another way to think of it). "
What? Scenes are made specifically for the purpose of referring their internal nodes and %/$% references literally just use get_node under the hood, %HPLabel and $%HPLabel are both literally just performing get_node("%HPLabel"), they're the same call. (technically they perform get_node(^"%HPLabel") but literally those are just syntax sugar for statically referenced nodes in Godot, they do the same thing)
"but if you tried to do get that HPLabel object in a scene with multiple characters, it would return multiple results if grabbing that name without specifying within which character first."
You can't give conflicting unique names to something in a scene, and should never expect to get something by unique name outside of that scene without referring to the nodes of said scene. If the characters are a scene you can't intrinsically reference their unique nodes without referencing to one of scene containing nodes, unique nodes are scene unique. If the characters aren't a scene that poses a larger question on why? That in itself will create a massive mess, you should always call down to the scenes, let the scenes handle their internal logic separately with call downs and signal ups.
Yep, you're right. Sorry, misunderstood why you were asking about the HPLabel call and such. So the way I remember messing with this at first, I was, indeed, expecting get_node() to be intrinsic and not require this/self/get_node("."), and was getting an error, and got it working with get_node("."). In retrospect, that might have been an alpha build bug or a me bug where I did something else and didn't realize it wasn't the cause of the problem. Either way, thanks for the input :).
@@Holonet01 No prob, I don't recall experiencing anything akin to the get_node("%HPLabel") failing on my local builds (tbf I didn't touch the alpha builds and didn't perform many constant tests on my builds until alpha 12 or later so I very well could have missed that problem in an earlier build) and if that was the case it most certainly was a problematic bug and nothing to do with what you expect from the engine, probably to do with GDScript 2.0 being a bit buggy.