ratww

I said IF the alternative is nothing. IF. Read that again. Read the whole context. Words are important. Don't skip them. Stop cherry-picking. Your point is only true IF I have money, time and knowledge to use those. I might not have it. Are you gonna come to my company and code all this stuff, for free? 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. And most potential engine writers don't have the budget for writing editors, hence my mention that there is a place for something generic.

> don't mind paying performance tax for stuff they don't need

The performance tax is higher in some JetBrains projects. It is also significantly higher in Visual Studio Enterprise than in VSCode. "Integrated" doesn't mean "faster".

> Your idea is a generic game editor vs something specific like Warcraft 3 editor

It's not. My idea was an open-source scene editor that engines can choose to support when they can't make a proprietary and engine-specific scene editor. You're the one who brought Warcraft 3 into the conversation. I also don't understand the "vs" part. Let me try to simplify my point to you: People who have time and money make X, should have X. People who can't make X, would ideally have an Y option too.

If you don't want to use such an editor, just don't use it, period. Claiming it won't be helpful to people and a community that wouldn't otherwise be able to build an alternative is asinine.

> I don't use WebStorm but yeah a browser (VSCode) is better at rendering JS than a Java IDE (IntelliJ).

"Rendering JS"? This is nonsensical, the JS code is run either in a browser during dev time or in a separate process for typechecking. An IDE is not a runtime. Please inform yourself before making such ludicrous statements.

> And I showed

You really haven't demonstrated anything, sorry. The cherry-picked CLion example doesn't negate the fact that there are counterexamples. Your ignorance doesn't invalidate the counterexamples. To me it sounds as if you're completely out of your depth here and just trying to win a random internet argument, and has absolutely nothing to contribute to this conversation. What you propose already exists but costs money. Why can't we have the alternative?

As soon as it was decided the team was late (due to constantly changing scope) he put forth a plan to make the team 4x bigger in one year. Contrary to probably the most obvious lesson from the book.

People just don't read. Or admit THEY are at fault.

It's not only documentation, which they ask for but never read. They also won't read error messages, and ask seniors for help on almost every situation.

(But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it)

Curiously the two that needed it didn't really want to study at all, and we eventually let them go (they were interns).

Sure, there's lots of startups burning the midnight oil to finish that MVP. But especially on more mature teams, it's incredibly easy to lose focus when doing software and spend several days on shitty features that don't really matter at all to customers, but are being prioritised due to inertia or capricious management.

A few minutes using Unity3D are able to demonstrate that: Unity's interface is quite transparent about the abstractions it uses.

Also, Unity3D itself uses the extensibility of its own editor to add advanced editing features, so it's already something industry-proven.

Big claims? What the hell does that mean?

What about Bevy, the engine mentioned in the article this thread refers to? Also, most Rust engines. Also most engines you find in Github.

Or do you want a list? Here's some from the top of my head that I'm familiar with: Love2D, Irrlicht, Torque3D, Solar2D, MUGEN, Nebula, jMonkeyEngine, Panda3D (this one powered several Disney games), Cocos2D (it powered several popular games before Cocos Creator existed), Ogre3D (before having an editor). There's also plenty of Rust ones: Bevy itself, Amethyst, I could do more research, but I suggest checking Wikipedia.

This is also not counting studio-specific scriptable engines. I worked on a few and we didn't need scene editors, because we just used 3D editors and tags. That's definitely an engine, despite not having the tools you claim to be necessary.

You can make the case for those engines not be called engines anymore, or maybe engines with editors should perhaps be called something like "megaengines" or whatever, but there's definitely more than one type of engine.

Sorry but you can't retroactively change the name of things just because they don't fit your limited knowledge. The "engines must have editors" thinking is something that only happened in the last 10 years, a few years after Unity3D gained popularity, and while some newbies might assume that from this meme, it doesn't really represent the historical use of term or the usage of the term by the industry as a whole.

