Hacker News Reader

Comment by leetrout | Hacker News Reader

> Tim Sweeney and Epic Games for their confidence in helping us finance our research via Epic Megagrant.

That’s interesting. Since this is all open source I guess Epic could potentially benefit from this... It’s nice to see they funded another engine.

View on HN

From a business perspective, Unreal doesn't really do 2D as per se (Whereas Godot is very simple to use) so improving Godot keeps people away from other tools like Unity which do have features that compete with Unreal.

As a unity developer I'm drooling at godot. I can't wait to jump ship to open source. Don't get me wrong unity is great, but godot is super compelling.

I'm someone who isn't at all knowledgeable about game development nor its industry, so forgive my ignorance, but what are you waiting for specifically?

One thing many of the big players do that Godot doesn’t is require telling the user they used that engine. If you use Unity, you need to show the Unity splash screen unless you pay the big bucks; Godot requires none of that.

So why would someone wait for that feature before changing to Godot if that's already a feature?

For Unity, the "big bucks" is $35/seat/month -- that gets you the ability to make a build without a splash screen & without showing any Unity logos, etc.

For small shops (ie low or no revenue), you only need to pay that when you're ready to actually ship/make a build.

Note that the costs are higher if you're revenue is huge, it goes up to like >$100/seat/month or similar IIRC, I think that kicks in if you're in the 7-figures of annual revenue.

It's not free, and it can get expensive -- but you have to do the math on what you get, how much each will cost you monetarily & in time / opportunity cost, etc. IMO Unreal looks pretty compelling, and if they had C# support we'd jump to it in a heartbeat; I really don't want to write C++ on a day-to-day basis. If Godot keeps it up, then it may be the answer, in another 18 months or so -- but probably not wholly a commercially viable option quite yet, especially for mid-to-small shops.

Yes, why are you waiting for Godot?

Sorry, I’ll get my coat.

Not the OP, but I did jump into Godot full time for about three months last September. There were several significant land-minds that blew up in my face and it has made me lose some confidence in the core Godot team.

Without going into specifics, I think the problem is that the core team don't actually make games, they just work on an engine, so they don't appreciate the problems that I faced. (The same problem that Unity has, but at least they have the time to listen to devs)

I really want to love Godot. But I worry that the risks are too great to jump from Unity.

There's one thing that make me reluctant to use Godot though and it's GDScript.

Edit: Seems like it's not a problem anymore, can't wait to try again.

Doesn't Godot allow binding with multiple languages? You can even use Rust for that instead of GDScript.

The problem is few of those bindings are mature, nor can they be expected to remain up to date. I don't know of any games in Godot using anything but GDScript or C#.

This will probably change in the future (I hope it does, and I really wish Godot just used WASM internally so any language that already compiled to it would work) but as of now it seems there's no point to using anything but GDScript or C#.

You mean bindings aren't stable and require reworking all the time?

I mean that language support comes in the form of random third party projects like perbone/luascript[0], so stability and completeness are entirely up to the whims and capabilities of the owner.

It's open source, of course, so that's to be expected, but it also means support for any language other than C# and GDScript is kind of a crapshoot.

[0]https://github.com/perbone/luascript

C++ is very easy to use with Godot and integrate with the GDScript support. GDScript is also very good as a script language.

Been writing my own application mostly using C++ for the core logic and main application logic using GDScript. The interfacing between C++ and GDScript is suprisingly easy once you set it up.

But yeah stuff like Rust support is depending on the maintainers of that code to update to support latest versions of Godot.

There's C# and C++ support, with third-party bindings to other languages (Rust, Python, etc)

GDScript is very "python like", never feels like a hurdle.

Tell me more.

You're not wrong, gdscript is pretty awful. It's only python-like for someone who's never used python. No list comprehensions, no tuples (which means no destructuring in assignment or function parameters), no first class functions, etc. It's like Python 1.x circa 1999, only worse.

Godot will get to the point of competing with Unreal, no doubt about it. Especially since Epic do a poor job at making Vulkan renderer in Unreal work well, and Godot invested in Vulkan all the way.

