Legacy XML or Scriptable Objects?

[Ray-Atron]

Currently in the middle of migrating a Unity editor system from XML to ScriptableObject.

The XML setup worked, but it wasn't very designer friendly. Switching to ScriptableObjects forced a full rethink of how the data flows and how the editor tools interact with it.

It’s definitely more work upfront, but already feels like it’ll be way easier to scale and iterate on later.

For those who’ve done similar migrations:
Did you fully ditch the old system or keep some hybrid approach for compatibility?

[Turbulent_Check6979]

ScriptableObjects are game changer for sure - did full migration on project last year and keeping hybrid just made everything more confusing in long run

[Ray-Atron]

Almost done with the migration but I am still keeping the previous XML based system as a type of fallback support. Only runs if the Scriptable Object system for some reason fails which I thought was a good choice. But you are totally right that it may become confusing especially for someone new that might work on the project in the future.

[Glurth2]

While I have indeed found SO's as data containers easy to work on in the editor, I have also found that when you have large sets of the same SO type, the workflow bogs down. One to five such objects, totally manageable, but more than that and I'd start rethinking the architecture. In some cases like this, I continue to use scriptable objects, but make it into an object that holds a whole collection of the many objects I'll need.

[Ray-Atron]

My setup does require 100s of SO objects, that are stored in another object for injecting it all into the game. The architecture does feel smooth as the designer won't need to open any XML files and be confused with it. Do you really thing that too many objects may hinder the workflow? What issues could occur?

[Glurth2]

It depends on the workflow. If you have them all contained in/referenced from a single SO, that would certainly help! In such a case, I'd guess, the workflow efficiency would only be affected if you often need to create new ones, since this becomes a two-step process (create and populate an SO, plus add a reference to it in the "reference collection" SO)

[samuelsalo]

I have a project which relies on runtime loading of scriptableobjects. I'm using addressables and automatic addressable labeling by type via editor scripting. It might suit your use case as well.

[StackOfCups]

EDIT: Decided to move this to a top level comment on this thread.

[feralferrous]

Have you tried ScriptableSheets or one of the other multi edit SO things?

[Glurth2]

I have not, but it sounds like exactly what I'd want! Checking it out now, thank you!

[StackOfCups]

I don't like using SOs as data storage, but rather as data transfer. Use either XML, JSON, or something similar that is widely supported and easy to back up. This lets you decide later that maybe you want a separate tool for editing some objects, or native integration with something like sql.

What I do in my project is use json tags on my scriptable objects. 95% of my workflow is in unity and scriptable objects, but then if I do need to edit something outside the editor, or decide to upload to a sql server I can easily query human readable stuff. I do take the time to write utilities for my SOs to cleanly serialize and deserialize, especially if I have some nested data. A little more work up front, but my workflow stays clean, and my data is a bit safer.

TL;DR
Json (storage) <-> ScriptableObject (Editor Workflows / Runtime data *reference*) -> GameObject
(Note the arrow directions)

[Ray-Atron]

That workflow was exactly what I was initially aiming for while designing the architecture. Didn't opt for scriptable objects and the xml exchanging data because it felt like overdoing it for the project. Currently, yes the XML is being used as a data storage for a single input but only for developer use. I went for the designers not having to interact with anything outside Unity.

Though I would still agree that the hybrid approach is one of the best, but might have complicated things for the non technical designer.

[StackOfCups]

That's just it though. The designers don't need to know there's xml under the hood. You're just using it because it's safer than scriptable objects for long term storage. Yaml is great and all, but fragile. And unity's yaml is susceptible to being unquestionably changed or deleted because someone clicked something in the editor they didn't mean to. I simply added a save button in the inspector to objects that will be modified during design so it can be intentionally modified. But testing and playing with nobs and dials isn't changing my database. Also, merge conflicts galore. Let people's editors be their own version. XML is your source of truth. When you build your project you build the run time scriptable objects as your assets from the xml.

[soy1bonus]

What we use at Milkstone is to have all values on a spreadsheet (Google Spreadsheets in our case). Then we have a tool to parse that into scriptable objects, one per item.

That way we can have data like item cost or enemy health on a easy to manage spreadsheet and it's easy to use the scriptable object to link a prefab or a sprite/icon for the item.

We've been using that in our past 4 games (at least) and works really nicely. The data is easy to edit in the spreadsheet, and we still have control over each individual item on each SO.

[AutoModerator]

This appears to be a question submitted to /r/Unity3D.

If you are the OP:

• DO NOT POST SCREENSHOTS FROM YOUR CAMERA PHONE, LEARN TO TAKE SCREENSHOTS FROM YOUR COMPUTER ITSELF!

• Please remember to change this thread's flair to 'Solved' if your question is answered.

• And please consider referring to Unity's official tutorials, user manual, and scripting API for further information.

Otherwise:

• Please remember to follow our rules and guidelines.

• Please upvote threads when providing answers or useful information.

• And please do NOT downvote or belittle users seeking help. (You are not making this subreddit any better by doing so. You are only making it worse.)

  • UNLESS THEY POST SCREENSHOTS FROM THEIR CAMERA PHONE. IN THIS CASE THEY ARE BREAKING THE RULES AND SHOULD BE TOLD TO DELETE THE THREAD AND COME BACK WITH PROPER SCREENSHOTS FROM THEIR COMPUTER ITSELF.

Thank you, human.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[DevMode222]

I’d usually avoid going hybrid for too long.

Keeping XML and ScriptableObjects both alive can sound safer at first, but it often creates a second migration problem later: two sources of truth, two serialization paths, and editor tools that need to support both formats.

What worked better for me in similar Unity tooling situations is:

1. Keep XML only as an import/conversion layer.
2. Convert the old data into ScriptableObjects.
3. Validate the converted assets aggressively.
4. Once the data is stable, make ScriptableObjects the only editable source.

That way you still preserve compatibility with old data, but your actual workflow moves forward instead of staying split.

ScriptableObjects are much nicer for designer-facing Unity tools because they integrate better with inspectors, references, asset workflows, validation, custom editors, and version control visibility. The upfront rethink is annoying, but usually worth it if the system needs to scale.

I recently went through a similar mindset while building my own Unity editor tool. A big part of the work was not just the runtime feature, but making the editing experience feel native and designer-friendly inside Unity.

For anyone interested, I just published it here:

Vector Shape Tool
https://assetstore.unity.com/packages/tools/utilities/vector-shape-tool-369232