Create an abstracted resource database/query API with text/visual scripting and editor visualization support. #37
Replies: 2 comments
-
Not sure whether you're aware already but worth to link, there's a Godot PR godotengine/godot#37070 which adds basic SQLite support as a module. Not abstracted, but that's a step forward. This repository seems to provide proof-of-concept for generalized database API. |
Beta Was this translation helpful? Give feedback.
-
Given aaronfranke's latest comment on it, I doubt it will end up becoming a core-integrated module. There isn't really a proper justification for it being included in core versus just a GDNative addon aside from "GDNative API/platform compatibility is poor," and that isn't a good enough reason. still, as a convenience factor, it would be quite nice. |
Beta Was this translation helpful? Give feedback.
-
Context
Wanting to write a highly data-driven simulation game with systemic narrative design. Heavily relies on Resources.
Problem
Godot has no concept of a database-like interface for resources. There are SQL databases and document databases that can be used in tandem with Godot, but nothing that is designed to work with and around the Godot resource data types or with integration into the Godot Editor GUI.
Suggestion
Create a module with an abstracted resource query service API. Various implementations of this query service could be written for different data stores (flat-file database, single-file embedded resource database, SQLite, MongoDB, CastleDB, whatever). The Godot Editor would provide a visual and scripted means of creating queries on the resources in the system. Users would be able to register handlers that operate on specific types of resources whenever they are saved/loaded/deleted. A spreadsheet visualization could then render the data within the Godot Editor.
Solution
The inspiration for this concept largely comes from YesSQL which is a brilliantly simple C# library for creating a document database using many common SQL databases. I would want a C++ implementation that is not reliant on C# though, or even SQL (abstract further to support even more variation in interfacing with the data store).
If it was designed flexibly enough and was easy enough to use in the editor and scripting, then you could reach a point where most EditorPlugins and assets provide integration support for the module. And if that happened, perhaps the module could be added to the core (though, not sure about that).
If we were to make it a plugin rather than a module, then we'd need to refactor editor tools to be distributed separately that way a spreadsheet interface could create instances of specialized editors in its own custom GUI code, without reinventing the wheel.
Beta Was this translation helpful? Give feedback.
All reactions