10 ms·

Game engines are more than libraries glued together

103 points by alice-i-cecile 4y ago

snarfy 4y ago
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.
- flohofwoe 4y ago
  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.
  - chongli 4y ago
    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! [1] https://www.reddit.com/r/roguelikedev/ https://www.reddit.com/r/roguelikedev/ [2] https://www.reddit.com/r/proceduralgeneration/ https://www.reddit.com/r/proceduralgeneration/ [3] http://roguebasin.com/index.php/Articles http://roguebasin.com/index.php/Articles
    - ohgodplsno 4y ago
      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.
  - tartoran 4y ago
    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.
- w4rh4wk5 4y ago
  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. We kinda did that for our little ray-tracer: https://www.youtube.com/watch?v=QZSoVidqV2Q https://www.youtube.com/watch?v=QZSoVidqV2Q
  - blooalien 4y ago
    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). :)
KronisLV 4y ago
> 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."
- anonymoushn 4y ago
  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!
  - dkersten 4y ago
    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)
flohofwoe 4y ago
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. ...controversial indeed :D
- ratww 4y ago
  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.
  - flohofwoe 4y ago
    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'). The Unity editor is actually quite hackable and can be used like that, but that's very likely a 'licensing grey area'.
p0nce 4y ago
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.
deleted 4y ago
[deleted]
stephc_int13 4y ago
In my opinion, the definition of a game engine is the part of the code in a game that is not the content.
jokoon 4y ago
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.
- 999900000999 4y ago
  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.
- ohgodplsno 4y ago
  >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.
fb03 4y ago
Happy to see you here, Alice and the whole Bevy gang!
- alice-i-cecile 4y ago
  Finally blogging! I'm looking forward to writing and sharing more; it's been fun to hear everyone's perspectives.
Ericson2314 4y ago
Lol they are playing themselves a bit because stuff being "more than libraries glued together" is generally a bad thing!
hgs3 4y ago
> 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.
- seba_dos1 4y ago
  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.
Animats 4y ago
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. [1] https://github.com/John-Nagle/serde-llsd https://github.com/John-Nagle/serde-llsd
- seba_dos1 4y ago
  > 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.
  - Animats 4y ago
    Typical issues: * 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.

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.

flohofwoe 4y ago
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.
- chongli 4y ago
  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! [1] https://www.reddit.com/r/roguelikedev/ https://www.reddit.com/r/roguelikedev/ [2] https://www.reddit.com/r/proceduralgeneration/ https://www.reddit.com/r/proceduralgeneration/ [3] http://roguebasin.com/index.php/Articles http://roguebasin.com/index.php/Articles
  - ohgodplsno 4y ago
    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.
- tartoran 4y ago
  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.
w4rh4wk5 4y ago
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. We kinda did that for our little ray-tracer: https://www.youtube.com/watch?v=QZSoVidqV2Q https://www.youtube.com/watch?v=QZSoVidqV2Q
- blooalien 4y ago
  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). :)

KronisLV 4y ago

> 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."

anonymoushn 4y ago
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!
- dkersten 4y ago
  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)

flohofwoe 4y ago

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. ...controversial indeed :D

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

p0nce 4y ago

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.

deleted 4y ago

[deleted]

stephc_int13 4y ago

In my opinion, the definition of a game engine is the part of the code in a game that is not the content.

jokoon 4y ago

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.

999900000999 4y ago
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.
ohgodplsno 4y ago
>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.

fb03 4y ago

Happy to see you here, Alice and the whole Bevy gang!

alice-i-cecile 4y ago
Finally blogging! I'm looking forward to writing and sharing more; it's been fun to hear everyone's perspectives.

Ericson2314 4y ago

Lol they are playing themselves a bit because stuff being "more than libraries glued together" is generally a bad thing!

hgs3 4y ago

> 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.

seba_dos1 4y ago
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.

Animats 4y ago

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. [1] https://github.com/John-Nagle/serde-llsd https://github.com/John-Nagle/serde-llsd

seba_dos1 4y ago
> 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.
- Animats 4y ago
  Typical issues: * 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.