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.
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.
The Unity editor is actually quite hackable and can be used like that, but that's very likely a 'licensing grey area'.
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.
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.
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.
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 ;]
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.
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.
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.
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.
- 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.
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.
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.
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.
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.
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.
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.
