Sharing Data between Game Devs & Designers

Dyon Ng - March 21, 2025

We’re developing a roguelike deckbuilder game, Runeborn, that requires hundreds of items, dozens of enemies, tons of dialogue text, and tooltips.
And we need to get all of this, constantly updated, frequently edited, data into Unity for our semi-daily builds for playtesting and review. While we developers probably prefer a database for all this stuff, our Game Designers and Artists prefer to use more accessible and familiar collaborative tools.

So for Items, Enemies, Boss Mechanics, etc., we’re using Unity’s Scriptable Objects for data storage and custom functionality. This allows our Technical Artist to manage art assets and more quickly make and preview changes within Unity, and since he’s technically inclined, easily use Git to version manage changes.

For a lot of our game balancing values, we actually use a Remote Config (JSON). This allows our Game Designers and Playtesters to make changes on the fly and instantly be able to test them without a new build. This can include item values, our randomness weightings, enemy health, level and shop values, and even starting player stats. We’ve used Firebase, Azure Playfab, Heroic Labs Nakama, and other game services in the past, but this time around, we’re sticking with Unity’s Remote Config since it’s a first-party add-on with an Editor package. Once values are finetuned, they actually get baked into the game so that Production-level builds don’t require the internet, allowing for offline play.

But for the rest of the actual item details, enemy names and descriptions, tutorial text, etc… Our Game Designers actually like using Excel, or Google Sheet actually (We’re on Team Google Workspace). By using Google Sheets, the barrier to entry for game design is really low and more people can help create new items and game ideas. We can easily create data visualizations and edit from anywhere, even on your phone. The only problem is getting all of this data from Google Sheets into the ScriptableObjects and Prefabs in Unity, but we have a solution for that!

As many Unity Game Devs know, ScriptableObjects, Prefabs, and almost all of the User Created Files from Unity are serialized in Unity YAML, and manipulating values outside of Unity is possible. And while I don’t recommend editing scenes or prefabs outside of Unity… ScriptableObjects files, on the other hand, are quite straightforward to edit. In fact, there’s even a Python 3 Library, by socialpoint-labs on GitHub, to manipulate those files.

Simply put, we have a script that runs and syncs all of our ScriptableObjects with the data from Google Sheets. But I’ll go into some more detail about how we have things setup and what steps we do during these scripts:

• We download the Google Sheets. You can do this manually within Google Sheets, or via Google’s API through a Service Account.

• Then we run the script; we’re actually using a NodeJS setup, but Python or any other scripting language is fine, we’re just experienced with NodeJS and Typescript:

• Multiple Shop Types: Explore and strategize with various shop offerings to enhance your build.

• Load the Google Sheet, which has a bunch of pages/sheets inside, each with different tables of data.
• Each page/sheet gets its own custom parser/formatter, just in case something needs custom functionality.
• Parse the rows of the data tables and create Lookups using IDs. Our ScriptableObjects will have a matching ID.
• When we iterate over the ScriptableObjects, we search for their IDs in our Lookups and if there is a matching record, we can use it to sync the data.
• BUT, BEFORE WE SYNC THE DATA: We can take this opportunity to sanitize and format the data so that our Game Engine doesn’t have to do it live during runtime.
• We run Keyword Matching and Regular Expressions to take the raw text from the Game Designers and convert it into RichText for TextMeshPro. This way, certain keywords can be bolded or have different colors, etc.
• A lot of category data is stored as Strings in the Google Sheet because it’s more human readable, like Item Rarity, Tags, or Tooltip Keywords, but that would be inefficient to store and manipulate within Unity/C#, so we also take this opportunity to convert those values into our internal Enums.
• Then we just write the YAML. As long as your formatting is consistent, it should be Git friendly and easy to review.

For our NodeJS setup, we’re not doing anything fancy:

• Just using SheetJS to ingest the XLSX file

• Axios for web requests

• Dotenv for client side secrets

• and JS-YAML for the asset files

Other than those, it’s vanilla NodeJS libraries. And if you want to get extra fancy, you can have all this stuff running in your CI/CD pipelines whenever you go to make a build, merge a PR, etc.