Video game engines absolutely handle text rendering across a wide range of languages. Not all games involve complex text input, but it’s a sufficiently common need that’d I’d expect a generic engine to support robustly.
Accessibility is often language in game technology. That should be better.
To be honest my first reaction was negative to this idea. But if your comments and links have done anything it’s convince me that maybe this isn’t a bad idea after all!
> Video game engines absolutely handle text rendering across a wide range of languages.
They handle specific subsets of text rendering across a wide range of languages. There's a ton of interactions with the OS-level text interactions that are both difficult to fully enumerate and even more difficult to re-implement non-natively. Font programming can get really, really complex—some of it might be perceived as unnecessary—ligatures, proper kerning, certainly sub pixel rendering, glyph variants, arguably emoji—but others will really suck, like poor interactions with highlighting and cursor movement; replicating native keybindings; replicating differences in how e.g. linux and Macs kill, yank, copy, cut, paste, etc; replicating differences in how "paragraphs" are split into "lines" (logical or visual?) across platforms.... this isn't even touching the complexity of processing input (do you really want to implement wubi chinese? Do you know how to properly handle unicode normalization the same way the local editor does so that typing the same keystrokes causes the same behavior? how about differences between punctuation glyphs between scripts? Are you even handling hyphenation correctly? Does it reflow as expected when the layout constraints change?) and simply processing unicode in a consistent and well-behaved manner.
(and of course this isn't even touching attributed text or rich text editing or combining fonts on a single line....)
> Accessibility is often language in game technology
I'm no expert, but accessibility concerns must be wildly different in a game than in a data-heavy or prose-heavy app. I can't imagine implementing a screen reader without relying heavily on the OS....
> They handle specific subsets of text rendering across a wide range of languages.
People radically overstate how hard this is. Yes there’s a lot of cases. But God bless UTF-8 which provides a very clear path.
There are countless hobby text editors and libraries that handle literally all of this.
> I can't imagine implementing a screen reader without relying heavily on the OS....
Of course. You “just” need to use the documented OS APIs. It’s not trivial. But like it’s not that hard to use the APIs that lots of programs and libraries already use.
> But God bless UTF-8 which provides a very clear path.
It's a very clear middle finger for CJK users if text rendering issues were dismissed because "we do UTF-8." Thanks to the Unicode Consortium, letters from CJK languages have shared code points in Unicode. This makes it very easy to have, for example, Chinese style fonts sprinkled over Japanese text. This kind of mixed styles are aesthetically inconsistent, unpleasant, and hard to read.
I never said it was impossible, I just said that a lot of what's currently possible in game engines is absolutely dogshit compared to even Electron. This is not really an opinion, the features just aren't implemented yet, and UX is not a concern.
And I never said video games can't handle text. I said it currently can't do it at the same level as the OS or browser, with all the features.
Implementing is of course possible. But unlike something like React Native, or Electron, if you want to keep the rendering model of game engines, you won't be able to leverage 40+ years of OS development and 30+ years of browser development. You gotta restart from scratch. The ceiling here is something like Flutter, which cost Google millions of dollars.
It even remains to be seen if performance will be even comparable to Electron if someone implement all the missing features.
> "Accessibility is often language in game technology. That should be better."
There are exactly zero game engines or game engine libraries currently that provide the automatic accessibility at the level of something like Electron. This is something else that must be rebuilt from scratch.
> And I never said video games can't handle text. I said it can't handle at the same level as the OS or browser.
The actual metric is “can they handle text at a sufficient level”. I’m inclined to say yes.
> Due to the rendering model of game engines, you won't be able to leverage 40+ years of OS development and 30+ years of browser development. You gotta restart from scratch.
Oh baby don’t threaten me with a good time.
Web browsers are kinda terrible at UX. Native mobile apps are sooo much better than web.
> There are exactly zero game engines or game engine libraries currently that provide the automatic accessibility at the level of something like Electron. This is something else that must be rebuilt from scratch.
It’s weird that you say “nothing to level of electron and therefore must start from scratch”. As if there aren’t already libraries and utilities to build off of. At the end of the day electron “just” uses the documented Windows API! It’s not a trivial project. But it’s hardly insurmountable.
Hmmm, I don't know what's this about "actual metric". Is it "sufficient" for simple projects? Sure. Is it as good as Electron in terms of UX, and look/feel? No, it's not even close. Because Electron is doing native rendering.
Let me try to explain a different way:
- You are saying that native is better. Sure. UX is better, look and feel is better, rendering, accessibility (in most cases), consistency, configurability.
- Electron leverages native for a lot of functionality, so it is able to provide good quality. With light styling and semantic tags, it will use a lot of native functionality and will look exactly like the OS.
- Game engines can't use native to the extent that Electron does, because the rendering model is fundamentally different (as explained in one of the links), so it must use libraries that don't exactly have the look/feel/quality of native and must simulate it. It doesn't get as far from native than that.
> It’s weird that you say “nothing to level of electron and therefore must start from scratch”.
But this is true. There is currently nothing close to Electron accessibility in the game world. I'm not talking about base-level accessibility. Check the kind of accessibility provided by browser engines and operating systems, and you'll see it is a lot of work already cut out for developers.
Are there libraries? Of course there are, I never disputed that. I actually managed to sneak a few commits and opened a few issues in AccessKit, which is a Rust accessibility library that can be integrated with game engines. But it's still early days compared to what Electron can do.
Sure. But there's no argument here. Me and others are merely answering your questions. You said above "I'm legitimately asking. I don't know." I'm assuming this was said in good faith.
Accessibility is often language in game technology. That should be better.
To be honest my first reaction was negative to this idea. But if your comments and links have done anything it’s convince me that maybe this isn’t a bad idea after all!