Proposed RFC Feature - Removal of Slice Mode for level editing in the O3DE Editor

[AMZN-daimini]

Summary:

We propose to remove support for editing legacy .ly level files and slices in the O3DE editor.

What is the relevance of this feature?

Our objective is to simplify the codebase, remove unused codepaths and legacy classes, and overall improve build speed and performance of the engine.

Using slices for levels and gameplay entity instantiations have been a possibility since the first O3DE release, but it has always been highly discouraged as the new prefabs system was intended to replace slice functionality across the editor.

With the addition of prefab overrides in the latest release, the prefab system provides all features to replace the slice system for uses pertaining to level editing.

Feature design description:

The Editor currently allows users to select which system to use for level editing.
Slices are the legacy system used in Lumberyard. They store levels and entities as xml files that are hard to diff and edit manually.
Prefabs are the new system introduced in O3DE. They store levels and entities as json files that can be easily handled by version control software like git
Slices are still actively used by the UI Editor, but the editor has been defaulting to Prefabs for level editing since version 21.07. Slice support for level editing has only been provided as a toggle for backwards compatibility while prefabs reached feature parity with slices.

We propose the removal of the ability to switch the Editor to slice mode in the context of level editing.
This will allow us to start removing editor UI and classes that are only used when the editor is set to slice mode.

Note that this effort doesn’t include the removal of the Slice system and backend classes, since they are still used by the UI Editor.

Technical design description:

This work will only entail removal of legacy code, and minor changes to system classes to remove unused codepaths.
Systems that still rely on the slice system will not be affected, for example the UI Editor. Work to convert the UI Editor to use prefabs would have to be part of a separate RFC.

What are the advantages of the feature?

Reduction in build times.
This change will result in the removal of at least 15000 lines of code from the codebase, which will reduce build times.

Improvements in onboarding for new developers.
When inspecting the Editor’s code, new contributors will require less historic knowledge of the legacy systems to recognize what is current and what isn’t, making it simpler to identify the source of issues they encountered in the Editor and ease bug-fixing.

What are the disadvantages of the feature?

Loss of backwards compatibility in editing slice levels.
Note that we have been recommending users to move to prefabs since the early days of the project, and would still have had to convert slice levels to prefabs to use some of the new Editor functionality. Support for converter code/plugins is still possible since the core slice code is still available in O3DE right now.

How will this be implemented or integrated into the O3DE environment?

This change can be implemented via incremental steps as follows:

• Removal of the slice mode setting from the editor preferences / cvars and changes to the queries to always return true for prefab mode;
• Removal of the slice-specific code in the editor (mostly implemented via if/else statements across the board);
• Removal of the layer functionality, which is no longer supported in prefabs;
• Removal of the SliceFavorites Gem;
• Removal of the level exporting system, which is no longer needed with prefabs;
• Removal of the API to query for prefab/slice mode activation (or likely removal of the logic, while leaving the shell that returns a fixed value while deprecating the API)

Are there any alternatives to this feature?

An alternative would be to not move forward with this change and wait for prefabs to be supported in the UI Editor before removing slices all at once. I believe there is value in approaching this in steps though, so starting this early would prove beneficial to the community.

How will users learn this feature?

We will communicate this change to the user base on Discord and in the Release Notes for the version of the engine that hosts this change.

Are there any open questions?

This change should not affect current efforts to provide users with a converter to turn Lumberyard slice levels into O3DE prefab level files, as the slice system’s backend APIs will be unaffected. Developers should ensure that is the case in every step of the effort.

[AMZN-daimini]

Data regarding the amount of lines of code that would be removed with this effort was collected via this PR:
o3de/o3de#17480

I verified the Editor builds and works as expected after these changes. These changes do not care to deprecate APIs though and go for direct removal, which may not be the best approach; that is why I rounded down the estimate. There's probably other code that can be removed on top of that, especially around context menus generation and slice-specific UI functionality that may have been missed in this sweep, so I can see the total to be near 20000 lines.

[KylerBessert]

@AMZN-daimini I saw the post on discord, with the removal of slice mode, does this also remove all parts of Slices? I know there is a gem for slices you can enable/disable for projects, though I do not use it and am fully using prefabs, I am curious if this gem is getting removed with this refactor? If so, will projects that use slices and upgrade their engine to this change will any issues persist, or will it be a smooth upgrade for those projects?

Thanks,
Kyler

[AMZN-daimini]

Hey Kyler!

@AMZN-daimini I saw the post on discord, with the removal of slice mode, does this also remove all parts of Slices?

