Yes. the editor could be left out, but in that case, I would completely cut out the one-way communication editor-runtime.
I don’t like that I can change the value in the editor, and see the changes in runtime, but only for startup objects. It feels like half done. Or you have full communication and synchronization, or you don’t.
By having a new viewer running in the game while in play mode, would make the current communication obsolete. It would be even better than Unity, because I found myself changing values at runtime, and then I have to remember what changes to re-apply in the editor after stopping the game.
With this new viewer I could make my changes at runtime, and, in the meantime, go to the editor to store the new values, without the risk to lose them or forget them.
Absolutely not. If you can affect to hierarchy in Editor from game - you can brake your project occasionally.
Now Editor allows you to add components to entities, see changes with hotswap and it’s great.
I would like to summon @will to make this point clear. He knows much better why it works this way.
I agree with you and of course, this is not what I suggest. Playcanvas editor doesn’t play the game itself so it can’t behave like Unity that restores the scene once the game stops. The two-way communication is not the way to go.
This is what I was suggesting to have in the new viewer integrated inside the game view. So that I can experiment by adding components, changing values, and so on. And I could do it also on runtime created objects. If I like the result, I then re-apply these changes in the editor. If I don’t… just restart the game. No harm is done to the project.
Now instead, I find myself changing one thing in the editor, and refresh the game every time because I can see the results only on objects created at runtime.
@will I would probably move this topic to Suggestion & Feedback.
I think console is my best friend it this case. It has history, templates and control application by code is okay for me.
If I want to change something, I just do it by code. I came to gamedev from backend development based on Unix, so I’ve never used to have UI for my purposes.
But I would really appreciate if somebody from core team tell us something about this subject.
We have thought of having an in-game debug view in the past. But other things have taken priority. Personally (I emphasize the word ‘personally’) I like the idea of having a view in the launch page where you can see all your runtime entities / assets etc and be able to inspect them and change their values without affecting the Editor. It would certainly be useful.
Having said that, how hard would it really be for someone to make a Chrome extension and implement such a feature? You could have an overlay that shows all the entities in a tree and be able to inspect them with a simple UI…
Fine, good luck.
Instead, I’m a paying customer, and I like if I can get help from someone else that is already focusing on developing such tools so that I can focus on coding my app.
I personally expect this kind of feature to be offered by the editor, and so by Playcanvas team.
At the end is a paid service that should be improved over time.
We take all suggestions into account and put them in our todo list if we decide they’re worth doing - features we’ve done in the past have come from user suggestions. Often we have other priorities in our pipeline and there are users out there who like creating extensions and enjoy such side projects so that’s why I’m suggesting that.
Yes, that would be of course possible, but I see that the editor could have more selling points by having more features. So far is very basic and has a lot of limitations.
Also, what I was suggesting wasn’t just to have a simple viewer, but a fully working hierarchy and inspector panel, exactly as the editor ones.
So it would make more sense to start from the editor code.
I think this has to be implemented carefully feature wise as the editor was always something that was designed to be collaborative in real time which has it’s own design constraints and conflicts with the Unity Editor functionality.
When User A tweaks ands items to the scene to test some stuff, should User B also receive the same changes?
The editor also ‘auto-saves’ for the same reason. Being able to revert back to the state when the user has launched (and at the moment, they spawn off a number of different play windows) also conflicts with the real time collaboration.
I agree with @vaios and @mikefinch on this. Here are my thoughts.
This belongs in the Launch page, not the Editor.
We could recreate the hierarchy and inspector panels to the left and right of the running game. Hopefully, we could reuse a lot of code from the Editor to do this. I think it’s important to get a consistent UI across the Editor and the Launcher.
We update the engine to fire events that are relevant to this: ‘entity:create’, ‘entity:reparent’, ‘entity:addcomponent’, ‘component:propertychange’, etc. These drive updates to the Launcher UI.
We keep this as a debugging tool - you can’t update the original scene in the Editor from this view. As has been suggested, communication between Editor and Launcher is one-way.
Instead, about the editor updating the runtime, sometimes it causes some issues.
If I set a value in the editor, it applies also other original values, breaking the runtime object.
For example, if I want to change only the x position of an object that has been moved, I can’t do it because it would also change y and z (by resetting them to the original values).
When dealing with dynamic objects could be better to have only the Launcher to make real-time changes only.
This would allow us to experiment new settings at runtime, and eventually apply those settings also in the editor.
I didn’t use the collaborative feature, but as @yaustar wrote, changing some settings in the editor wouldn’t it affect also other developers’ runtime? For static objects could be fine, but for dynamic objects probably not.
It could also be an option in the settings to enable/disable the editor->runtime communication.