2. Given the list and impact of 3rd party contributors and the absence of a CLA I think there is little ability for them to change the licensee in the future to something proprietary (nor is there any indication that the current key people at W4/Godot would want to do something like this)

3. That said, how do the venture capital companies hope that W4 makes them back their investment and a healthy profit on top. To be crystal clear, there is nothing wrong with that but I would like have it out in the open before. "Console support" seems a little bit thin although I'm ready to admit that I may not know enough about the industry.

If anyone could provide some additional information I'd be very thankful.

Edit: personally I prefer the open stewardship model like Blender or the Linux foundation where it is clear that Major financial contributors expect to get software for their own businesses out of it and support an open project in order to share costs and have a say in the direction it takes.

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)

> W4 Games is working on a complementary offering that is simpler in nature. We are developing and plan to offer fully middleware approved console ports for all platforms (Nintendo, Microsoft and Sony). This will place Godot in the same category (and offer the same assurances) as the large commercial game engines.

> Instead of offering porting services (which are still required by many developers and publishers), W4 Games will offer fully working console ports. These ports are intended to be middleware approved, meaning that the console manufacturer approves the port and certifies that it meets the required standards of quality, as well as supporting the full (or as close as possible) feature set of the console, including full integration to the console SDKs (for ease of development and deployment).

It seems like 2 of the 4 founders are also members ins the Godot board of directors and if I recall W4 has a strong voice in the Godot development team.

Maybe I'm just to pessimistic these days. (That speaks for Godot being a good project people care about).

I missed that. I'm glad if Godot remains independent. VC funded OSS projects do not have a track record of remaining open-source.

I did not expect W4 to get that much funding, but at it's current trajectory I could imagine it becoming a kind of publisher of Godot games. This is completely without any evidence, just my gut feeling.

I could also see them provide the kind of SaaS backend tools one needs to publish a game ( Network backend, payments, content delivery )

They just like the guy.

He’s now raised $23m publicly for the entity. Improbable said they raised $500m, I don’t know what reality was, but I’m sure it was similar.

It’s a lot of money for sure, I wonder what risky stuff they will spend it on. We have a lot of options for game development and we also had a lot of options for multiplayer engineering.

If you were a brilliant engineer, would you sign up for “port games to consoles?” I don’t know. So I’m sure there’s something really visionary behind the fundraising that hasn’t been said publicly.

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.

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

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?

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.

Unity was seen as a hobby engine then, we used it for the web, but for desktop used Unreal. Godot today is way ahead of where Unity was in 2007ish.

That allows developers to experiment a little bit (internally or with smaller projects) and hedge their bets.

If there is language compatibility (e.g. C# ) and your reusable components are somewhat sensibly designed (if only to mitigate update risks in your initial engine) it's feasible to think about switching for your next game (unless say in with service product that is expected to run indefinitely)

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.

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.

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

"just"?

Also large portion of first party Unity subsystems which you install through builtin package manger (I am not talking about third party asset store stuff) is available in source code form under relatively nonrestrictive Unity Companion License to anyone. Don't need the Enterprise plan or additional payments for that. For those modules you can not only read and modify the source code, but you can even openly distribute your modified versions. The biggest restriction of this license is that you can only use that source code in combination with Unity, you can't port it to different engines. And in many cases where I read it, to better understand how to correctly use the library or avoid a bug, it was quite readable.

So overall access to source code isn't the main obstacle for game developers to fix the problem in Unity, spending time fixing things and afterwards maintaining a modified version is.

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.

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.

It will be a while until we see AA / AAA games in Godot, it's missing too much right now to be viable in the 3D space (again, for AA/AAA. For indies, sure, why not). One day, certainly, I hope so, but not today nor tomorrow.

At the same time I find it hard to not feel cynical when I see that much money invested by a VC firm into an open source project.

I wish the best to the Godot team, so far they have a been pretty good at leading the project.

Great stuff.

[0]. https://youtu.be/nAh_Kx5Zh5Q

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

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 :)

Look at some of the games that made Unity popular in the first place, and the people/companies that made them. Lots of them are moving to Godot now, but again, it'll take time before those people/companies launch the games.

Godot is behind engine I don't even heard of.

Stuff that I've encountered so far:

- A very annoying issue where the editor will lock up after my Linux laptop wakes up from sleep. I've lost work because I've closed the laptop without remembering to close Godot first.