No, this would only remove the Editor UI related to editing slice-based levels.
Some other tools still use slices under the hood (LyShine/UI Editor is one example) and those will be unaffected.

I know there is a gem for slices you can enable/disable for projects, though I do not use it and am fully using prefabs, I am curious if this gem is getting removed with this refactor?

If the Gem you are referring to is Slice Favorites, yes.
Every other part of the Slice system is currently part of the core engine as far as I know.

If so, will projects that use slices and upgrade their engine to this change will any issues persist, or will it be a smooth upgrade for those projects?

For projects that use slices for levels, this would be a hard cut. An editor built after these changes are implemented would be unable to open their levels.
There is an effort ongoing (o3de/o3de#17478) to implement a slice-to-prefab level converter. So users would have to use that converter to port their slice levels to the prefab system. It's possible, but I don't expect it to be the smoothest of experiences.

To my knowledge, pretty much everyone uses prefabs right now. I could not find many examples of slice usage on the Discord, nor recent bug reports related to slice functionality.

@Ulrick28 since this is a clear functionality cut, regardless of the adoption... should we wait for the next main release before doing this work? We may just add to the release notes that 24.05 (or whatever the name) is the last main release to support slices for level editing, and that the release contains the tooling to port slice levels to prefabs. So a that point 24.05 would be the last version to support slices in levels, and 24.11 (or whatever) could be the first release without slice support for levels.

In terms of work, I would only need to wait for the stabilization branch for that main release to be cut before starting to push this work to development.

[Ulrick28]

As far as I am aware, no one is using slices and we had already performed some removals making it difficult to use a slice in O3DE. The only reason we have kept slices around is due to the LYShine runtime UI editor.

…

On Thu, Mar 7, 2024 at 2:23 AM Danilo Aimini ***@***.***> wrote: Hey Kyler! @AMZN-daimini <https://github.com/AMZN-daimini> I saw the post on discord, with the removal of slice mode, does this also remove all parts of Slices? No, this would only remove the Editor UI related to editing slice-based levels. Some other tools still use slices under the hood (LyShine/UI Editor is one example) and those will be unaffected. I know there is a gem for slices you can enable/disable for projects, though I do not use it and am fully using prefabs, I am curious if this gem is getting removed with this refactor? If the Gem you are referring to is Slice Favorites, yes. Every other part of the Slice system is currently part of the core engine as far as I know. If so, will projects that use slices and upgrade their engine to this change will any issues persist, or will it be a smooth upgrade for those projects? For projects that use slices for levels, this would be a hard cut. An editor built after these changes are implemented would be unable to open their levels. To my knowledge, pretty much everyone uses prefabs right now. I could not find many examples of slice usage on the Discord, nor recent bug reports related to slice functionality. @Ulrick28 <https://github.com/Ulrick28> since this is a clear functionality cut, regardless of the adoption... should we wait for the next main release before doing this work? We may just add to the release notes that 24.05 (or whatever the name) is the last main release to support slices for level editing, so that it is clearer. In terms of work, I would only need to wait for the stabilization branch for that main release to be cut before starting to push this work to development. — Reply to this email directly, view it on GitHub <#148 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARAYZKE54A3PVVKTMNMUEQDYXA5YPAVCNFSM6AAAAABDPO4BLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBTGE4TQOJSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[AMZN-daimini]

As far as I am aware, no one is using slices and we had already performed some removals making it difficult to use a slice in O3DE. The only reason we have kept slices around is due to the LYShine runtime UI editor.

Got it. Would we want to wait for the next major release before we begin then, or is it enough to just provide a commit/tag with the last editor version supporting slices for use with the converter?

[nick-l-o3de]

AFAIK, slice code cannot be totally removed since the UI system depends on it.

That being said, I'm thumbs-up on removing everything we can - there is absolutely no intention to go back to using slices in levels and it needs to be removed eventually. The only other caveat is that any legacy conversion code will die once slices are gone, right?

[AMZN-daimini]

AFAIK, slice code cannot be totally removed since the UI system depends on it.
That being said, I'm thumbs-up on removing everything we can - there is absolutely no intention to go back to using slices in levels and it needs to be removed eventually.

Correct, this would just remove the Slice UI related to level editing. Which is still a pretty big amount of code that is currently unused.

The only other caveat is that any legacy conversion code will die once slices are gone, right?

Not right now with this effort, since we're not removing the slice backend (since as you mentioned, it's being used by the UI Editor).
Ideally once we get to the point where we can remove the slice system for good, we could try to either port it out to a Gem with the slice-to-prefab converter, or just deprecate it for good (and point users needing that conversion to a specific engine version).