AmbientRun / Ambient

The multiplayer game engine
https://ambient.run
Apache License 2.0
3.79k stars 122 forks source link

Ambient IDE #694

Open FredrikNoren opened 1 year ago

FredrikNoren commented 1 year ago

Currently you have to add --debugger when calling ambient to see the dev tools. We should reverse this; the dev tools should be shown by default and we can have a flag like --no-dev-tools to hide them. This would make it easier for new users to "discover" the ECS as well; they can just look at how things work.

Long term, the plan is to build out the dev tools with more features, such as:

Once we have #12, the IDE should basically just be opened at the beginning of a dev session and then be kept open (kind of like how you'd use VSCode or Unity; they just keep running).

(Not sure if IDE is the best name; we can think of better ones)

ten3roberts commented 1 year ago

Another solution we have discussed is to have a subtle cogwheel or alike in the corner when enabled, which when clicked will slide out the inspector and ide panel. This makes it possible to still "play" the game without having the inspector take up too much space, like on the web where the inspector covers quite a large area.

For releases, such as a main game, or other things we consider to be released we could disable the cogwheel altogether. However, given our goals we may even choose to keep it there, as our focus may be to just be able to play a game, and at any time get up that menu and modify it. So it the author chooses it can be there all the time

philpax commented 1 year ago

Currently you have to add --debugger when calling ambient to see the dev tools. We should reverse this; the dev tools should be shown by default and we can have a flag like --no-dev-tools to hide them.

Sounds good - only suggestion I'd make is to turn the IDE off for remote embers (or maybe embers marked as "production") so that users can use #684 to run embers off the website without having the debugger show up. Maybe change it to --force-debugger-on (show, even for production embers) and --force-debugger-off (don't show, even for local embers)?

(Not sure if IDE is the best name; we can think of better ones)

I think it's fine - it is an integrated development environment, after all 😅 If the scope wasn't growing, "inspector" would be fine, but IDE better covers its full scope I think.

FredrikNoren commented 1 year ago

@ten3roberts Yup, think we can make something that feels fairly discreet by default, but which easily expands to lots of functionality.

@philpax For players; to run the "desktop version" of deployed games, I was thinking we'd add a download button on the website, where you download a zip of ambient.exe (renamed to your_game.exe) + settings.toml, where settings.toml contains information to launch that game. For developers I think it's we'd want to show the IDE even when connecting to remote sessions, as they'd presumably be "developing" (i.e. want to inspect network traffic and whatnot).

Pombal commented 1 year ago

Similar to the cogwheel idea, I was going to mention being able to enable/disable the IDE at runtime on a key press. Ideally, disabled by default (don't pay for what you don't use) with some helper text showing the available commands on non production builds.

FredrikNoren commented 1 year ago

@Pombal Yeah we can easily add hotkeys to "the cogwheel" etc., it's already supported by the UI. And yes, by default it should take more or less 0 performance impact (though I think we can still show "the cogwheel" itself, that shouldn't impact performance).

philpax commented 1 year ago

For players; to run the "desktop version" of deployed games, I was thinking we'd add a download button on the website, where you download a zip of ambient.exe (renamed to your_game.exe) + settings.toml, where settings.toml contains information to launch that game.

What if I already have an ambient.exe, want/have to use the desktop client, and want to play games I see on the website, or that my friend is hosting, or has shared with me? People should be able to play games from anywhere using the desktop client without having to manually disable the debugger, IMO.

I think the cogwheel solution is a better way of handling this than always showing the IDE; for "production" builds it can be disabled, but for non-production builds users and developers alike can click on it to show the information they need.

FredrikNoren commented 1 year ago

@philpax I'd only expect developers to have ambient.exe installed locally (you have to install rust and then install ambient to get that). For players there will be other routes to play (like I mentioned above).

philpax commented 1 year ago

I'm using ambient.exe here to refer to the version manager, or whatever people use to run the game. If we're drawing a distinction between a dev client with the debugger turned on by default and a user client with it turned off by default, that's fine - just need to make sure that's obvious.

FredrikNoren commented 1 year ago

@philpax No I mean also the version manager; I wouldn't expect anyone other than devs to have that. But yeah I think we're kind of on the same page; players shouldn't see the IDE basically.

FredrikNoren commented 1 year ago

I'm also thinking we make the IDE really minimalistic by default (0 performance cost etc.); i.e. @ten3roberts's "cogwheel" but a bit more discoverable than that (you should want to click around as a new user to figure out how ambient works). Just to give a rough idea of the direction:

Frame 19

So one of the buttons would open the ECS inspector for instance, another would open the asset pipeline editor

FredrikNoren commented 1 year ago

@philpax and I just spoke about another potential idea here; we might be able to make the IDE an ember itself, and implement it on the guest side. That would allow for all the exciting guest side stuff, like user extensions.

philpax commented 1 year ago

@philpax and I just spoke about another potential idea here; we might be able to make the IDE an ember itself, and implement it on the guest side. That would allow for all the exciting guest side stuff, like user extensions.

Can also integrate it with the editor 😉