I don't know anything about game engines, but always assumed that Godot was limited to simpler games. A lot of people seem to be pushing for Godot to replace Unity after the recent licensing shambles.
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?
1. Congratulations to them. Godot is some great piece of open source software and everything that strengthens it is beneficial to the market segment as a whole.
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.
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.
Thank you for pointing that out. That seems like it could be a profitable idea.
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 don't have any up to date information on the path W4 will go, but Juan and Remi have always been very clear that they have no plans to change anything in how Godot is licensed nor would they be able to.
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 )
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.
I missed that. I'm glad if Godot remains independent. VC funded OSS projects do not have a track record of remaining open-source.
That would be putting the cart before the horse, no games yet worth porting, so obviously so, it couldn’t be the reason for the investment.
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.
Chicken and egg problem, no games worth porting because games look at the engine and are like "oh you can't do console? i'm out". Part of making godot an industry standard is first making sure it has industry standard capabilities.
They are affiliated in as far as one of the original Godot authors is the one of the founders of W4 (Juan Linietsky). However, I think it would help avoid misunderstandings if W4 communicated clearly how much they are dedicating to open source development and how much is closed source stuff only related to Godot.
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.
Yeah that's true.
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)
It's a decent consulting business, but where's the moat? I don't see the case for VC money. This seems more appropriate for a bank loan or something.
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.
"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.
Is this some VC's pouncing on Unity's missteps? How serious was the damage to Unity's credibility after the installation fee disaster? How big is the moat for unity?
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).”
Getting game engines in console and providing support for developers is certainly a business. I've met some people who brought their custom (more simple ) engines/games to consoles and there is money in providing a ready made solution which, by the nature of it, cannot be open source or permissive.
The main question is it the "10x in 3 years" kind of business or the "steady stream of a small medim profit" variety.
It's not EEE because W4 Games actually founded by some of top Godot contributors who continue to work on FOSS version as well. There just some things you can't have open source like console platform support code.
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.
Google Play IAP: https://github.com/godotengine/godot-google-play-billing
The iOS one is unmaintained and has been for a while (it still doesn't officially support Godot 4.x). Supposedly it should be maintained again by EOY but we've yet to see any progress on it.
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.
The moat is massive for console games, mobile games on Godot work great. We have 2 high quality Godot based mobile games in production on iOS/google play/steam right now.
Unity has very few advantages over Godot on mobile.
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.
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.
Godot is great. I am afraid it's still a very long way before they become for game development what Blender is for 3D modelling these days. If it will even happen at all. So any improvement and funding is more than welcome.
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 :)
Godot has not eaten anything significant from Unity, like nothing at all.
Yes, it has. But game engine adoption takes time, it's not immediately clear that it is eating some of Unity's lunch, as games have to be developed, launched and appreciated before it's obvious for the average (developer) person.
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.
Serious / non-leading / non-rhetorical question: What are the gaps?
From the perspective of a hobby unity dev who's making a jam game in Godot to feel it out, Godot has a lot of rough edges, weird choices, and stuff that's just missing.
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.
Thank you!
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.
I find the title rather confusing, as, after reading their FAQ (https://w4games.com/faq/) it is clear that they don't own Godot. They are building a traditional BaaS for gaming, specifically targeted at Godot developers (and they may contribute to Godot development, which doesn't make a real difference rearding ownership).
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).
Thank you for the precision. I guess the important part is how Godot is currently organized and remains independent.
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.
Godot is awesome, but I wish that when people start ambitious new projects that are meant to last for decades they’d choose a language that has more modern conveniences than C++. The compile times suck. The language is such a complicated mess you have to basically ban whole parts of the language from being used in the project to make development palatable. I would even prefer C to C++. I know Rust is probably a hard sell though.
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++
Godot
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.
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.
giving people what they want: a Photoshop clone
If that was really what people wanted, wouldn’t there be a successful fork by now?
I hope for Godot to remain true to itself over time. Unity was the indie upstart at one point, just like Godot is now.
Penpot/Figma story all over ... I hope not.
Unity was never FOSS. Nor was Figma, to my knowledge
Great, now Godot has a time bomb as well.
"Investors"
I'm not affiliated with the channel and they probably don't even know I'm posting here but this[0] is a great entry point into Godot Engine although I think the instruction style leads for it to be more general and applicable to other engines or what a game engine actually facilitates.
Great stuff.
Congratulations to the Godot team! I have used Godot a lot in the past and can't wait to replace my Unity junk.
Hoping for Godot to be the Blender of game development engines one day.
Congratulations, that’s a pretty impressive feat. It’s fantastic to see how fast things are developing. I may be wrong but the current momentum to develop viable alternatives to the big proprietary engines feels real and not just based on hype. We may reach a point in a few years where Blender + Godot are basically the go-to option for small to medium size studio, which is crazy to think about given the state of game dev just 10-15 years ago.
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 to see more support for Godot! The lead VC and the company pledges bode well for keeping the bulk of the new tech open I think.
Biggest red flag is the lack of anyone with games pedigree. If the goal is to crack the duopoly with a great FOSS engine supported by paid BaaS + enterprise support plans, you’re going to need strong connections, partners, and knowledge of the real product requirements. First sales will be pretty challenging, but if they can get traction and ship great games there’s certainly an opportunity
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
"just"?
Well, I mean source code is easier to read that Unreal. And Unity does not even provide source code, so you have to wait until they fix the issue for you. In addition, the Godot community is really helpful, if you provide an example project with your problem.
Unity sells source code access, it's in the "contact us for quote" category. But that's how many B2B services work, including some of the most widely used commercial game middleware.
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 personally had issues where I wanted to read the Unity source code but couldn't. And I suspect it wouldn't have been worth the cost in my case. There's really no substitute for shared source. Truly open source isn't necessarily better; modifying it is not often realistic, but having to pay just to read it is a big stumbling block.
Oh yeah, haven't you heard? All open source software is intrinsically flawless because you can just fork it.
I think patching a game engine is fairly common in the industry. Games are not on a dependency update treadmill. They pick a version, and barring some external crisis, there is no reason to upgrade anything ever. If there is one bug affecting rendering or speed from the underlying engine, it can be worth finding it yourself.
Much easier than waiting for a suitable job opening at Unity, getting a job at Unity, and then just cloning Unity and fixing things yourself.
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.
I wonder whether that is because most games are projects with a clear endpoint after which development mostly stops.
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)
The counterpoint to this is many studios are sequel factories, or producing games that are at least broadly in the same genre continuously, and each game starts as a fork of the last, which is how you end up with things like the COD engine or Source 2 having a direct lineage to engines from 90s quake games. So "Assassins Creed: Odyssey" may not be an ongoing service, but "Assassins Creed" is, and tech carries forward from one to the next.
Exactly. I used Unity starting from almost the first release, and attended Unite in 2007.
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.
From a cursory search it seems there are large games build in Godot. Sonic Colors: Ultimate seems to be an example.
It's the only example so far (if we consider this poor remake a "large" game). And the team behind (Blind Squirrel) didn't use Godot as-is, they had to rewrite most of the core graphics area.
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.
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.
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:
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.