Generating .unity files via external scripts

Questions & Answers
1

TL;DR: I want to use an external script (which will run for a long time) to automatically generate a YAML .unity file, which I will then use in the editor for further, manual editing.

Expanding:

What I want to do is similar to procedural generation, in that I want an algorithm to make a few calculations and spit out a level for the game. However, there are a few key differences, which makes approaches such as an in-game script unviable. Here are three of them:

  1. I want to create a static level, not something that will change every playthough;

  2. the algorithm for the level-building is complex, and the levels I want to make are very large, which means the script will run for too long for the player to wait it out every time the game is booted;

  3. I want to be able to manually edit the output level in the Unity Editor, so I can handcraft a few features in it, as well as playtest it.

My first idea was to write a Python script for the generation, and have it spit out a YAML .unity file which I could then open in the editor to check the resulting scene and keep on editing whatever I needed. After looking around a bit, I found out that apparently this isn’t such a good idea because,
among other things, manually messing with the serialization number (the one with the ampersand) in .unity files is a big no-no.

My question is: what else can I do?

My question is different from this one because, like I said, I don’t want the .unity file to be used in-game (in fact I know that can’t be done), I want it to be used only during development.

Thank you for your time.

2

this isn’t such a good idea because, among other things, manually messing with the serialization number (the one with the ampersand) in .unity files is a big no-no.

@DaniloCaldeira I’ve been curious about generating these .YAML files externally as well, but have yet to make any attempt. What issues were raised for generating objectIds (like “&4321”) in this approach?

Unity’s specification suggests “the number is unique within the file […] assigned to each object arbitrarily”, so I’m not sure it has anything to do with the serialization properties.

I would figure emulating the unique objectids would “just work”, as long as you maintain two-way referencing between objects and their scene components throughout the .YAML:

--- !u!1 &4321
GameObject:
  m_Component:
  - component: {fileID: 876}

--- !u!114 &876
MonoBehaviour:
  m_GameObject: {fileID: 4321}