Nah, people will not stop using Unreal because it doesn’t support Vulkan. (Sadly) DirectX 11/12 and Windows is still the standard platform in high-profile gamedev...

DX lock-in will die out. Better sooner rather than later, but even if later, it still will. MS won't be able to poison the industry with lock-in forever. So those who invest in Vulkan today will be ahead of those who don't.

Godot did the right thing to completely ignore DX and focus on Vulkan.

Well, in the same paragraph it goes on to say:

> ...and Tim Sweeney and Epic Games for their confidence in helping us finance our research via Epic Megagrant. This new technique was developed entirely in the open and implemented under MIT license, so anyone can take it for using in their own engines and games.

So there you go. Whatever Godot devs do, it's MIT and anyone can take. Epic gets an agile engine/team to do the research, and once a viable implementation exists they can analyze it and see it it's implementable within UE, should they want to.

Of course, I write this without knowing if Unreal Engine has SDF Global Illumination. Maybe they already have it, but wanted to finance a new alternative to compare against their own.

In general the unreal engine has had voxel based global illumination for a long time and in fact was where it entered the mainstream. It added signed distance field stuff a few years ago as well.

Godot is more likely to eat Unity's cake than Unreal Engine's cake.

Unity is currently the dominating engine among mobile games and 2D games.

And if it is to believe their numbers, the large majority of Switch games as well.

I may be naive but I think the coder in Sweeny likes to see what Godot is doing, and the skeptic in me thinks that Sweeny knows Godot would only ever really eat at Unity's marketshare.

I don't think there's anything naive about this take..

Why wouldn't a company like Epic, who is the dominant market player by far, put some funding into smaller open source research projects like this? Godot is no threat to them, and quite the contrary brings positive contributions to the whole industry.

Not only is it good PR, but as they say a rising tide lifts all boats.

Because Unreal doesn't scale down like Unity does, by improving Godot, they reduce Unity's attractiveness to the small coding communities.

Not sure what market you mean, Unity has a larger marketshare. Can't find a good source for numbers but a lot of places are quoting that Unity has 48% of the total market and Unreal has 13%. Also not sure how this is being measured, but in my experience Unity is more popular.

Numbers are misleading here. I don't have any stats but I think Unreal games make more money.

But the market here is game developers, not people who buy the games that developers make.

I think the metric Epic would be interested in would be the amount of royalties they would collect, so it would include the number of developers scaled by the financial success of their games. The financial success of the developers whose market share you capture matters a lot.

Godot is more likely to be used by people whose games wouldn't earn enough to cross the threshold where they would owe money to Epic had they used UnrealEngine, so keeping them away from Unity makes a lot of sense.

Only if you ignore the network effect of developers knowing your platform vs others...

Somewhat true. While it doesn’t matter to the end user what engine is used if it looks and runs the same, it does if one engine can’t compete in polish. And I don’t know about you, but I hate splash screens that just say (for example) “built with Unity”. (Yes, splash screens hide loading, but as a user, I don’t care what engine you used)

Measured by number of games that might be true, but measured by players I'd wager it's not.

Engine market share doesn't matter much if you're just going by games released.

Steam (the video game marketplace) gets hundreds of releases each day (seriously), and the vast majority of them are bad, and make no money.

I think if you're looking at serious money-making studios that put out good games (whether they are indie or AAA), I bet the engine distribution would look different than your numbers.

But that's my best guess..

An engine like UE which has decades and decades of work does not care about what a small engine like Godot does.

The grant is more about avoiding monopoly claims, getting good PR and attacking Unity.

Why would Epic put money into an open source competitor?

I could see funding open source that is complementary or, perhaps better, something your competitor makes money on. But this?

I was looking into Unreal for my next project, but Godot looks amazing. And they won't take a cut of my profits. It might do everything I need.

epic's biggest competitor is unity. Godot competes more with unity than unreal engine, and therefore, it's a strategic attack on unity.

Unless you are selling millions of copies I don't think Epic Games would care what engine you are using for your indie game.

Reply on news.ycombinator.com