My point is only that MORE can be done, regardless of integration or not. What really matters is the data model and (as demonstrated by Unity) extensibility.

I still have the weird stories to tell, but glad I'm out of there.

I hope you're also in a great place!

"The ticket is part of a relief package decided by the Scholz cabinet due to the increased energy costs due to the Russian attack on Ukraine"

[1] https://de.wikipedia.org/wiki/9-Euro-Ticket

I personally would probably pay the €69 if my employer paid a part, since I already pay €40 / €63 for Berlin, which I consider a good deal.

But for people that have a car and tourists €70 is indeed a bit steep.

And I completely disagree about JetBrains products being more integrated. Some integrations are MUCH better and deeper in VSCode. To give three recent examples I came across: Vue, React and Svelte. WebStorm doesn't even have some features offered by VSCode, like typechecking in templates. Not to mention that, at least to me, VSCode is significantly lighter than WebStorm and runs much faster in older laptops.

VSCode is also significantly faster and much much lighter than the ultra-integrated and native Visual Studio, so there's also that. I know because I use both, and I know which one locks up all the time and takes 40GB of disk. Seems like they just didn't use the optimisation opportunities.

Either way, this discussion doesn't seem to be going anywhere. There's doesn't seem to be anything for us to learn here. I'm addressing every new single point you make, while you keep moving the goalposts by cherry-picking my posts while ignoring the parts I cover :/

We started this discussion by saying "it would be awesome if X existed" to which you said "100% disagree". Sounds like you don't want me to have some tools, or maybe you're under the assumption that my desire is for Unity/Unreal/Godot to stop existing, which is definitely not the case.

Sounds like you're confused yourself :)

You probably mean "it doesn't bundle the _editor_ with it".

The part uncontroversially accepted as being the "engine" is definitely bundled.

Not really. In the case of Unreal/Unity/Godot (and perhaps things like Quake and Source before it), sure. But there is definitely more to engines than this, which is the argument being made.

We probably need a better term to differentiate traditional engines from the big ones that come with an integrated editor. But until we do, there are many sizes of engines.

> As long as, through an upgrade, your engine keeps the same way of working and you're familiar with it, it is an engine as a whole

Again, this is the controversial part. Engines are traditionally not about editors and workflows and whatnot. Sure the term has changed recently and a lot of people now have this impression, but until there's new terms, engines come in different sizes.

Might as well compare Logic Pro X with Visual Studio Code. Which one is better for editing pictures?

Call me when the tile editor starts having aspirations of being an IDE.

> The ticket can be bought only throughout the summer months.

The ticket is a new thing, by the way. The reason it's only available in "summer months" is because they haven't finished thinking about how it's gonna be after that.

However the transport companies already manifested interest in continuing with the ticket for €69 [1]. Sure, not €9 but still progress. Some parties recently suggested €365 per year. Both are still a great price IMO considering I used to pay €40 a month (€63 in total, my company pays the rest), for a ticket that only covered Berlin!

[1] https://www.tagesschau.de/wirtschaft/verbraucher/69-euro-tic...

[2] https://www.iamexpat.de/expat-info/german-expat-news/left-ca...

...and yet Unity and Unreal are quite popular compared to "rolling your own editor", and very few people do it. Most people seem to be happy with the Unity/Unreal/Godot tools, with generic IDEs, with generic image editors, with generic 3D editors, with generic DAWs, etc etc etc.

A standalone scene editor doesn't have to be more generic than Unity or Unreal. The idea is providing a base for engine makers to work on, not the opposite.

Part of the success of generic solutions is due to cost. Not every game developer has the time and resources to make a tool like the two you mentioned. And also engine makers, not all of them have the time and resources to do an editor like Unity or Unreal.

A good generic editor is better than a shitty specific editor. It's also better than a non-existing editor.

> It's the same thing with IDE. The more plugin friendly you make your IDE, the less optimization chances you have.

