Unity’s gotten better over time, but honestly janky-/blurry-looking text-rendering is still one of the giveaways that you’re playing a game made with Unity. I notice it the worst with computer card games or strategy games (where text rendering is tricky). Makes one miss flash... .
Godot puts localisation/internationalisation really way more in the foreground than Unity (having built-in support for it, while Unity does not, as well as having the development software itself being localised into far more languages than Unity), so it makes sense that this culture would also lead to better text support.
(disclaimer: I work with unity a lot - I’ve only done a one or two small projects in Godot, and would still recommend Unity above it generally)
Is there any solution or reason for the blurry text, even with TMPro? I'll be honest all my games have horrid text rendering because of that, and it's super frustrating, but I've never found a setting that fixes it (be it UI scaling shenanigans or in the TMP component itself)
I think there should be some randomo selection of settings that should make text-rendering tolerable with TMPro (crisp at most resolutions without using up your memory budget), but I haven’t touched it in a while, so can’t advise...
It actually does not relate to Go at all. It's a game engine and allows you to write scripts in it's own scripting language (which kind of looks like python), C#, and a visual graph language.
It has nothing to do with the go language, just a coincidence
>More choices than any other engine.
GDScript Python-like scripting language, designed to make games with zero hassle. Learn why our community loves it.
Full C# 8.0 support using Mono.
Full C++ support without needing to recompile the engine using GDNative.
Visual scripting using blocks and connections.
Additional languages with community-provided support for Rust, Nim, D and other languages.
Built-in editor with syntax highlighting, real-time parser and code completion.
Integrated documentation. Browse and search the whole API offline, without leaving the editor.
The name has nothing to do with Go the language; Just coincidence. It was taken from a play called Waiting for Godot.[0]
Internally, everything is C++ (and your code can also be written in it), but the bundled scripting language is called GDScript (it’s a bit of a mixture of Python, Lua, and others with some extra unique syntax sugar). However, it does support bindings to other languages. The most common being C# (using Mono), but people have gotten Rust to work (among others).
It's more because it's a fairly niche technique that requires either dual-source blending or constant blend colors, things that game rendering engineers don't think about often. It's also tricky to make work with transparency, which is the reason OS X ditched it. Basically, nobody in the video games space does it frequently.
Maybe I should clean up and open-source my subpixel text renderer that uses dual-source blending....
Subpixel text rendering also requires intimate knowledge of the display being rasterized for, and becomes a mess once you enter multiple displays with different pixel layouts. I was working on support in my font library https://github.com/mooman219/fontdue/, but it quickly becomes not worth it. I'm interested to see your approach to the problem if your project is online!
After you see really nice fonts, and get used to them, bad ones just drive you crazy. a 1440p or 4k monitor for instance, after having one you don't want to use a 1080p monitor for text any more!
I imagine for games its partly a performance issue that they don't do fancier font rendering sometimes.
You can do that! I've done it. I tapped into Uniscribe on Windows, Core Text on macOS, and PangoCairo on Linux. The problem is that this looks horrifically inconsistent between platforms. You also end up doing a ton of work to figure out how to accomplish a simple task like, "I want this text in this box, that word is italic, please add the line breaks, here is a font file." That's simple on one platform, but you end up having to duplicate everything you do across all the platforms you support, and typically you will find one platform that breaks your assumptions about how libraries should handle this task. Your code ends up being convoluted so it can hide the (major) differences between different APIs.
It's actually so much work that you probably want your game engine to do it internally in a way that is consistent cross-platform. Fortunately, most of the guts have already been figured out for you by the amazing people that work on HarfBuzz. The basic formula is to take your Unicode string, take your font, and feed it to HarfBuzz to have HarfBuzz figure out the metrics and glyph offsets. You then use the metrics to do layout and line breaks.
It is a lot of work, but it turns out to be less work than figuring out how to this working cross-platform using system libraries. This is also, generally speaking, how web browsers deal with their text. There are a couple other pieces that you need like text segmentation but these are tractable.
that is what you do a lot of times. but then what if the user resizes the window? do you just scale the texture and let it look like crap? do you draw new textures on resize events? same question RE user changing font size. what if the game has lots of varied font sizes. now you have a lot of textures. what if the font has features that depend on adjacent letters? then you can't just render every letter and slap them on the screen as needed when people type.
> Why not just use some system library to write into a texture and then use that in your game?
if you are making any non-trivial software that is supposed to run on two different operating systems, you never never never want to use the OS font rendering, as you'll get text slightly wider, line breaks at different places, stuff that fits neatly in a pixmap on Windows will be 3 pixels too wide on macOS and suddenly won't fit your button, baselines are a bit different, there's the 72 / 96 dpi mess, users will complain that their document don't look the same across OSes... it's an endless can of worms. Just ship & use freetype & harfbuzz everywhere (or use Qt which can do that for you automatically).
> This allows changing font size for individual draw calls, controls, or spans of text in the RichTextLabel control without creating new Font instances.
It was so frustrating to have different font sizes in a RichTextLabel.
Only downside is that we have to wait until Godot 4
It feels like complete mismanagement to me that Godot focuses on work like this instead of things that directly impact gameplay. You can see it in other places like them creating their own programming language.
Why can't I do multiplayer out-of-the-box? Why do I have to roll that myself? Why can't I start up a project and immediately work with gamerules/gamemode callbacks?
I can checkout Grid[1] and immediately do those things, and it has two orders of magnitude less followers. Why do "game engine" developers insist on doing essentially just rendering with some bindings to things like Box2D and OpenAL?
A massive selling point for Godot, is its relative simplicity, general purpose design, and unopinionated approach to development inside of it. Unlike many open source engines that have failed, Godot (esp. Since 3.x) tends to provide you with minimal abstractions, and focus its development efforts on polishing core features which more complex features can be built on top of. It offers a smaller core feature set than an engine like Unreal, but polishes what's there so well that it can compete on a commercial level
I personally believe much of its success is owed in large part to this kind of prioritization on fit and finish.
Its networking api is minimal, and easy to use. It helps you negotiate your initial connection, and then gets out of your way, so you can spend your time thinking about the information coming through the pipe.
A more opinionated system might be faster to get up and going, but would likely get in your way for more complex projects.
Much of godot's functionality is implemented in modules, which the engine can be optionally compiled without, and are easily added in by other developers.
On top of this, the engine has a plug-in ecosystem like Unity has, which allows functionality extension on a per-project basis.
This means that more opinionated networking features can be trivially appended to the engine's core feature set by the community, and shared or sold as developers see fit.
Imo, this is a win. Developers don't have to work around, bypass, or ship with a clunky networking model that seemed like a good idea at the time, and Godot devs don't have to maintain the potentially sprawling implementation of a feature that could very well get in somebody's way.
Wrt gdscript, it's something that existed in the engine before it was open-sourced, is tightly integrated into the engine's systems, and is easy to bind new code and methods to.
I don't think that the core vm has been touched too much since it was released, and it's fairly easy to ignore if you want to use C#, or C++ instead.
Godot exists in a space between something like Unreal, and older frameworks like XNA. It's small enough that a single person can wrap their head around it, offers a baseline set of tools, with a modern renderer (4.0 will have a more modern renderer). It's beginner friendly, but it rarely gets in the way of experienced devs as a result.
> Its networking api is minimal, and easy to use. It helps you negotiate your initial connection, and then gets out of your way, so you can spend your time thinking about the information coming through the pipe.
This doesn't mean anything at all if you've actually built a game before. You can do this with ENet alone, which means they haven't done anything for you.
> A more opinionated system might be faster to get up and going, but would likely get in your way for more complex projects.
There's effectively no difference in its multiplayer offering and a GitHub project with under 100 stars and a month's development work binding rendering APIs to a popular programming language. You literally have to do everything yourself.
> Much of godot's functionality is implemented in modules, which the engine can be optionally compiled without, and are easily added in by other developers.
On top of this, the engine has a plug-in ecosystem like Unity has, which allows functionality extension on a per-project basis.
None of this means anything at all. You're just saying people have to create their own work, but hey, since it's in a "module" that makes it good!
> Imo, this is a win. Developers don't have to work around, bypass, or ship with a clunky networking model that seemed like a good idea at the time, and Godot devs don't have to maintain the potentially sprawling implementation of a feature that could very well get in somebody's way.
Yeah you're right, and the end result is basically no one does multiplayer or does it well, because most people using Godot don't know what they're doing to begin with. It's easy to not get in somebody's way when you do nothing at all, isn't it?
> Wrt gdscript, it's something that existed in the engine before it was open-sourced, is tightly integrated into the engine's systems, and is easy to bind new code and methods to.
As far as I know, they spent Mozilla funds to continue developing it versus features actual game developers care about.
I don't really see a difference between what it offers in terms of meaningful features, and what someone experienced could throw themselves in 3-6 months time.
> This doesn't mean anything at all if you've actually built a game before. You can do this with ENet alone, which means they haven't done anything for you.
They've integrated it into the engine, tested it across multiple platforms, exposed its methods via the language bindings interface, and abstracted away memory management if you don't want to think about it. They've also written a simple protocol that allows for remote procedure calls on the scene-tree that abstracts away the lower-level networking components. That's not nothing.
> There's effectively no difference in its multiplayer offering and a GitHub project with under 100 stars and a month's development work binding rendering APIs to a popular programming language. You literally have to do everything yourself.
The difference is every other feature of the engine.
> None of this means anything at all. You're just saying people have to create their own work, but hey, since it's in a "module" that makes it good!
I'm saying that the engine allows anyone who wants a feature to add it without requiring low-level development efforts, or getting the devs to accept a feature commit to make it generally available. This doesn't excuse every missing feature in the engine by a long-shot. But it does mean that the engine, and its development team can focus on getting the boring things right, and can reasonably expect their community to fill in the blanks over time.
> Yeah you're right, and the end result is basically no one does multiplayer or does it well, because most people using Godot don't know what they're doing to begin with. It's easy to not get in somebody's way when you do nothing at all, isn't it?
Most people using any game engine don't know what they're doing. And once again, I think you're exaggerating when you say, 'nothing at all'. Minimal? Yes.
> As far as I know, they spent Mozilla funds to continue developing it versus features actual game developers care about.
Per their blog posts, the 2019 Mozilla grant was used to fund the following things game developers don't care about:
1. Godot's Browser support
2. Improving Networking documentation, and debugging features, refactoring their TCP/UDP layer, implementing DTLS over UDP
> I don't really see a difference between what it offers in terms of meaningful features, and what someone experienced could throw themselves in 3-6 months time.
At the very least, 3-6 months of development time. Some of which could likely be used to implement a networking protocol.
But more seriously, you get a solid, well-documented, increasingly refined engine with a permissive license that's actively being tested and maintained across multiple platforms and hardware configurations.
The engine has several dedicated developers working full-time that you don't have to pay for, who are often happy to answer any questions you may have, and a large community to provide free support whenever they're unavailable or unwilling to help.
You also have a young but growing plug-in ecosystem whose developers seem to love sharing their source code.
Most of the features that are there are fairly mature, and are actively being battle-tested by novice and dumb developers with a gift for finding edge cases and breaking things.
An experienced developer could certainly approximate Godot's feature set in six months. Of that, I have no doubt. But I really think you're underestimating the team, and what it's achieved.
> This doesn't mean anything at all if you've actually built a game before. You can do this with ENet alone, which means they haven't done anything for you.
I write multiplayer games for a living, and the thought of an built in multiplayer system that does more than ship bytes around and maybe help out with serialization is a red flag.
Do you want to build a strategy game, an FPS, a MMO or a fighting game? Well that's four completely different architectures.
Engines that ship with built in multiplayer tend to be a step up in flexibility from modding a game.
Great, I ship engine software that gets used by game developers.
A strategy games, FPS, and fighting game all have the same networking model. An MMO is the only one that doesn’t, and yet you still have a subset of the prior in the later. So no, engines should provide more.
This is just not true. The vast majority of strategy games use deterministic simulations with input delay. Fighting games generally use what is essentially event sourcing from inputs with rollback. Neither of these look anything like the client side prediction you'd build an FPS on.
I personally know a AAA project that tried to build a strategy game on a rock solid FPS engine's netcode and it was a disaster that sunk it single handedly.
And that's before we get in to asynchronous, async/sync hybrid, trusted peer to peer (used a lot for coop games to lower server costs), multiplayer idle games, hybrid deterministic with trusted peer to peer (eg you can move around freely but gameplay modifying actions are scheduled in advance).
It's a complicated and vibrant field and one size does not fit all. There are just parts you can abstract away and provide libraries for.
All multiplayer is asynchronous you donut. Asynchronous game rules have nothing to do with asynchronous networking.
> async/sync hybrid
Pulling stuff out of your behind.
> trusted peer to peer (used a lot for coop games to lower server costs)
No such thing. There is no "trust" in multiplayer. If you write a peer to peer game, you're open to cheating.
> multiplayer idle games
What?
> hybrid deterministic with trusted peer to peer
Pulling stuff out of your behind.
At the end of the day, entities, objects, actors, whatever you want to call them, have networked fields and they're serialized and transmitted. Game rules state is networked. Developers choose what they want to network. The engine determines what is sent and what is not.
This lattermost piece is where things can get complicated based on whether or not information needs to be sent, shouldn't be sent, is sent by visibility or audibility, is sent by quad tree node, etc.
But there's no different architecture for it. That's plainly stupid. There's nothing about these made up designs you're talking about that stops the need for entities to have watched fields that get serialized and transmitted based on transmission rules.
All of these systems exist in real games I have first hand knowledge of.
What I'm taking from this conversation and looking at your engine is you're very familiar with the Source way of doing things, but ignorant of other work in the field.
If you were being pleasant I'd be happy to go in to specifics, but you aren't, so I won't.
Although I will say this:
> There's nothing about these made up designs you're talking about that stops the need for entities to have watched fields that get serialized and transmitted based on transmission rules.
Over a million people have played my multiplayer games, and they are not implemented this way.
All multiplayer is deterministic. You can't have networked multiplayer without determinism.
> event sourcing from inputs with rollback
This is the exact same thing as rollback in FPS games. It works the same way.
> I personally know a AAA project that tried to build a strategy game on a rock solid FPS engine's netcode and it was a disaster that sunk it single handedly.
Fascinating, because Valve literally did it with DOTA.
42 comments
[ 2.7 ms ] story [ 107 ms ] threadGodot puts localisation/internationalisation really way more in the foreground than Unity (having built-in support for it, while Unity does not, as well as having the development software itself being localised into far more languages than Unity), so it makes sense that this culture would also lead to better text support.
(disclaimer: I work with unity a lot - I’ve only done a one or two small projects in Godot, and would still recommend Unity above it generally)
I wish they didn't go with C#, I keep trying to use const-correctness and getting annoyed
It has nothing to do with the go language, just a coincidence
>More choices than any other engine.
Internally, everything is C++ (and your code can also be written in it), but the bundled scripting language is called GDScript (it’s a bit of a mixture of Python, Lua, and others with some extra unique syntax sugar). However, it does support bindings to other languages. The most common being C# (using Mono), but people have gotten Rust to work (among others).
[0]: https://en.wikipedia.org/wiki/Waiting_for_Godot
As I understand it, subpixel rendering is a treacherous patent landscape. Is that the reason why it is consistently missing from these tools?
edit: seems like it wasn't too long ago.
https://www.freetype.org/patents.html
Maybe I should clean up and open-source my subpixel text renderer that uses dual-source blending....
I imagine for games its partly a performance issue that they don't do fancier font rendering sometimes.
Why not just use some system library to write into a texture and then use that in your game?
It's actually so much work that you probably want your game engine to do it internally in a way that is consistent cross-platform. Fortunately, most of the guts have already been figured out for you by the amazing people that work on HarfBuzz. The basic formula is to take your Unicode string, take your font, and feed it to HarfBuzz to have HarfBuzz figure out the metrics and glyph offsets. You then use the metrics to do layout and line breaks.
It is a lot of work, but it turns out to be less work than figuring out how to this working cross-platform using system libraries. This is also, generally speaking, how web browsers deal with their text. There are a couple other pieces that you need like text segmentation but these are tractable.
fonts are hard
if you are making any non-trivial software that is supposed to run on two different operating systems, you never never never want to use the OS font rendering, as you'll get text slightly wider, line breaks at different places, stuff that fits neatly in a pixmap on Windows will be 3 pixels too wide on macOS and suddenly won't fit your button, baselines are a bit different, there's the 72 / 96 dpi mess, users will complain that their document don't look the same across OSes... it's an endless can of worms. Just ship & use freetype & harfbuzz everywhere (or use Qt which can do that for you automatically).
> This allows changing font size for individual draw calls, controls, or spans of text in the RichTextLabel control without creating new Font instances.
It was so frustrating to have different font sizes in a RichTextLabel.
Only downside is that we have to wait until Godot 4
Why can't I do multiplayer out-of-the-box? Why do I have to roll that myself? Why can't I start up a project and immediately work with gamerules/gamemode callbacks?
I can checkout Grid[1] and immediately do those things, and it has two orders of magnitude less followers. Why do "game engine" developers insist on doing essentially just rendering with some bindings to things like Box2D and OpenAL?
[1]: https://github.com/Planimeter/grid-sdk
I personally believe much of its success is owed in large part to this kind of prioritization on fit and finish.
Its networking api is minimal, and easy to use. It helps you negotiate your initial connection, and then gets out of your way, so you can spend your time thinking about the information coming through the pipe.
A more opinionated system might be faster to get up and going, but would likely get in your way for more complex projects.
Much of godot's functionality is implemented in modules, which the engine can be optionally compiled without, and are easily added in by other developers.
On top of this, the engine has a plug-in ecosystem like Unity has, which allows functionality extension on a per-project basis.
This means that more opinionated networking features can be trivially appended to the engine's core feature set by the community, and shared or sold as developers see fit.
Imo, this is a win. Developers don't have to work around, bypass, or ship with a clunky networking model that seemed like a good idea at the time, and Godot devs don't have to maintain the potentially sprawling implementation of a feature that could very well get in somebody's way.
Wrt gdscript, it's something that existed in the engine before it was open-sourced, is tightly integrated into the engine's systems, and is easy to bind new code and methods to.
I don't think that the core vm has been touched too much since it was released, and it's fairly easy to ignore if you want to use C#, or C++ instead.
Godot exists in a space between something like Unreal, and older frameworks like XNA. It's small enough that a single person can wrap their head around it, offers a baseline set of tools, with a modern renderer (4.0 will have a more modern renderer). It's beginner friendly, but it rarely gets in the way of experienced devs as a result.
This doesn't mean anything at all if you've actually built a game before. You can do this with ENet alone, which means they haven't done anything for you.
> A more opinionated system might be faster to get up and going, but would likely get in your way for more complex projects.
There's effectively no difference in its multiplayer offering and a GitHub project with under 100 stars and a month's development work binding rendering APIs to a popular programming language. You literally have to do everything yourself.
> Much of godot's functionality is implemented in modules, which the engine can be optionally compiled without, and are easily added in by other developers. On top of this, the engine has a plug-in ecosystem like Unity has, which allows functionality extension on a per-project basis.
None of this means anything at all. You're just saying people have to create their own work, but hey, since it's in a "module" that makes it good!
> Imo, this is a win. Developers don't have to work around, bypass, or ship with a clunky networking model that seemed like a good idea at the time, and Godot devs don't have to maintain the potentially sprawling implementation of a feature that could very well get in somebody's way.
Yeah you're right, and the end result is basically no one does multiplayer or does it well, because most people using Godot don't know what they're doing to begin with. It's easy to not get in somebody's way when you do nothing at all, isn't it?
> Wrt gdscript, it's something that existed in the engine before it was open-sourced, is tightly integrated into the engine's systems, and is easy to bind new code and methods to.
As far as I know, they spent Mozilla funds to continue developing it versus features actual game developers care about.
I don't really see a difference between what it offers in terms of meaningful features, and what someone experienced could throw themselves in 3-6 months time.
They've integrated it into the engine, tested it across multiple platforms, exposed its methods via the language bindings interface, and abstracted away memory management if you don't want to think about it. They've also written a simple protocol that allows for remote procedure calls on the scene-tree that abstracts away the lower-level networking components. That's not nothing.
> There's effectively no difference in its multiplayer offering and a GitHub project with under 100 stars and a month's development work binding rendering APIs to a popular programming language. You literally have to do everything yourself.
The difference is every other feature of the engine.
> None of this means anything at all. You're just saying people have to create their own work, but hey, since it's in a "module" that makes it good!
I'm saying that the engine allows anyone who wants a feature to add it without requiring low-level development efforts, or getting the devs to accept a feature commit to make it generally available. This doesn't excuse every missing feature in the engine by a long-shot. But it does mean that the engine, and its development team can focus on getting the boring things right, and can reasonably expect their community to fill in the blanks over time.
> Yeah you're right, and the end result is basically no one does multiplayer or does it well, because most people using Godot don't know what they're doing to begin with. It's easy to not get in somebody's way when you do nothing at all, isn't it?
Most people using any game engine don't know what they're doing. And once again, I think you're exaggerating when you say, 'nothing at all'. Minimal? Yes.
> As far as I know, they spent Mozilla funds to continue developing it versus features actual game developers care about.
Per their blog posts, the 2019 Mozilla grant was used to fund the following things game developers don't care about:
1. Godot's Browser support
2. Improving Networking documentation, and debugging features, refactoring their TCP/UDP layer, implementing DTLS over UDP
3. Assets for showcase and benchmarking demos
https://godotengine.org/article/godot-engine-awarded-50000-m...
> I don't really see a difference between what it offers in terms of meaningful features, and what someone experienced could throw themselves in 3-6 months time.
At the very least, 3-6 months of development time. Some of which could likely be used to implement a networking protocol.
But more seriously, you get a solid, well-documented, increasingly refined engine with a permissive license that's actively being tested and maintained across multiple platforms and hardware configurations.
The engine has several dedicated developers working full-time that you don't have to pay for, who are often happy to answer any questions you may have, and a large community to provide free support whenever they're unavailable or unwilling to help.
You also have a young but growing plug-in ecosystem whose developers seem to love sharing their source code.
Most of the features that are there are fairly mature, and are actively being battle-tested by novice and dumb developers with a gift for finding edge cases and breaking things.
An experienced developer could certainly approximate Godot's feature set in six months. Of that, I have no doubt. But I really think you're underestimating the team, and what it's achieved.
I write multiplayer games for a living, and the thought of an built in multiplayer system that does more than ship bytes around and maybe help out with serialization is a red flag.
Do you want to build a strategy game, an FPS, a MMO or a fighting game? Well that's four completely different architectures.
Engines that ship with built in multiplayer tend to be a step up in flexibility from modding a game.
A strategy games, FPS, and fighting game all have the same networking model. An MMO is the only one that doesn’t, and yet you still have a subset of the prior in the later. So no, engines should provide more.
I personally know a AAA project that tried to build a strategy game on a rock solid FPS engine's netcode and it was a disaster that sunk it single handedly.
It's a complicated and vibrant field and one size does not fit all. There are just parts you can abstract away and provide libraries for.
All multiplayer is asynchronous you donut. Asynchronous game rules have nothing to do with asynchronous networking.
> async/sync hybrid
Pulling stuff out of your behind.
> trusted peer to peer (used a lot for coop games to lower server costs)
No such thing. There is no "trust" in multiplayer. If you write a peer to peer game, you're open to cheating.
> multiplayer idle games
What?
> hybrid deterministic with trusted peer to peer
Pulling stuff out of your behind.
At the end of the day, entities, objects, actors, whatever you want to call them, have networked fields and they're serialized and transmitted. Game rules state is networked. Developers choose what they want to network. The engine determines what is sent and what is not.
This lattermost piece is where things can get complicated based on whether or not information needs to be sent, shouldn't be sent, is sent by visibility or audibility, is sent by quad tree node, etc.
But there's no different architecture for it. That's plainly stupid. There's nothing about these made up designs you're talking about that stops the need for entities to have watched fields that get serialized and transmitted based on transmission rules.
What I'm taking from this conversation and looking at your engine is you're very familiar with the Source way of doing things, but ignorant of other work in the field.
If you were being pleasant I'd be happy to go in to specifics, but you aren't, so I won't.
Although I will say this:
> There's nothing about these made up designs you're talking about that stops the need for entities to have watched fields that get serialized and transmitted based on transmission rules.
Over a million people have played my multiplayer games, and they are not implemented this way.
> event sourcing from inputs with rollback
This is the exact same thing as rollback in FPS games. It works the same way.
> I personally know a AAA project that tried to build a strategy game on a rock solid FPS engine's netcode and it was a disaster that sunk it single handedly.
Fascinating, because Valve literally did it with DOTA.