- Performance issues with large assets or too many assets. A single pixel art asset pack ([LimeZu's Modern Interiors](https://limezu.itch.io/moderninteriors)) brought Godot to its knees until I pruned it. The large tilemaps in there will also slow the tilemap editor to a crawl.

- I've been struggling with getting the dynamic tilemap rules to behave as expected. YMMV

- I'm not a fan of Godot's single-window UI approach, especially when it comes to scripting. You can futz with editor settings to make this slightly better, though.

- You can't mix 2d and 3d stuff like you can in Unity, and the 3d side of things is way rougher than 2d.

- They're still working out what direction to take with an Asset store.

- The shift from Unity's GameObject>Component model to Godot's single script per node approach has been an awkward adjustment for me. I keep replicating the old model by making prefab nodes that are basically just components.

- I miss Unity's play mode scene inspector. Godot is halfway there. You can poke around in the scene tree, but you don't see that update in the editor.

- The collision system isn't as straightforward as Unity

- It'd be nice if we had a bit of a slot system like we have with Vue Components for when we nest things under packed scenes.

The good stuff:

- There's only one type of signal/callback instead of the three different systems Unity can use. The signaling system is well-implemented instead of feeling bolted on.

- Godot doesn't differentiate between a Scene and a Prefab like Unity does. It avoids the don't destroy on load juggling you have to do and gives you a bit more control

- Some neat shortcuts for boilerplate stuff are built into the editor. For example, if you're adding SFX, you often want to provide several similar SFX clips to provide variety. When you set the SFX in the editor, you can assign a Randomizer to it, which takes a list of SFX and plays them randomly based on the weights and mode you set. You can even set pitch and volume adjustments to add even more variety.

- The fire-and-forget tween system is very convenient.

A lot of people compare Godot to Blender. It's not at the level that Blender is at now, but it does give me Blender pre-2.5 vibes- A solid base for enthusiasts that can be honed into polished software for the masses. I hope that Godot glows up the same way.

As relevant to Godot, most of my work is with kids (as relevant here on both ends -- teaching kids to code, and making educational activities). I haven't used either Godot or Unity much, and was trying to decide. For a variety of reasons, open-source is a huge win*, so I was leaning that way.

I don't expect much 3d or to be doing too many things which are overly fancy. Much more on the "weekend hack" or "kids afterschool activity" side of things, and much less on the serious game development side.

From your list, it doesn't sound like there are (m)any showstoppers to just picking Godot.

* (1) Avoids licensing issues installing / uninstalling on classrooms full of computers (2) Advanced kids can learn more, since they can look under the hood (3) Guaranteed long-term support (kids activities are sometimes not updated for a while) (4) Automatic FERPA / COPPA compliance and proper handling of student data. ...and the list goes on for quite a while longer.

If you know some basics, you can whip up a simple platformer, top down game, old-school top down shooter and such very, very quickly. A decent tutorial can have you at at something functional on the screen in half an hour or so. And then you can start playing around to make it cooler.

All while teaching kids some basics of programming.

I haven't used it much, but that was my first impression. It's good to see it confirmed.

I'm sure that as the GDExtension project develops, it'll only be a matter of time until someone builds a visual programming language for it.

Penpot/Figma story all over ... I hope not.

Blender

OpenToonz

GIMP

I hope all these major open source projects reach their potential. Blender is already basically there, and I'm expecting the rest to catch up eventually. Even GIMP -- it really just needs some TLC and actual funding and it could easily start on the notoriety/attention path Godot's been on for a few years now.

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.

If that was really what people wanted, wouldn’t there be a successful fork by now?

Unfortunately the reality is if people can barely pay attention and contribute to Gimp, what chance do any forks have?

Gimp moves slowly but they do listen to their users. Lack of funding is more responsible for any complaints people have with Gimp, not some assumed "anti-Photoshop" idealism.

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.

iOS IAP: https://github.com/godotengine/godot-ios-plugins

There were a bunch of people asking about it on Discord for Godot 4, and some confused reddit threads offering to pay people for a tutorial:

https://www.reddit.com/r/godot/comments/11vxeo7/can_i_please...

https://old.reddit.com/r/godot/comments/13ka6qc/will_pay_to_...

„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).”

The main question is it the "10x in 3 years" kind of business or the "steady stream of a small medim profit" variety.

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.

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.

Unity has very few advantages over Godot on mobile.

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