I'm painfully aware of this problem. I'm writing a metaverse viewer in Rust, to connect to the Second Life / Open Simulator servers and get better performance and look from that 20-year old technology. A metaverse viewer has the problems of both an MMO game client and a web browser. It works much like an MMO client, but it's more general. All the game logic and content come from the server. It faces most of the overload problems a web browser faces. Plus some of the hostile content problems.
I can use many library-type components from game ecosystems. But I can't use the big game engines, Unity and Unreal, because they assume a workflow that uses their own editors, their own networking, and their own formats. So I'm forced to glue libraries together. Some of which I have to write.[1] Most of it is little stuff. Too much little stuff.
That section about struggling to get open source library maintainers to fix things is spot on. I have Github issues open for six libraries. If I open the hood on one of those libraries, I could spend months getting deep enough to contribute. I can only do so much.
> If I open the hood on one of those libraries, I could spend months getting deep enough to contribute.
Really? I can understand it in case of missing features or stuff that needs deeper refactors, but in my experience digging into an external library to debug an issue with it usually ended up with a working patch at most a few days later (usually hours), which is comparable to finding workarounds but with much better outcome. Granted, a working patch doesn't necessarily mean a mergeable patch yet (though it often does for bug fixes), but with FLOSS dependencies you can simply ship a patched version before it gets accepted anyway.
Since my stack is fully FLOSS, I tend to look for fixes first before resorting to workarounds and this approach has served me pretty well so far. Even if I fail to come up with a fix in the end, I learn possible workarounds in the process.
* winit - window.with_maximized ineffective on X11 platform
* rend3 - Minimize window causes unwrap panic on Windows / Wine. OK on Linux
Cross platform full screen is hard. Winit, WGPU, Rend3, and egui are all involved. Some things work on some platforms but not others. Order of operations matters where it shouldn't. (Must be visible before maximized on some platforms, but not all.) Right now I have enough workarounds to continue working. This area is brittle and easy to break. You need direct access to every supported platform (which, for winit, is Linux/X11, Linux/Wayland, MacOS on both x86 and ARM, Android, and WebAssembly) to work on this, and I don't have a full set of target machines. That comes up a lot with the libraries that handle cross-platform issues and present a portable API to the caller. Rust is good about cross-platform portability. It's impressive how well it works. But problems remain.)
* egui - Strange scrolling behavior - jitter up and down
Egui (a menu/widget overlay system) is under "heavy development".
This problem is in the mechanism for scrolling text windows efficiently when most of the text is offscreen, a common choke point in GUI libraries. Need to chase this down. I built a standalone program to demo this, but haven't tried to fix it. This I probably do need to address myself.
* sys-locale - Returns "en_US" on Linux. Should return "en-US".
One of those little things that breaks other things. RFC 5646 says use "-", and the parser for locales assumes that. Easier to work around than fix, although I reported it. A fix will probably break something that's depending on the current wrong behavior. I don't know enough about the internationalization ecosystem to be confident changing this.
That paragraph is quite fascinating. I mostly work with SDL and Allegro and I've chased a fair share of similar bugs there already on various platforms, most notably fullscreen handling under Wayland, but I never had to care about breaking other platforms with my fixes because platform handling is quite reasonably abstracted away in SDL (and SDL supports a lot of exotic platforms aside of those you mentioned, so it would be pretty much impossible anyway). I don't know winit, I wonder what in its design makes it so troublesome there.
Winit is trying to handle full screen, draggable window with frame and controls, maximized window with frame and controls, maximized window without frame and controls, and minimized window, across various platforms. Then there's the interaction between Winit and the 3D system, which in my case is Rend3/WGPU on top of Vulkan, Metal, OpenGL, or Direct-X. WGPU handles most of the cross platform stuff for 3D.
Supported platforms are Mac, Windows, Linux (X11 or Wayland), and Android (Chromebook and phone).
Not all the combinations work.
To work on this, either someone has to have all the supported hardware, or you need a closely cooperating team who collectively have all the hardware. Mucking about with something like that from the outside is likely to result in breaking something or creating hard to maintain single platform special cases.
I'm glad the winit and WGPU teams are doing this. It's important infrastructure used by many projects. It's impressive that it works as well as it does.
So seems like SDL covers everything Winit does plus much more (including at least some stuff WGPU does), and you really don't need to have all supported hardware to work on bugs in it - which would be a nightmare, since aside from the platforms you mentioned it supports stuff like Haiku, PSP, OS/2, Nokia N-Gage or QNX, and even console SDKs behind NDAs that aren't available publicly.
Its video drivers and render backends are all separated from each other. In all my adventures with fixing bugs or implementing new features in its Wayland backend (such as HiDPI support) I never had to touch the platform-independent stuff. Not saying that it doesn't happen in general, but I personally never had to do that.
It smells like nothing more than a maturity issue. SDL is almost 25 years old at this point.
How are you supposed to make a level for a game if the engine doesn't support editing levels? A big part of the level is that it integrates features of the engine directly into the level, e.g. static light shadow rendering.
There are so many options which people are just blind to these days because the "Unity way of doing things" has become so entrenched in people's minds :D
- you can build the level in a 3D modelling tool like 3DSMax or Maya and then write an exporter plugin to export the data into your engine-specific file format
- you can write a simple DSL to describe your level through text
- you can write a converter from another popular level file format (like Quake maps)
- you can write a plugin for the Unity editor, and create your maps in Unity
- etc etc etc... the possibilities are endless
...of course a dedicated level editing tool tailored to a specific runtime engine will always be most powerful and flexible.
Or you can go down the roguelike path and generate the levels procedurally. This approach is incredibly powerful and gives traditional roguelikes a ton of replay value while being very easy to build compared to traditional static assets. Plus there are subreddits [1] [2], wikis [3], and more dedicated to the topic!
Any good roguelike that came out in the last 15 years has had a visualizer for seeds, how map elements fit together if it's 3D, etc. You need tools to make a good game.
That’s true and in general conducive to going off the beaten path and building original games. I feel that with large game engines the cost is in ubiform putput: everything looks like everything.
Build it in Blender, including cameras and lights. Then build an importer for your game. This is substantially less work than building a whole editor. Especially when considering the editing capabilities of Blender.
Or build it in Blender, export it in GLTF (.glb), and import it directly into a game engine that supports GLTF import (like Godot engine for example). :)
This post hits home. It's true that if you want to make a more framework-ey library it is easy to end up maintaining a lot for controlling the developer experience. It is really sobering since it means a limit to reuse.
> It gets so much worse though. Suppose you need that bug fix from your dependency, or worse, want a shiny new feature to unblock your work?
> Roll a d12 to determine what happens:
> ... (a lot of examples of no attention being given to the issue)
Personally, I'm all for open source, but to me this seems inevitable when you expect people to solve your requests and issues with (quite possibly) no compensation.
That's a situation where paid support of any sort with SLAs would help mitigate almost all of these things. Similarly, if you couldn't get a contract from the current maintainers of the project (or couldn't find those maintainers in the first placE) then it would be telling, that you should probably look elsewhere.
Then again, curiously, open source projects rarely if ever offer paid support and using closed source libraries comes with a wholly different set of risks.
It does seem like it would be a reasonably lucrative area, though: "Pay us X$ per month to have your issues reviewed within Y hours." Or maybe even just allow the interested parties to donate money towards the resolution of particular issues that matter to them: "So far Z$ has been donated towards the solution of this particular issue. This issue has the #1 highest amount of donations and should be given priority."
Interestingly "You patch the issue and ship the patched library in your game" is not on the list.
Comparing to popular game engine Unity, let's say you are making a game that uses time-travel dead-reckoning netcode and polls inputs at 60hz. So you'd like to poll inputs at 60hz even if the game is rendering at 20hz, and you'd like to send those inputs in UDP packets immediately, not up to 50ms later than you got them. You don't need to roll a d12, we already know what happens: you start waiting in June 2005 for the ability to poll inputs at 60hz while rendering the game at some other rate, occasionally posting about this issue on the official forums. You continue waiting for at least *17 years*. It's a good thing you didn't depend on an open-source library instead!
Sorta unrelated, but I see the existence of engines to also be sort of a problem for Open Source libraries too. They create sort of a maintenance bottleneck.
In other areas where open source is more prevalent (like web dev), there will be virtually a guarantee that someone running into some long-lived issue within a library will try to patch and contribute back, or in the worst case fork it. Because the end users of frameworks/libraries often have the skills needed to patch those libraries.
In Games, however, there's fewer and fewer true consumer of libraries, since everything go through engines, and there's a lot of consolidation going on. Also, the popular engines aren't targeted at programmers that could fix the libraries, quite the opposite.
That puts a lot of pressure on library maintainers and engine maintainers, as they become the only people able to fix those deeper issues. Bevy of course is a bit lower-level, an others have source-available, but still...
Isn’t Unity’s code available? Unreal’s is, at least. It’s not quite the same as having official support and you don’t have the same rights as in open source, but you can at least change the code and fix it yourself if you really need to (with the difficulty of understanding a complex codebase, but that’s the case in open source engines too)
Unity is a lot more choosy about who gets their code than Unreal. To get the source you need to be in at least the $1800/seat/year tier and pay an additional cost that isn't specified.
The other commenter answered it (that unity’s source costs money to get access to), but my comment wasn’t about whether it’s proprietary or not, but rather if the source is available/accessible. Unreal’s source code is on GitHub, but it’s still proprietary. You cannot redistribute it or anything like that.
> Personally, I'm all for open source, but to me this seems inevitable when you expect people to solve your requests and issues with (quite possibly) no compensation.
Let's remember that half the point of open source/free software is that you have the freedom to fix things yourself. Remember that the reason that Stallman started his free software work was that he couldn't fix a printer because he was dependent on a company that wouldn't give him the source code.
I don't understand how we came to this idea that open source/free software means that people are dependent on each other to fix each other's bugs when the point of it was to get rid of that dependency.
As a gamedev I don’t have time to fix every issue that comes up with the engine. I’m not interested in building a game engine, I want to make games. Unity and Unreal are mature enough that they have understood limitation, workarounds of known bugs, and many, many solutions for common game mechanics. I built game engines for the first half of my career (about 6 years) and it’s a lot of work that could be better spent designing and implementing new game features. This is also why a lot AA and AAA game development are moving to Unreal and Unity because they want to make games not engines.
> As a gamedev I don’t have time to fix every issue that comes up with the engine. I’m not interested in building a game engine, I want to make games.
Not only that, but you might not necessarily be able to fix it yourself either! You might be a developer who can learn to use Godot with GDScript or C# (just an example) and could get comfortable with its abstractions, but might have never worked on your own engine before and might not have the pre-requisite C++ experience not to make horrible mistakes.
Using an off-the-shelf engine is generally supposed to allow you to get by with a team of game developers, instead of needing another team of game engine developers. That's not to say that it's not very lucrative to have the latter for larger organizations, though I think that smaller teams have different concerns.
Game engines are not good in general, because they do too many things. In my view it's better to pick libraries that do just what you need.
It gets a bit worse when you need to write a functionality that is specific to your game, and it becomes too dependent on a certain engine or library, so you can't switch to another library or engine.
Unreal and unity are monsters that allows beginners to have quick access to a high end rendering system, but then it doesn't leave enough room to add new cool things, like cool gameplay, a good multiplayer system, etc, when you want to ship on console who have limited memory.
I'm quite curious about the unreal engine and how fortnite uses it, because PUBG is a similar game, but its performances are quite bad, so it is an easy demonstration that a rich engine doesn't mean your game will be a smooth experience if your developers are not experts, because expert developer can write a better home made engine instead of paying for a rich engine.
These are the good reasons why I don't want to use all-in-one solutions, and this applies for web frameworks too. What's even worse, is that those big things don't just enforce a programming style, they also make it difficult to migrate your code elsewhere.
> Unreal and unity are monsters that allows beginners to have quick access to a high end rendering system, but then it doesn't leave enough room to add new cool things, like cool gameplay, a good multiplayer system, etc, when you want to ship on console who have limited memory.
I'm not following you here. These engines are exactly what enable you to add new cool things, and not focus on implementing lower level details.
Not to mention the huge library of games from B to AAA that use unreal/unity with things like cool gameplay, multiplayer and multi platform (PC and consoles).. this comment made no sense.
The comment hits closer to the bullseye than you realize. When you buy into an engine like UE and especially Unity you look at the successes on consoles but in reality you're in for a world of hurt if you want to achieve the same level of perf on the older consoles. It's like the difference between a stock WRX and a rally team prepped WRX - same car sure but the perf is vastly different and if you want to compete on that level you have a lot more work ahead of you.
>when you need to write a functionality that is specific to your game, and it becomes too dependent on a certain engine or library, so you can't switch to another library or engine.
Games are not a thing you just change engines on. You don't paint with oil on a canvas then halfway through it go "you know what, I think aquarelle would be better" and swap out the canvas for aquarelle paper. The engine is a detail of your game and should never be core to it.
>but then it doesn't leave enough room to add new cool things, like cool gameplay, a good multiplayer system, etc, when you want to ship on console who have limited memory.
You've not given a single look at Unreal, have you ? You have complete access to the entire source, it is modifiable and extendable to do absolutely anything you want, whether through blueprints or directly in C++. No cool multiplayer ? UE's default network replication is good enough to run on pretty much anything today. No cool gameplay ? ABZU (adventure puzzle exploring game), Assetto Corsa Competizione (highly accurate sim racing), Borderlands 3 (FPS Loot shooter), Dragon Ball FighterZ (fighting) as well as many experiments by users, including complex uses of portals and non euclidean geometry, etc.
It's not that the engine doesn't let you do cool things, it's that you're a software developer at heart that wants to find reasons to add new features to your engine, instead of making a game.
>PUBG is a similar game, but its performances are quite bad
PUBG was made by a brand new developer who slapped together assets from the store and hacked away until it barely worked. The whole core of PUBG is rotten and terrible code. So, sure, with home made engine, you don't have this problem because someone like Playerunknown would literally not have had the skills to write the engine and the game would have never existed.
It's not an engine problem, it's a developer problem. Think about things for a minute when you do then and you'll have no troubles. It provides you with so many accurate and useful debugging tools that your home made engine will never have if you want to do a performance pass.
> It's not that the engine doesn't let you do cool things, it's that you're a software developer at heart that wants to find reasons to add new features to your engine, instead of making a game.
This is so true. Yak shaving _feels_ incredibly productive. Look at everything I got done today!
The same can be true for rewrites, refactors, redesigns (product/graphic designers looove yak shaving), and prototypes.
I don't think that makes any of these things objectively bad. It just means there's a difference between wanting to have made a game and wanting to make games.
When you and your friends go out to get yogurt, do you generally go to a farm to pick out your cow?
The big part of what makes Unity easy to use, is just everyone uses it. I can pay an artist to make me some assets which work with HDRP. If I'm building some custom library, with custom shaders, I'm going to have to do much more work to make sure the assets are compatible.
You also have to think about the life cycle of code, if I make a small game in Unity and publish it, I'm probably not going to touch it after release.
> GitHub is littered with failed projects taking this approach...
I would argue this is because most of the developers trying to make these game engines are hobbyists or students. Most professional software engineering these days is all about gluing packages together so anyone with modest work experience shouldn't have trouble with this.
And what's the definition of "failed" anyway? Lots of these projects are likely complete - served their purpose already and don't have to be touched anymore.
I wish the term "game engine" would be better defined. Somehow this now means "the whole package", an integrated product like Unity, UE or Godot which includes all tooling required to create and publish games. This isn't an engine, it's a whole "Gamedev IDE", in spirit much closer to Photoshop than ImageMagick. Or as car analogy: nobody calls a whole car an "engine", even though every car has one.
The original meaning of "game engine" which made much more sense was: "the actual code which enables the game to run", e.g. just the runtime parts, the tiny piece of code that's dangling off the end of the asset pipeline ("tiny" relative to the work that needs to go into authoring tools and asset pipeline).
> Let's begin with something controversial: a stack made for a single game is not a game engine.
IMO this coupling happens mostly on purpose. It's just vertical integration, Apple style. It seems to be in the interest of "engine" makers to make people think that a smaller engine without an editor can't succeed, and that there's no possibility of having a standalone editor. They want control of the whole stack.
Game development in general has been plagued by those things. Everything uses proprietary formats, little interoperability, lots of custom stuff. All the parts that aren't proprietary came from the outside (eg: audio/video/image formats) or was leaked by generous developers (Quake MD? and BSP formats being used in newer games/libraries).
I would personally love to see more people working on editors that can be used by multiple engines, so that we can see more focused engines grow too, without having to create a whole editor ecosystem. And also editors would grow themselves, and editor-makers would make one without having to make a full engine. I really think it's possible.
> ...controversial indeed :D
I think the article writer is flat out wrong on this one. The Doom and Quake engines are definitely... well, engines, even though they were only reused later. Sure you can have a more spaghetti "game without engine", but I'd draw the line whether it's reusable/logically separated or not.
> It seems to be in the interest of "engine" makers to make people think that a smaller engine without an editor can't succeed
Phaser for a long time was a runtime engine without an editor, and many people missed that type of capability. Same with Cocos2D.
> and that there's no possibility of having a standalone editor.
Tiled (for 2d maps) or Spine (for 2d animations) are 2 examples of well known standalone editors. There's no chance to "make people think" that such things can't exist.
> It seems to be in the interest of "engine" makers to make people think
There's no hidden agenda going on, it's that integrated tools are often much more effective when building things out of multiple different pieces. Wouldn't it be cool to place animated objects in Tiled and see their animation states to properly gauge how they interact with the rest of the scenery in different states? Or use Spine to animate a tilemap going through an earthquake?
Custom file formats exist because features differ, and even for similar features, the semantics differ.
> Tiled (for 2d maps) or Spine (for 2d animations) are 2 examples of well known standalone editors.
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.
> Apples and Oranges compared to what the editors in Unity/Unreal/Godot do.
That's because integration allows them to do more :) I'm in the process of writing a game in bevy (rust game engine without editor). And most of the time so far I've spent integrating Tiled with it :)
This has nothing to do with integration but rather with the goal. Comparing a 2D-only tile editor and an animation editor with a 2D/3D engine and full-IDE is nonsensical.
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.
> Call me when the tile editor starts having aspirations of being an IDE.
It's not for 3d, but for 2d it allows placement of non-grid-aligned objects, has custom properties, relations between objects, object grouping, layers, types, templates and classes.
So yeah, you can use it as an editor for 2d game if you integrate it with your game. I've used unity before and I prefer tiled+bevy combo for writing 2d games even if it's more work upfront.
Alright, then it sounds closer to what I'm thinking, although extremely limited :) Either way, I'm glad it exists!
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.
Yep, it's been a while since I've been in the industry but with med-large teams your the composition of staff is such that Art/TechArt/Design are where the majority of the time/effort is going to be spent.
Last team I was on of ~60, we had 9-10 devs, if I could build tools that made our design or art team more effective that was a better use of my time(within reason of course).
I think the open source community can definitely do something cool like this. Although good UX has been historically the Achilles Heel of open source, I believe the focus would help a lot in this regard. No need to worry about the engine part itself. Godot's editor for example is already quite good, and it's only a portion of the engine. Imagine what a team with more focus could achieve.
It would also help tremendously in standardising file formats and other conventions. We've kinda settled on either ECS or Node-Based architectures, so there's an obvious starting point, concept-wise. Just have each engine provide a configuration file telling which components (or node types) are available, and how they can be configured. Or provide a language-server-like API so it's extensible.
There's no need to worry about high-fidelity, physics, sounds, or scripting during the editing (only during debugging), so some editor that just knows the 3D formats is enough. If debugging is needed there should be an optional way, like with code editors.
I've been looking for a big project to tackle, maybe that's something I can try to start myself :)
> I've been looking for a big project to tackle, maybe that's something I can try to start myself :)
I had a similar thought. I was thinking maybe this could even be some web-based system where you could have multiple editors talking to the same engine session, or vice versa.
> Although good UX has been historically the Achilles Heel of open source
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.
Something web would be really cool, indeed. Not only collaboration, but imagine integrating source control with all that too, that would be an awesome experience. Source Control is not something I enjoyed when I worked in a mainstream engine.
> 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.
> 100% agree. A popular "bring your own engine" editor would be awesome and would make a lot of sense (just not a lot of 'business sense').
This makes no sense at all to me. Part of what makes different game engines interesting is that they have different ways of modeling the world. How can you make an editor that's agnostic to the model? What's it even editing?
Unless your notion of 'game engine' is restricted to a subset that happen to use a very specific model. Like for example...2D tile-based platformers with finite maps.
> that they have different ways of modeling the world
You can usually abstract the 'data model' down to a generic "spreadsheet-like" representation of object types which are described by typed attributes (or in Unity lingo, game objects, components and properties). Anything more specialized (like modelling-, animation- and material-system tools) can be brought in through a plugin system. But at the core it's essentially a stack of Excel sheets with different view panels on the same data (like a property editor, or the 3D scene view).
For most 2D/3D games using ECS, which is something somewhat popular right now, you can definitely easily abstract the editor, in the manner flohofwoe mentioned for example. Same for other systems.
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.
When you look at the Unity editor, it's really mostly "just" a tree of game objects, which have components attached, which have editable properties of a handful of data types.
That's a generic enough core feature set to be applicable to be useful for most types of games, yet the UI is already tricky enough to "do right" to justify a standard tool (especially when it comes to things like searchability and bulk-editing of data.
Additional game-specific functionality can be provided via a plugin mechanism.
Most DCC tools have actually a fairly basic 'core idea' which is then extended through plugins (e.g. in Maya the core idea is "everything is a DAG node").
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.
> That's an editor for single game. The more generic you make it, the worse they are to use.
...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.
Sorry, but Electron is amazing if the alternative is "nothing". Same for game-specific editors. Some companies can't do it, so in this case Unity/Unreal editors are indeed better. And some engines also don't have the manpower to do engine-specific editors, so if something already existed it would be by definition better to the world.
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.
> Sorry, but Electron is amazing if the alternative is "nothing".
The alternative isn't nothing. The alternative is either Java, Qt, Gnome, Slint, rolling your own, doing per OS UI, etc.
People don't want to roll their own (understandable) or don't mind paying performance tax for stuff they don't need.
I don't use WebStorm but yeah a browser (VSCode) is better at rendering JS than a Java IDE (IntelliJ). Ofc a browser will have an advantage on home turf.
That said quality differs, but honestly try debugging Rust in VSCode vs CLion. Worlds of difference. Even if CLion isn't the best Rust plugin. Or Java in VSCode vs IntelliJ.
> We started this discussion by saying "it would be awesome if X existed" to which you said "100% disagree".
Your idea is a generic game editor vs something specific like Warcraft 3 editor, I made an analogy between something like LSP vs more integrated stuff like IntelliJ.
And I showed you what you leave if you make LSP primary focus, there are going to be some use cases that won't work in generic case, that a more specific IDE (or Rappid Application Deveploer env) would work with.
> The alternative isn't nothing. The alternative is either Java, Qt, Gnome, Slint, rolling your own, doing per OS UI, etc.
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?
> 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.
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.
> 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.
Given how many genres of games popped out of the Warcraft 3 ecosystem (dota, tower defenses, island troll tribes, survival games, rpgs, Pokémon-likes, board game likes, etc), it seems to me that Warcraft 3 is a perfect example of how much commonality exists between games that isn’t being exploited today — that it doesn’t require that much flexibility to support quite the variety.
StarCraft 2’s editor went even further with the game genres it was able to support (though they failed at building the community to utilize it)
Decoupling the user interface from the actual engine seems like an excellent idea on the surface.
Aside from your post here, has anyone even proposed an "engine agnostic" IDE experience for game dev? I can kinda see how it would be possible to do this - code your engine against some common editor API rather than the other way around.
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.
> has anyone even proposed an "engine agnostic" IDE experience for game dev?
I'm working in this direction. My focus is on higher-level editors for making worlds, meshes, animations, sounds, and visual effects. So far it's mostly written in Luau (Roblox's open source version of Lua) and the first engine integration is Unity. You use the editors and a Luau API to make your game. The API for now is part Unity-inspired and part Roblox-inspired.
I have the editors and Luau integration working well enough that I'm now using them to build a game. I plan to do that before supporting other engines. I've been building with other engines in mind (including having an abstraction), but I wanted to prove (to myself at least) that the editors have value before going down this path.
I'm kind of taking some risks with the editors, e.g. they're diegetic (all in-world UI). My main goal is to build higher-level editors that are actually fun to use, and then supporting multiple engines is secondary. Good to know someone else is thinking about that though!
When I was working with a semi-big studio, the people there always talked about this kind of thing. It kinda sucks to depend on Unity or Unreal. I've seen some people at Gamedev.net talking about it in the past too.
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.
Different engines have different ways of handling the same (or similar things). Either your IDE would need to provide an abstraction on to of all the engines (making it sort of an engine by itself), 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.
> Different engines have different ways of handling the same (or similar things).
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.
It's not just vertical integration for the sake of it. There are many, many, many things that are simply made easier by having every component able to talk to eachother. UE5's particle system can talk to the sound system back and forth, which can trigger gameplay events and send data to the renderer, etc. This leads to extremely complex interactions being rather easy to do, and that is exactly what large games want nowadays. You don't want to painstakingly time your cutscene to begin exactly 2m15s after the beginning of the level because you know that's where the song will begin but shit wait the intro can loop, no, you just have a gameplay event that starts the sound, the sound regularly says "hey, if you're ready, please trigger the cutscene now" and everything works together.
Getting this with a bunch of libs glued together is simply impossible. This is a design that was thought of for years before it happened properly.
The components are a concern of the engine and the game code, not of the editor. There is nothing preventing components from talking to each other when a generic editor is used. Have you ever played with Unity? Their modular design is generic enough to allow different components to be connected to each other.
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?
They are stacked at my folks place, can't remember the names.
One is about doing a return to castle of wolfstein clone, including network code for Novell networks, the other a 3D engine in C++ for a space shooter.
>The original meaning of "game engine" which made much more sense was: "the actual code which enables the game to run", e.g. just the runtime parts, the tiny piece of code that's dangling off the end of the asset pipeline ("tiny" relative to the work that needs to go into authoring tools and asset pipeline).
It still means that. When you hit the "Build" button in the Unreal IDE, you get your assets and custom code packaged together with the engine code. It doesn't bundle the IDE. I haven't used Unity in years, but from what I remember it works the same.
The IDE is only there (at least in Unreal's case) to give artists and programmers an easy workflow to develop the finished product, after which it's cast adrift. You need an integrated IDE these days because the number of features that are included in the engine is insane. If you're doing shaders and you're not writing them in raw GLSL, then the Unreal materials interface in the IDE is indispensable. If you're doing visual scripting (eg. Blueprint) the same applies.
My own engine used to be a single-game stack. Now there are more than 40 games written with it out there (and only one of them with its code written by someone else than me). It's not an IDE at all, just a bunch of (often intentionally leaky) abstractions on top of existing libraries. It comes with a tiny external editor written in PyQt that produces animations that can be consumed by the engine (which is optional, as they can be created by hand too), plus a bunch of scripts that use Docker containers to effortlessly cross-build it to several platforms.
I really don't care about other people using this engine. It's not for them, even though it's public and FLOSS. It's a tool for me (and people I work with) to make it easier for me to write my games the way I want to write them.
I wonder what the article's author would call it ;]
To me a game engine is anything that doesn't include a full blown IDE but still allows you to make games using any IDE, closer to a library. I agree with you, I don't know what could fix this to make a subtle distinction between the fully integrated game development environment maybe IGDE? Not sure, but it is more helpful to know how much they hold your hand. I'm okay with a very small library that doesn't provide all tooling as long as its in a language with good tooling, or they provide SOME tooling.
Yeah, back when I was growing up and Carmack was everyone's hero, "game engine" basically meant the game's main loop, and everything that supported that main loop. The code that makes the game actually work.
These days "game engine" basically means Microsoft Access for gamedev. And if you don't use one you're basically leaving money on the table, so it makes no sense to try and be a Carmack in today's scene.
> a stack made for a single game is not a game engine.
For a concrete example: the newest Lego game, Star Wars the Complete Saga, had a complete engine rewrite ("NTT") and the new game is the only one that runs it. I wonder what term the author would use to describe NTT, which isn't designed to run a single game or have a community.
What does a complete engine rewrite mean ? Is it just a new renderer with deferred shading ? Is it a bunch of new gameplay tools ? Is it a start-from-scratch thing ? (Which would be absolutely stupid).
Game engines are more of an ecosystem. Yes, the community is a thing because the devs seem to be a small indie group that uses Godot so they can ask for assistance, but Frostbite does not have such a thing (well, maybe internally at EA), and yet noone would say it's not an engine. 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. UE and Unity are two different engines because the workflows are different. But UE4.0 to UE5.0 is still the same engine, you won't take that much longer to get back in the groove.
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.
You can still find rotary engines in cars, that doesn't mean that the first thing that comes to literally everyone's mind when you mention engines is the classic combustion engine with cylinders.
Lots of big claims about engines traditionally not being about editors, but nothing to back that up. Engines have always referred to the whole package, and to something somewhat reusable. Saying "recently" and mentioning the Quake Engine before makes me question your definition of recent. Thirty years old in an industry that's barely 50 if you count the first popular games like Oregon Trail? Where do you fit Monkey Island, using the SCUMM Engine in 1990 ? You don't see anyone talking about the Celeste Engine, or the A Link to the Past Engine, because they're bespoke, single purpose implementations.
So, no, engines have pretty much always been about reusable tools, that may or may not bake certain gameplay elements in, but are overall just a tool.
> Lots of big claims about engines traditionally not being about editors, but nothing to back that up
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.
The difference between SCUMM and something like "Celeste Engine" is that Gilbert and the rest of Lucasfilm Games decided to reuse Maniac Mansion's code for their next titles, while nothing reused Celeste's code (yet). SCUMM even has it in its name ;)
I think you are confused. Editors are not part of the game engine. Unity editor is separate from Unity the game engine. When you ship your Unity game it doesn't bundle the engine with it.
