Game engines are more than libraries glued together
leafwing-studios.com
leafwing-studios.com
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.
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.
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.
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.
- 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.
[1] https://www.reddit.com/r/roguelikedev/
We kinda did that for our little ray-tracer: https://www.youtube.com/watch?v=QZSoVidqV2Q
> 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."
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!
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
...controversial indeed :D
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.
The Unity editor is actually quite hackable and can be used like that, but that's very likely a 'licensing grey area'.
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 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.
> 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.
Different engines will have different requirements. By making an editor for generic case, you'll end up Jack of all trades, master of none.
Integration makes more sense, but the price you pay is inflexibility.
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.
It's the same thing with IDE. The more plugin friendly you make your IDE, the less optimization chances you have.
...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.
So is Electron compared to rolling your native app. Electron is easier to develop for and pool of developers are bigger.
I'm taking about optimization opportunities.
> Visual Studio Code, vim and emacs are actually extremely extensible and very performant.
Eh. I don't use vim or emacs, but VSC isn't on par with something more integrated like JetBrains.
What I have in mind is Ralph Levien blog: https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
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.
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.
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?
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
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.
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.
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)
Agreed, and this is on my mind as I work in this direction.
By the way, I was really inspired by The Nebula Device back in the day, and even used it for some side projects. Thanks for working on it.
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.
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).
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.
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.
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).
Integrated engines just reflect that composition.
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.
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 :)
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.
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.
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.
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.
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.
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.
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.
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!
I post about progress here if you're interested: https://twitter.com/kineticpoet
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.
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?
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.
Is it "Tricks of the Game-Programming Gurus" (https://www.amazon.com/Tricks-Game-Programming-Gurus-Andre-L...)?
> a 3D engine in C++ for a space shooter
The other seems to be "Building a 3D Game Engine in C++" (https://www.amazon.co.uk/Building-3D-Game-Engine-C/dp/047112...).
It's amazing to see old gamedev books :)
> 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.
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.
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.
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 shotgun is a library. The motorbike is a framework. The (unskinned, inactive) T-100 is a game engine.
The Arnold-skinned Terminator shooting at the T-1000 with the shotgun while riding away in the motorbike is a video game.
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.
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.
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.
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 ;]