Add DataTables to Redot

[RadenTheFolf]

Describe the project you are working on

A data driven game making heavy use of csv files for storing item info

Describe the problem or limitation you are having in your project

Having to leave the engine to manage item data as well as needing to convert csv files into values that can be used in engine cause unneeded steps in both the development process and in the loading and processing of the information.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

DataTables would bring the ability to manage and interact with information that would commonly be placed in separate csv files into the engine removing the need for data driven games to have their data managed elsewhere.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

DataTables will utilize the existing dictionary type in Redot and provide a GUI within the editor to manage the objects placed in this dictionary. You would define a structure for the data using the GUI as well as insert read update and remove items from the table which follow the defined structure within the GUI.

Items should be read from the table in gdscript calling a function like the example here:

var MyItem = MyDataTable.get_item_by_id(1)
var MySecondItem = MyDataTable.get_item_by_column("Name", "Item2")

Example GUI:

The lower section would list out the data rows stored in the table

If this enhancement will not be used often, can it be worked around with a few lines of script?

Due to the complexity involved there is no way to simply implement this feature in just a few lines of script

Is there a reason why this should be core and not an add-on in the asset library?

While this could be made as an addon implementing this into the engine would provide an out of the box solution to issues faced while developing data driven games.

[SkogiB]

Sweet, sweet data tables..........

[Frontrider]

This addon is why I'd not do it. There are so many different levels for this, that the integrated version may just become something you don't need/can't use.
https://github.com/radubolovan/Godot-Database-Manager

Official addon is the way to go here, like how Godot wants to, but is not doing a terrain.

[RadenTheFolf]

This addon is why I'd not do it. There are so many different levels for this, that the integrated version may just become something you don't need/can't use. https://github.com/radubolovan/Godot-Database-Manager

Official addon is the way to go here, like how Godot wants to, but is not doing a terrain.

This isn't aiming to replace databases or interface with them its meant to be an in engine interface for managing properties of items within data driven games. While there are many ways to do this data management is an issue a lot of developers deal with in one way or another.

Data tables are useful mostly because of their familiar nature. Every developer is going to be used to the table format. Whether its a database, csv, json or even just the use of in engine dictionaries defined in files, we tend to structure our data into tables.

Even if you want to use something different than having datatables being stored directly to files. the interface provided and api created to work with them could be expanded on by other addons to allow integration with an external database or other solution that utilizes table structures.

Having a centralized interface and api that can be expanded upon to support different endpoints like SQL, NoSQL, on disk, or in memory table based datastores, I believe will provide a more intuitive experience for users regardless of the storage technology they choose to use.

[Frontrider]

Having a centralized interface and api that can be expanded upon to support different endpoints like SQL, NoSQL, on disk, or in memory table based datastores, I believe will provide a more intuitive experience for users regardless of the storage technology they choose to use.

That is a good idea. I'd make it an external addon, that is in the official repo with a label.