3 ms·
> I said IF the alternative is nothing. IF. Read that again. Read the whole context. Re-read it. It still is unclear. An app made in Electron could have been w
by Ygg2 4y ago
> I said IF the alternative is nothing. IF. Read that again. Read the whole context.
Re-read it. It still is unclear.
An app made in Electron could have been written in something else. What use case do you have where the alternative is nothing. The IF is almost never valid. Even if it doesn't exist yet, you can make it.
> Most game teams don't have the budget, so they won't have a custom editor and will have to use something like Unity/Unreal/Godot.
Sounds like excuses. Get a bigger team, smaller scope, or more money.
I've used Unity vs custom-made engines and ease, and just fun of the use of well-made customized engine beats Unity/Godot (I haven't used Unreal lately) in almost every way. Like time for Unity to start alone is 5min, plus Unity makes a certain style of games nigh-impossible to develop.
E.g. two similarily complex projects
https://www.youtube.com/watch?v=BT1B4HkEhfQ https://www.youtube.com/watch?v=BT1B4HkEhfQ
First is UnityStation in Unity, second is SS14 in C#.
And Unity is a lot of pain to work with.
> Claiming it won't be helpful to people and a community that wouldn't otherwise be able to build an alternative is asinine.
I said it would be more helpful to focus on building a specific viewer for a particular type of game. Sure, you can make a viewer that is meh at being a top-down, isometric, 3D, hyperbolic, pixel art, vector, etc.
Or an editor that's great at just pixel art - Like Aseprite.
Or a 2D Level editor - like LDtk.
Do one thing correct vs. do many things tolerable.
>"Rendering JS"?
Lapsus linguae. I meant to write debugging. So read it as, debugging JS in JS VM, isn't as good as debugging JS in JVM and vice versa (JVM in JS).
> The cherry-picked CLion example doesn't negate the fact that there are counterexamples.
Implying your example isn't cherry-picked? Really? How much have you used VSCode for languages with other VMs?
> Why can't we have the alternative?
I'm not saying you can't have the alternative; I think most of the time, it's a wrong trade-off.
I found myself preferring "the right tool for the job" over "everything and the kitchen sink" approach. And yeah, there are benefits to merging stuff and keeping it all in one place. See the link to Ralph Levinen's blog.
But, I tolerate IDEs because the integration of debugger and code help + highlight is obligatory, but I would lie if I didn't use a simpler tool if I need to quickly and speedily edit something.
Now compare Rider C# Ide to Unity IDE, that integrates even more into the mix. So it's C#, 3D Editor/Viewer, engine, etc.
- ratww 4y ago> Sounds like excuses. Get a bigger team, smaller scope, or more money. That sounds ludicrous. A bigger team or more money are incredibly difficult, especially for hobbyist and open source. And the whole goal of this idea is to reduce the scope of projects in the first place! It's impossible to reduce the scope if it requires something that might be as big as the engine itself. - > Lapsus linguae. I meant to write debugging. So read it as, debugging JS in JS VM, isn't as good as debugging JS in JVM and vice versa (JVM in JS). But the Javascript doesn't run inside the JVM or inside the Electron process. It happens in a completely separate process! It's the same for the syntax highlighting: it happens inside the Language Server for VSCode, and it's probably the same for JetBrains when using Typescript too. - > Implying your example isn't cherry-picked? Really? How much have you used VSCode for languages with other VMs? Of course it's cherry-picked, but this is how counterexamples work. The point is that a JetBrains IDE isn't by definition "better integrated", there are several more factors.