Prefabs Phase 1

[iampremo]

Prefabs are the ability to reference one project from another, and only the assets used by the main project will be included in the game.

Any asset types will be allowed (though rooms may complicate this).

Prefabs may reference other prefabs (allowing for nested prefabs) but loops of dependencies are not allowed.

Phase 1 for prefabs will be the initial release with

• Tooling for adding prefabs into projects and only including the assets used.
• Integration with the Package Manager (which will deliver all prefabs to the system)
• Tools for adding prefab assets into your project within Room Editor / Sequence Editor. moved to Prefab Library #4681
• Working with early adopters to create local packages (invite only)

New format brief explanation

Example excerpt:

{
  "$GMProject": "",
  "%Name": "23_01_2024-game",
  "AudioGroups": [
    {"$GMAudioGroup":"","%Name":"audiogroup_default","targets":-1,},
  ],
  "configs": {
    "children": [],
    "name": "Default",
  },
  "defaultScriptType": 0,
  "Folders": [
    {"$GMFolder":"","%Name":"Sprites","folderPath":"folders/Sprites.yy",},
    {"$GMFolder":"","%Name":"Tile Sets","folderPath":"folders/Tile Sets.yy",},
    {"$GMFolder":"","%Name":"Sounds","folderPath":"folders/Sounds.yy",},
    {"$GMFolder":"","%Name":"Paths","folderPath":"folders/Paths.yy",},

All records are in ALPHA SORTED order, which is a requirement.

Typed records are indicated with a leading TYPE TAG and space for a VERSION.
The version will be "" until we start using revisions, then it will be v1 v2 v3 etc
These will always be first in a JSON record (they must be!):

  "$GMProject": "",

Objects with names will have a name field that is now called %Name to cause it to appear at the top
after the type tag:

  "%Name": "23_01_2024-game",

The formatting is better, and should give a better Git Merge experience.

Git Merge MIGHT become a support issue because the fields DO NOW NEED TO REMAIN IN ORDER.
But actually that might help!

Compatibility

To keep some compatibility with previous IDEs, we have reinstated the following fields
resourceVersion - will be pinned to 2.0; please use the TypeTag if you are requiring to operate on a specific version.
resourceType - tracks the same as the TypeTag; GMSprite, GMProject, GMObject, etc..
name - tracks the same as the NameTag

This allows older IDEs to open the projects in read-only mode, but support will start to deteriorate as new resources and changes are made, so you should make use of ProjectTool ( Tools->Project Tool from the IDE ) to fully downgrade projects to an older version if required.

For the sake of clarity, this covers:

• YYP projects
• YYZ archived projects
• YYMPS Marketplace and Local packages

[FoxyOfJungle]

Looking forward to this one.

[DAndrewBox]

Hopefully this would be implemented before 2023 LTS

[GameDevTosh]

At last, this is what I'm waiting for!

[Ceyase]

I need it!

[ahengine]

Please add Nested prefab too

[iampremo]

Please add Nested prefab too

Thats part of the design already ;)

[adam-coster]

@stuckie A downside of this new format, that I hope y'all will consider if it isn't already too late:

In the old format, all yy(p) files had a common key called resourceType, which made it really easy for external tools to figure out what the resource was. E.g. by parsing the file as JSON(ish), then just grabbing the resourceType value.

This is particularly useful to deal with file formats changing over time, because it creates a discriminated union. Schema validation tools (like AJV for JSON or Zod for JavaScript) can use discriminated unions to infer which variant of a schema to use when validating a file. But only when there is a shared key with known values.

If the format change just renamed keys for sorting purposes, rather than removing the common keys, I imagine that'd be about the same as far as GameMaker's parsing goes. But it would make it much easier to handle format changes for other tools.

{
  "$ResourceType": "GMProject",
  "$ResourceVersion": "1.0",
  "%Name": "..."
}

Any chance that's something that could happen, or is the described change a done deal?

[stuckie]

Is there anything else that your tools would need/like that we could change just now?
We will likely split the resource tag back out again, and we don't really want to change format output again - at least not for a long while!

[adam-coster]

@stuckie I definitely understand not wanting to change it! I spent all day yesterday updating our tools for the new format, and I imagine y'all have to deal with a lot more consequences of project format changes than we do!

Even though we've already updated our tools, having the known, constant keys is still preferable even if I have to redo a bit of that work, so I welcome the change.

I don't think there's any other change I'd really be looking for.

[stuckie]

We have added resourceVersion and resourceType back in.

The resourceType field will track the same as it always did - GMSprite, GMAudioGroup, etc..
The resourceVersion field will always be 2.0 - this stops previous over eager IDEs from trying to load it and making a mess.

So, because the versioning has changed, if you do need to rely on what version a resource is, you are best parsing the new top tag.

[stuckie]

Just to keep the chain updated, we've re-added the name field too, and I've added a Compatibility set at the bottom of the original ticket to explain this.

[adam-coster]

@stuckie I wrote up a separate issue asking for some guidance on formatting:#4713

[backYard321]

Can't wait for this!

[Emc1923]

Verified support added internally.