Atelier MVP discussion!

(Alve Lars Larsson) #1

Hello everyone, it was a fun meeting some of you chaps yesterday!
We need to push the discussion on the MVP for the Editor, and it is good for those who missed this meeting to chip in here.

We are creating a google document to collect our thoughts, please take a look here.

To quickly bring you up to speed here is what we currently are thinking. These will be the minimal features the Atelier UI needs to be able to do for MVP.

Level and prefab editing
A way to compose a project quickly and visually, this will be a load better instead of doing things by hand in code. The Editor should know what systems and components are available in the project, you can assign and tweak values of prefabs, place them in a level with either 2D or 3D space.

Undo, Redo, Recover. aka Atelier-Changelog
Using a diff-centric message-passing system for event-change management via broadcast routing between components of Atelier will enable undo, redo, recovery and history branching. (See @nothingismagick 's detailed follow-up below.)

General project management with Amtheyst.toml
At the root of an amethyst project we are going to have an Amethyst.toml, this will store general information about the game, editor settings, and the project’s engine settings. This TOML file will be the file the editor is initially looking for to open a project. Potentially the editor can generate amethyst projects or “project templates”.

Launch, debug, build it, all from the editor.
We are thinking of doing some slight automation of these basic features and put them as single-click buttons.

In Editor Console Interface
Where we can display warnings, errors, and info in one place, and the ability to send back commands to the system.

Hierarchy vs Query interface
Displaying information with ECS may prove to be difficult, these are fresh grounds to cover, an idea is to allow us to use a Query system similar to what spacial OS is doing, while we want some way to also have a sort of “classic” Hierarchy scene view.

The Atelier project
The editor is part of the Atelier project, the editor is referred to as Atelier-UI, while Atelier-Assets is the actual asset system that will be integrated into amethyst.

2D and 3D space editing
Thanks to @AndreaCatania for reminding me about adding this,
Our plans to use this great component to do all our 2D translations in the editor in a designated 2D editing space.

3D is something different, we need to discuss how we want to integrate the 3D rendering from the engine into our webview canvas.

EDIT
Atelier-UI has now moved and is now under the amethyst org!

5 Likes
(Nothingismagick) #2

Undo / Redo / Recovery

In my opinion this is something that needs to be solved before any other work on the Atelier UI can be done, as bolting this kind of system onto an existing approach is bound to brittle and too much work, likely forcing things to be completely rebuilt.

A couple of thoughts:

  1. The reactivity of the interface is very important if the user is making “forward” changes (adding a prefab, modifying a position etc.) This means that actions should happen immediately - as close to realtime as possible.
  2. The undo / redo activity can take as much time as it needs - but should still be useable.
  3. There are some states of the editor where undo / redo won’t really make sense.
  4. Being able to completely recover from a crash (which we expect will likely happen sometimes) is the holy grail.
  5. Maintaining a complete history of changes as a separate file would allow a user to step back through the entire history of the development of the project.
  6. Any changes that take place “outside” of the editor will not be reflected in the history.

My idea is that the evolution of an Atelier project can be modelled on a git-like type of changelog (tuned for brevity and performance). The entire history of all the changes will be recorded in a file (the most recent +10/-10 events in memory).

I am thinking about using a piece of rust middleware as a router that listens for changes and broadcasts these changes to atelier-assets && atelier-changelog && atelier-ui.

This pattern is nice, because no matter which component informs the router that something has changed, the changes propagate everywhere. In the case of an “UNDO” trigger, the router polls the changelog for the last event (which is technically a DIFF between the data at State(now-1) and the data at State(now)) and pipes that to atelier-assets & atelier-ui. In fact, this could open up opportunities for:

  • multiple people working simultaneously on a game
  • having branching revisions in their editor

In fact this last one would mean that a gamedev can branch and experiment their work, even having multidimensional undo and redo. It may make the interface more complicated - but the process of branching, merging and git diffing is basically common knowledge these days and leveraging that “attitude” for this critical piece of Atelier infrastructure seems to come with a lot of benefits… :smiley:

5 Likes
(Nothingismagick) #3

And already my first revision of what I just said: There is still some underlying scaffolding of the interface of the UI that can be done in the meantime, but integrating all these systems will have to wait for the atelier-changelog system to be put in place.

(Erlend Sogge Heggen) #4

It seems to me like this is what we should focus the MVP around in that case. Is the workflow for “launch, debug, build it” largely decoupled from the undo/redo & prefabs story?

(Alve Lars Larsson) #5

yes, it should not be involved with that, it’s basically “cargo run & cargo build” as buttons. as to other work that can be done without being dependent on the undo/redo system, I am working on the Amethyst.toml project management and content/filesystem view part, this should not be dependent on the undo/redo system too, these are only basic components

1 Like
(T.G. McLean) #6

Did a quick read-through of your MVP targets, and they make sense.

May I ask (on a somewhat different note), aside from the two Figmas referenced in the Notes doc, has there been any thoroughgoing imagining of the UI?

(Alve Lars Larsson) #7

The tow figmas are currently only sketches of “style guilds” or feelers to how we want the UI to be like in a final version, they are WIP( and has not gone through proper contrast and standards testing ). when I have the time I will produce a propper design document and a figma doc.

(Andrea Catania) #8

Tab system

One useful thing is a tab system where you can detach the tab to obtain a floating or full screen window, similar to the UE4.

This aspect is important because the game editor doesn’t have only game scene to manage, for example imagine a specific window to handle the skeleton character, or another one where you can work with visual shaders, or the animation tree and so on.

If we can have the possibility to create specialized windows for specific features will be a nice thing for the usability, otherwise we will end with the same problems that the Godot editor has.

2D/HUD and 3D

It’s not clear how you planned to handle the 2D/HUD and 3D editing.

2 Likes
(Alve Lars Larsson) #9

Oh yes, you mean a docking system? I forgot to add that up here, I and @nothingismagick have talked about similar.

as to 2D, we have found a component this,


It’s a great way to let us do all the things we need for 2D in the editor for UI etc

1 Like
(Nothingismagick) #10

@AndreaCatania - spawning subwindows is something that will have to be resolved upstream at Tauri, I just created an issue for it. I know exactly what you mean though and wholeheartedly agree. There is a quasar component (QWindow) that allows us to popout tabs / frames and drag - reposition them within the window. It has a slight perf problem that I discovered, but am in contact with the author about mitigations during the drag event.

(Nothingismagick) #11

Here is a current screenshot from an exploratory atelier window:

All the panes are resizeable and the menus are technically functional albeit not yet wired up. The i18n system exists and is implemented in one place, but I just want to reiterate that this is not a final design. Just more like POC work with LOTS of rough edges.

4 Likes
(Andrea Catania) #12

Cool!

I’m referring more, on how you plan to combine the 2d / HUD editing with the 3D. For example Godot has two tabs one for 2D view and the other for 3D view for the same scene. UE4 has a completely separated workflow where you have to create the 2D resource and add in inside a scene https://youtu.be/XVU5vNnhgxo?t=108.

Both solutions have pro and cons, and I think that would be useful plan from now on how to approach these.

@nothingismagick I’m really happy that you have my same idea, dedicated windows are love!

1 Like
(Alve Lars Larsson) #13

great question, I am unsure what we want? I like both godot’s way and UE4, but unity does everything in the same scene and only moves the editor camera to an orthographic view for 2D

And I like the latter, it feels more “natural”

(Andrea Catania) #14

I think that this closely depends on how the game engine works.

For example:

  • Godot: In the same scene you can have 2D and 3D objects because you have two separate cameras (2D/3D) that you can move independently. I like it because both the 2D and 3D are treated in the same way and both have full capabilities.
  • UE4: Create 2D games with this engine is not so nice and the reason is because the 2D/HUD is a resource and not an actual scene. But I like the fact that they have a specialized window to handle the HUD but most important 2D and 3D objects are not mixed.

A solution could be a crossover where both 2D and 3D have the same capabilities but however the scenes are not mixed together.

1 Like
(OvermindDL1) #15

Technically in Godot you can have ‘many’ cameras, either 2d or 3d, and they can be overlaid as you wish, even pointing to entirely different scenes. It’s quite a nice structure.

(David LeGare) #16

I’m still getting caught up with all the goings-on with the editor, so forgive me if I’m asking any questions that have already been answered elsewhere.

What’s the intended scope of the MVP? Something bigger than a technical proof-of-concept, but smaller than a production-ready application, I assume? I like the list of features posted above, but it feels like a lot for an MVP. My suggestion would be to focus on things that are:

  • Major technical hurdles that need to be addressed early in order to establish a solid architecture for the editor.
  • Things that provide key functionality that isn’t provided by current Amethyst tech, and would therefore represent a major bump in usability for users.

Suggested features to include:

  • Level/prefab editing - “Offline” asset authoring is one of the core use cases of the editor, and presents a number of key technical challenges to overcome, so it’s a critical part of the MVP.
  • Undo, Redo, Recover - As @nothingismagick noted above, the undo/redo functionality is a particularly tricky part of the tech, and will need to be integrated from the beginning in order to work well. If we don’t include it in the MVP, we’ll likely have to make major changes later on in order to support it properly.
  • 2D/3D preview in editor - I consider this to be part of asset editing process; It’s hard to work with a level editor that doesn’t let you see what you’re editing. It’s worth calling out explicitly, though, since rendering in the editor is, as far as I know, an unsolved technical problem.
  • Atelier integration - As noted in the original post, the editor is intended to be tightly integrated with Atelier-Assets, so it makes sense to include the integration in the MVP.

Things to maybe wait on:

  • Runtime inspection/debugging - Being able to examine the state of your game’s world as it runs is important, but keeping the MVP focused on asset authoring will help reduce the scope.
  • Build/run game from the editor - This isn’t a major technical issue compared to the others, and users can currently run their games from the command line with cargo.
  • Console/log output - Users can already access logs from their game from their terminal. Managing a large volume of log output is potentially a technical concern, but it one that is relatively well-solved, and so probably isn’t important to address in the MVP.
  • Hierarchy vs Query interface - We’ll need some kind of minimal interface for listing entities for both debugging and prefab authoring purposes, but it doesn’t have to be especially advanced in order to be useful for the MVP. This is also a potentially large design space to explore, and is probably worth doing as its own major initiative after the MVP.
6 Likes
(Nothingismagick) #17

So here’s a quick recap of yesterday’s meeting for those interested:

Attendance:
Kae4 randomPoison Alve Khionu nothingismagick

  1. Editor-core repo can be archived, some of its ideas will be used in the rust backend of the tauri based Atelier-UI. Kudos to @randomPoison#0083 for helping spec the scope of the current work!!!
  2. Atelier-Assets will be used for loading assets at bootstrap time, its daemon will be started (or hooked into) by Atelier-UI
  3. Atelier-Assets will be enhanced with an RPC API endpoint for MODIFYING metadata
  4. For the MVP Atelier-UI will focus primarily on being a prefab / asset editor
  5. There was general agreement (and some discussion) about the notion that using diffs (via Capnp RPC) is the right way forward for managing commands / undo / redo / recovery
  6. We are going to have weekly Editor meetings (Tuesdays for now)

And here are a couple flowcharts of the asset system that @kabergstrom prepared.
https://www.lucidchart.com/documents/view/414792ce-fa77-4676-9f90-1af8b6ac6041/0_0
https://www.lucidchart.com/documents/view/19393d19-ec4c-4469-910d-bac1a1b04834/0_0

2 Likes
(Nothingismagick) #18

Regarding Build/run game from the editor => there is a very simple API for doing this from tauri, so it might as well ship.

1 Like