Visual Studio Code, vim and emacs are actually extremely extensible and very performant. The sweet spot seems to be much more performant than you seem to assume.

Curiously most Indies kinda dislike the idea because they like the integration. DIY-engine-makers are split: some want to do it all, others would enjoy having an editor.

> code your engine against some common editor API rather than the other way around

Yep, that's the trick.

> The idea of being able to swap to an entirely different engine but keep all my content, tools, etc is pretty fantastical, but I don't see why it would be impossible.

Exactly, that's already the reality with IDEs, even when advanced features like debugging and reflection are involved.

There is already a lot of common ground, and this is what I'm after. It can even be just component-based, like Unity, which is a great abstraction understood by a lot of people. Engines that are too different from don't have to be supported by such an editor, or would require some extension.

> Either your IDE would need to provide an abstraction on to of all the engines

Why? I don't care if engine X uses this editor or not. I can't force them. I probably wouldn't be able to legally make this work with something like Unity, that uses proprietary file formats.

What I want is a generic editor that can provide enough functionality to be used by future engines, not a Unity/Unreal/Godot replacement. Engines have to do heavy lifting too if they want to support the editor. If they don't, it's their choice.

It's like bob1029 said above: "code your engine against some common editor API rather than the other way around".

> or the game makers would need to specify a lot of attributes for each game object in multiple ways, often one for each supported engine.

This is trivial to do with computers: just do what Unity does with Reflection. Just provide metadata for the types of components, containing the list of attributes. It can be a JSON file or something like that. Or provide something similar to VSCode Language Server where properties can be queried with an API.

Your mistake here is assuming that such a tool would be complete from the get go and replace all competition, without needing to talk to other software. I'm not a venture capitalist, I'm a software engineer. I'm fine with limitations in my tools.

> Completely agree. Perhaps the best way to go about a project like this would be to establish a few mock use cases up front (i.e. actually try to build a dummy game with your own tools). The magic of UX doesn't appear until you have actually used a thing and start tweaking stuff like animation delays, font sizes, tab order, modal positions, et. al.

That's true! However, there's some good prior art for engine editors, in the shape of Unity, Godot and Unreal.

Not to mention that interconnection between components is often also achieved via code inside each component (example: gameObject.GetComponent() in Unity), which is not really the concern of the editor, but rather of the engine and the game code.

> Getting this with a bunch of libs glued together is simply impossible.

I really don't see what "bunch of libs glued together" has to do with my comments at all. Are you sure you answered to the right person? Are you answering to the article in general?

For a lot of functionality, they need plugins or something similar. See Unity editor scripts for an example. Something unified would be able to take advantage of those plugins in a more generic way. Need a tile editor? Plugin. Need retargeting? Plugin. Need a special exporter for your game? Another plugin. Need a custom editor pane? Plugin, like Unity.

Another proof that current engine/editors are masters of one is that most people is already using a separate IDE for code, a separate 3D software, a separate texture painter.

Those are a 2D map editor and a 2D animation editor.

Apples and Oranges compared to what the editors in Unity/Unreal/Godot do.

> There's no chance to "make people think" that such things can't exist.

A lot of people in this very thread seem to be under this impression.

> it's that integrated tools are often much more effective when building things out of multiple different pieces

Integration can happen in different ways. Complete integration (aka being made by the same team and tightly coupled) is not necessary for a great experience.

For programming itself we’re already free to choose our editor of choice, and they often integrate quite well. People used to say the same about Visual Studio and C#.

> Custom file formats exist because features differ, and even for similar features, the semantics differ.

There is a lot of common functionality in modern engines. Not to mention that formats can be extended to contain additional metadata coming from customised parts of the editor. And editors can be extended to allow new formats too.

Starting with the automatic assumption that there cannot be a common format is incorrect.

The internet is also filled with those same people. That includes Twitter and Facebook. The reason the bad ones are are extra loud in the internet is because some websites amplify their messages, whereas normal people don’t want the extra attention and prefer privacy.