If you don’t know coda.io it’s a collaborative document creation tool similar to Notion.so
We use it our my team for design documents, project management, meeting, etc.
With Coda Sync, we use a Coda document as a database.
A few interesting features:
each table generates a Scriptable Object class with the columns automatically creating properties (e.g. text → string, number → float, …)
each entry in tables generate an Scriptable Object instance
these scriptable objects can have a reference to another generated scriptable object (when using a lookup column) or an asset in your project (sprite, audio clip…)
Here is a link to all the information and the documentation:
Very interesting idea. How do you handle the case from my game designer where he says “I thought I changed that value in coda but it doesn’t seem to be different in my build”?
Will there be a way to expose the “version” of records (or “last refreshed” date from the Table importer perhaps?)
Also, I understand why you’d not want my production releases to load data live from Coda (extra network IO, values not changing often, etc), but during development, can I enable “launch time” and perhaps even “run time” loading and reloading of coda data so that my game designer can tweak the value in Coda and see it reflect in his build live on the device he’s testing from?
For your first point, it could be a good addition to show the date of last syncing !
For the second part, your game designer only needs to press a button in a SO to sync what he’s working on. I tried to make the tool as easy-to-use as possible for non-programmers to allow the designers to use it by themself. So I think they should be taught how to sync the data.
A “launch time” option could be interesting, but as we need to wait for the API response, I don’t know if it’s possible to delay the game start to wait for the data to arrive. Also, I can see some problems of someone forgeting to disable the option and the tool syncing invalid data because of someone else working on it at the same time.
And a “run time” option seems very unlikely to happen to me, as I rely heavily on Editor-only code.
To not require everything to be in Resources folders, I often use AssetDatabase class to fetch assets.
How is data transferred? Does it use a Json container or are tables plain CSV?
I‘m curious because I wrote a CSV reader/writer and importer so you can essentially do the same as your tool, except for using the usual Spreadsheet apps.
That does answer a lot of my questions – thank you.
My game designer likes to play the build on their device and wanted to change the behaviors around live (without having the editor). I’ve been integrating a quake like console where they can tweak exposed properties with a /setValue GOName.PropertyName=123, but that has the limitation that they need to have a keyboard.
I still very much like the design of your solution though.
Coda provides an API we are using: Coda API (v1) Reference Documentation
We had made a simple tool using Google sheets but one of the things that I didn’t like was the fact the data was not type. A coda table is a database so each column has a type and we use that to generate the scriptable object associated for each table.
We are also trying to generate enums but have asked a little update on the API so hopefully the API team at Coda will make this little change ^^’
I exactly know why they want that (game designer speaking here ^^)
It seems a bit hard to implement in a v1 but I do think that it is a very interesting suggestion!
My solution for that is either auto-detect the type from the existing values or (if table/columns may be entirely empty) prefix the header with a type. As in: first row defines the type (int, float, string etc) and second row the name of the properties/fields with third row being the first data row.
I see
well, that’s the advantage of using a database, columns are already type, and one column can be a lookup to another table (so a reference to another scriptable object in unity) or to the same table.
and being an online tool, it’s synced with all the users. That’s especially useful if you want to have some people in the team that don’t have the unity project (a client, a writer, …)
Last but not least, another interesting use case is to have other tables in the Coda document that are not used to be synced with your unity project, but to test the data or simulate player progress.
For example I have a project with some game data (items to buy, rewards) and I wanted to simulate how fast the player will be able to buy these items. So I made a table where I can test some game parameters (required success percentage to get 1 star, 2 stars, etc.) and the player skill
then for each played game I could see what the player gets: coins, rewards, etc. and what they could buy allowing me to see the player progression, based on the game real items
