W4 Games raises $15M to drive video game development with Godot Engine

Godot seems to be MIT licensed. So anyone is free to create a proprietary fork if they want to. I can’t imagine this will be a problem as I suspect that the community is large enough that development of the OSS version would continue anyway, but the lack of CLA doesn’t seem relevant here.

> "Console support" seems a little bit thin

Look at it this way: There's a good chance that more console games will be published using Godot than any other engine.

Reading the FAQ it seems they are not affiliated with Godot, nor control any of it aspects. https://w4games.com/faq/ It seems they plan (https://w4games.com/products/) to make money by creating a BaaS/SaaS platform and selling tools to make the Godot games easier to port to consoles.

Console support and porting effort in general is the main biz of some companies, the most popular being M2 (mostly emulators) and MP2 Games (handles Clickteam Fusion ports to console like Freedom Planet, Baba is You), but there are many other smaller studios. They mostly seem to have their own proprietary tech. That kinda work also can't be open source as official console SDKs are expensive and covered by NDAs.

If the next Undertale/Minecraft gets built in Godot, W4 Games would be the easiest way to get that game to consoles and rack in tons of royalties, so I think the investment is justified (though hoping it doesn't poison Godot in some way)

I have no insider information, and I know little about this transaction.

However, I have done COSS business models before. This sort of thing is ridiculously easy to monetize. You can look at Red Hat, MongoDB, and many other platforms to see how this works. The key is usually services.

Broadly, there are two types of service contracts:

- Low-cost. Find developers / support people / admins / ... in India for $10-$100/day.

- High-quality / money is not a issue. Find the best people (think BCG, McKinsey, law firms, boutique UX consultancies) and pay them $500/hour.

Something like Godot is used a lot in places you wouldn't expect. Major video games and kids learning are the high-visibility uses, but there's a lot of game-like systems used in corporate, military, and government settings built on systems like Godot, Unity, and Unreal Engine.

If you're developing an experimental airplane which _must_ work, costs hundreds of millions of dollars, and hinges on a pilot training system being developed, or you're making a marketing tool in a winner-takes-all-market worth a billion, you're very much in the later category of shops you'll outsource to.

If you're the major developer or contributor to an open ecosystem, you become the go-to shop for the latter. If something needs fixing in the core tool to make the app you're developing work, you have people in-house who can fix it.

A lot of these are also places with less than impressive competence to vet vendors (most specialize in another industry), and "major developer of Godot" is an easy way to not screw it up. It's the same reason people hire name-brand law firms or management consulting firms: it's not the best choice, but if you don't know better and need a problem solved, it's a safe choice.

An asset store might be the fastest way to build a platform that makes money for them.

From a cursory search it seems there are large games build in Godot. Sonic Colors: Ultimate seems to be an example.

To replace Unity? Yes, and if there is something missing, you just clone Godot and fix it yourself. I can compile the whole engine in 2 minutes. There are currently some limitations for AAA games in the rendering pipeline, see Clay John's nice talk about this, from the last Godot con[1]. For example, at the company I work for we use Godot 4 to recreate Google Earth with OSM data :)

[1] https://www.youtube.com/watch?v=MW3IFMvDTCY

Unity itself was once seen as the "mobile and hobbyist platform" compared to "big kid engines" like frostbite, cryengine and unreal.

I think Godot is there, and they are seeing the start of adoption by AAA devs even before the Unity licensing shenanigans. But as Unity's own rise shows, it's not going to be a matter of flipping a switch and having comparable share amongst big games tomorrow.

It's probably also worth mentioning that it's possible to build pretty much any game in any framework, or without, it's just a matter of time and effort. Like LWJGL still is seen as a "toy" framework despite being in one of the most successful video games of all time (Minecraft). Factorio used just Allegro as a layer on top of SDL before migrating to bare SDL2. Conversely, many of the technical problems for KSP1 or Cities Skylines 2 have been attributed to Unity being a poor fit, despite being widely recognised as having "made it" into the "real engines" tier. There were also some EA developers with not very nice things to say about frostbite for games that don't look like Battlefield in the era where EA was pushing for all their devs to adopt it.

As far as I am aware, there is nothing intrinsically preventing people using it.

I have no experience in building big titles or even commercial games, but I see no obvious "blockers" to building a large and complex 3d game. It's not like Godot itself limits you to only doing basic 2d platformers or whatever - it seems as flexible and power as unity.

Sure you might not have all the same eye candy as the very latest unreal engine or whatever, so AAA quality titles might be out, and I am not sure what the multiplayer stack is like, but it seems like the fundamentals are there and so there is nothing to hold people back.

> Is it really possible to build games line Cities Skylines, Subnautica, Rust, Outer Wilds, KSP, Ori... in Godot? Is this more of a long term ambition at this point, or is it possible for this kind of game to be built in Godot today?

This might be a bit silly, but when it comes to engines and tools in regards to graphical fidelity and larger projects, I like to think of it in 3 broad categories:

  * Impossible - you're not making the next Crysis in GameMaker, Construct, or RPG Maker. Period.
  * Unviable - you could technically rip out and replace 50% of jMonkeyEngine or NeoAxis with something more performant and better, if you had near-unlimited resources; except we both know it's not happening.
  * Viable - you could take an off-the-shelf engine like Unity or Unreal and with a large amount of work achieve your goals, with varying degrees of success.

Godot was strictly in the "unviable" group during its 2.X and 3.X releases, but is getting better now (new renderer, nice LOD functionality, good C# support in addition to GDScript when you don't want to program gameplay in C++) and thanks to community efforts missing functionality is also getting added (like the terrain plugins, the older of which were sometimes quite broken): https://godotengine.org/asset-library/asset It still doesn't have that big of a commercial ecosystem around it (like Unity does) and still feels a bit half baked at times and getting the same things you could get out of Unity or Unreal working would take more work for larger projects... but it feels more and more doable.

Then again, currently Godot is hands down better for smaller projects, a lot of indie games, game jam games and quick prototyping, both Unity and Unreal feel too sluggish and heavyweight for that (and Unity in particular is a mess because of the whole legacy pipeline/URP/HDRP situation, DOTS, multiple input systems, multiple UI solutions and just so much fragmentation). Not every game needs to have the scale of the ones previously listed, actually most don't and should better manage their scope and could still be wildly successful.

Overall, it feels trending upwards and I'm curious to see where Godot will be in 5-10 years. If you tried right now, you'd just have all the normal early adopter struggles.

I would guess medium term, short term if there's a specific roadblock that happens to get a lot of attention. My understanding is that Unity's got certain things in a more sophisticated but less elegant form, where Godot seems to want to do everything 'correctly' even if it imposes performance penalties.

Making Godot, less 'klugey' but less performant.

The trouble with maximizing Unity the way professional devs do, is that you have to know which kluges to use and which to avoid. It's somewhat impractical and the end result still isn't that awesome: some of those games you mention are hitting a performance wall even though they're in Unity.

I don't think Godot is really on par with Unity in the 3d performant space in all respects, but I think that could change quickly, and what will happen is that it'll catch up over the medium term without going totally klugey. I'd give it a couple years to get there. Right now I think you'd have to design around what's not currently performant enough.

The W4 founders are the project founders and many of the top contributors to Godot Engine. Godot has always done what for me is the right thing for the continued open source nature of the project, including limiting any organisation's members on the leadership committee, assigning trademark rights to a foundation and not naming their company Godot Engine, LLC (unlike, say, Gitea).

So structurally it's the safest open source project against a future source available pivot, but there are some concerns such as the separation of the Godot foundation from it's parent organisation or a "de facto control" fork.

I think on the other hand, they do have a more clear selling point vs do it yourself on the open source projects. For IP reasons, console manufacturers don't permit the console integration part to be open source, so that's the bit that W4 has that the open source project can never compete with (though other companies building on the open source project could of course build their own).

They donate a lot of code back to the engine, w4 has already contributed an entire directx renderer to the engine that they needed to build out for their console porting efforts anyway.

> I am afraid it's still a very long way before they become for game development what Blender is for 3D modelling these days

Makes sense. Blender is coming up to being 30 years old soon, and it still isn't heavily embedded into the mainstream pipelines, but it's getting closer every day.

By contrast, Godot is about 10 years old, but still has eaten some of Unity's pie. Cannot wait to see how Godot is in about 20 years, surely they will have surpassed Unity at that point :)

Serious / non-leading / non-rhetorical question: What are the gaps?

Unity was never FOSS. Nor was Figma, to my knowledge

It kinda does sound like EEE.

„W4 Games will strengthen our role within the Godot ecosystem by supporting its open-source development and continuing to build products and services to facilitate Godot’s expansion, such as W4 Consoles (an approved middleware console porting solution for Godot games) and W4 Cloud (multi-tenant service to support millions of users).”

Unity still has a more mature product compared to Godot, so for many projects it won’t be feasible to switch to Godot.

Unity is easier to use, has more fully featured and higher quality rendering pipelines, more integrations with other software, a larger asset store and the ability to quickly add advertisements to a game using Unity Ads. (etcetera)

That said, we stopped using Unity because of the term changes and are now focusing on building a custom game engine, but our use case is way different than game studios.

In game studios it’s a numbers game. e.g. How much does it cost to retrain our staff to switch to a different engine versus the benefits. From what I can see, Unity has not yet made its product so unattractive that it won’t be used for future productions.

It is business as usual for big studios, maybe a couple of indies decided to port their games to GDScript or do not care about the platforms where C#/Godot isn't available.

Godot currently doesn't even have good support for things like in-app purchases for iOS/Android. No one is willing to work on stuff like that for free/open-source fun.

I think the big moat is that for studios, games are so risky to make, that there's no reason to take on tech risk by possibly running into issues like this. You know Unity will work for basically any non AAA game you want to make.

Hopefully this $15m closes that gap.

Their moat is massive for mobile apps.

For PC + console, I think their clock is ticking. Godot has many disadvantages (fewer features, large performance problems, asset store, poor UI) but they'll eventually fix them and perhaps become the dominant engine. The only question is how much further ahead Unity will be.

GIMP seems actively hostile to giving people what they want: a Photoshop clone. Even projects which would revamp the interface to be more Photoshop like were given the cold shoulder.

At this point I have fully switched to Krita. I am not a real artist and am only ever making little doodles for my apps, but the developers seem more in tune with what users need.

"Investors"

I'm guessing once Zig is at 1.x (breaking changes before then), "real contenders" for C++ engines might shape up to on-par within the first few years of that point. (I mean the subset of such projects without prior or subsequent abandonment.)

> I would even prefer C to C++

Assuming you want to game-dev not engine-dev, the above is quite the doable rule for your "C++" codebase under your own oversight and maintenance even though including some C++ engine and calling its APIs, right? (Apart from the fact that some-not-all of them expose some capi `.h`s from what I've seen.)

Most of them might (assuming here I know) anyway tend toward the lean-and-mean none-too-OOP way of doing things, data-oriented designs etc.

My (newbie) C++ is C (structs + funcs) but with struct methods and occasional light inheritance, aka Go-like (methods and embeds). The std::string too seems alright-enough right now (vs. a hand-rolled slice-of-T-being-uint8_t struct-making macro) as long as there's no mass string handlings going on, in which case it'll have to be evaluated more seriously.

I think Godot started before Rust took off, so they didn't have better alternatives then. The jury is still out on whether other C++ competition has any staying power, and even Rust still has some deficiencies compared to C++

IIRC the standard Unity Assets store license does allow using assets in other engines. And maybe you also wanna check out KenneyNL if you are looking for open assets for various small stuff.