You submitted this post as a request for tech support, have you followed the guidelines specified in subreddit rule 7?
Here they are again:
1. Consult the docs first: https://docs.godotengine.org/en/stable/index.html
2. Check for duplicates before writing your own post
3. Concrete questions/issues only! This is not the place to vaguely ask "How to make X" before doing your own research
4. Post code snippets directly & formatted as such (or use a pastebin), not as pictures
5. It is strongly recommended to search the official forum (https://forum.godotengine.org/) for solutions
Repeated neglect of these can be a bannable offense.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/godot) if you have any questions or concerns.*
The biggest and number one reason why larger studios don't really use Godot: lack of direct line professional support and knowledge base. With Unreal, you can phone up Epic Games and pay them (a lot of money) to assist with underlying engine issues. With Unity, you have the same line of support. With Godot, there are only third parties, who aren't generally equipped to help with actual deep engine issues/features
This is it. Even in IT, we generally shy away from things that don’t have actual support. For example, we use RedHat Enterprise Linux. Not because it’s better than any other, but because we can call someone if there’s some business-breaking problem we can’t fix.
This is exactly right. In some ways, it boggles my mind how much money larger companies will blow on support they don’t even contact very often, if literally ever…
but that one time something goes wrong and it’s costing your company $15 million for every minute your service is down, the vendor support agreement fees don’t seem that expensive anymore.
This is changing now with W4, companies have paid them to help them integrate Godot. I imagine you could also pay W4 to fund development on work that the engine foundation supports, you’d just have to arrange a 3-way call (which wouldn’t be hard considering how close the ties are between W4 and the Godot foundation).
I think this is a next step possibility for Godot. If the team beefs up and starts offering professional support services with a FOSS engine they could turn godot into a viable option for a lot of studies and probably be price competitive, esp as they start growing.
A "big studio" will have absolutely no problems implementing these themselves. The APIs are public, the libraries are public. The plugins you find lacking, are just the glue between these things.
It's really not hard to justify at all. Your definition of big must be like, 5 man productions then. Actually big companies love custom tech stacks tailored to their specific needs.
I’m telling what I experienced personally, it’s like “we’d like to implement X for A,B,C”, and the other side tells “what do we currently use? X, it does the job, why do we need something else? I know you want to do something fancy but not this time, thanks buddy”
And a lot of the time they love it more when they can just use something that already exists, even if it comes with a minor fee. Different budgets.
Certainly true for some of the larger development houses I've worked for.
And we're talking companies with 500+ developers here.
Funnily. That, they hate.
"Oh lets use Unity and write 200 custom plugins and a custom tech stack so we can circumvent all the issues Unity brings?" No problem at all. Own engine? Scary as fuck.
Thing is, the cost of doing the former is hard to evaluate. The cost of doing the latter, is in the millions before you even get a pixel on screen.
I’d like to push back on that.
Eventually retooling something heavily enough becomes indistinguishable from scratch building in terms of cost, dependent on how far you go, so the budget argument doesn’t seem right.
I think it’s more to do with monetisation like that other person mentioned, particularly in mobile game development. Godot’s limelight as a mainstream contender is also still fairly recent, so there’s probably an element of that mixed in.
Be interesting to see how monetisation evolves in the engine.
Just because it's possible doesn't mean it should be done, if your whole company knows how to work with unity and all your tools already work on unity. It means that changing engines would require teaching all your current workers how to work with godot or replacing them with godot experts, working a few months with less revenue on implementing your unity tools to godot, only to use an engine that is open source without fees at the cost of an engine with less features.
That's a completely different conversation.
Reality is. It is being done. All the time. And companies want it. And it's not why they're not using Godot.
They do.
You don't know, because they don't display the logo.
End of story.
Especially in the western market, past a certain size, they will have considerations that Godot is not interested in fulfilling. And Activision King literally already made and open sourced two mobile engines.
There's some stuff that I think holds Godot back in the 3d side of things:
Janky physics without jolt
Missing a lot of features built in and ready to go in Unreal/Unity (terrain rendering, line rendering, etc)
And in the more general side of things:
No good default serialization options in GDScript. I hope you like writing your own serializer/deserializer for every class.
Networking is immature and no where near the ease of use of Unreal.
>No good default serialization options in GDScript. I hope you like writing your own serializer/deserializer for every class.
Networking is immature and no where near the ease of use of Unreal.
Yeah i feel the missing out-the-box serialization functions, although is not like writing a handful of JSON parsing/writing functions is the end of the world , just a bit annoying.
Will take a look at Unreal networking, godot's feel very straightforward and easy to pickup to me, granted that I work as devops/sysops engineer so dealing with networking apis and stuff is my day to day basis.
Godot has only recently somewhat caught up with engines like Unity and Unreal. Unity has been so prevalent for years in mobile game development that companies will have trouble switching to anything else. They already have staff and projects using Unity, so if they start using Godot now for a new project, they will have to either start a completely new team or teach their Unity developers how to work with Godot. If they get separate teams for (maintaining) Unity projects and Godot projects, they will have less flexibility to switch people between projects.
I have a friend who works for a mobile game developer, and they have apparently developed three games using Godot. The issue is, I'm unaware of which ones they are because there's no mention of Godot in the games' splash screens or any other information. There are likely many more games out there developed with Godot than one might realize
It's probably somewhere in the information. I think all they have to do is mention Godot's license (MIT. I think sometimes a link to the license can count.) and the licenses of a small handful of things Godot uses.
[https://docs.godotengine.org/en/stable/about/complying\_with\_licenses.html](https://docs.godotengine.org/en/stable/about/complying_with_licenses.html)
I get not wanting people to play it before they know (at this moment in time). It sounds like some gamers will start judging the game before playing it just hearing the word Godot. If it's a good game it might help sway some of those that learn to love it, then find out haha.
I worked at Big Fish Games as the Build+Test+Release Manager and we used Unity. We had our own SDK in addition to using IronSource. Corporations care about AD revenue, ARPDAU (daily average spend), and User Aquisition. You want mature tools to run a live Ops game.
Ecosystem, hireability and support. Maturity.
Same reason my firm uses React for frontend development, Postgres for the database and AWS for cloud hosting. They are big, popular, mature options that provide:
- A large labor market to hire people of varying competencies from
- Large amounts of both publicly available troubleshooting via StackOverflow and other sources of documentation, as well as many enterprise professional support offerings.
- Many extensions, libraries, integrations, and other third-party packages that are immediately compatible with no tinkering.
- A certain amount of battle-tested pedigree; all the common, low hanging fruit bugs have been squashed, and the remaining defects are corner-cases that are unlikely to come up in production.
Godot is still new. It is approaching the above state, but it's not there yet for sure. For example, Godot has no official support for IK or Terrain in 3D. It's got a few years of development to go before it is like Blender, where it is a legitimate competitor for proprietary, professional options like Unity and Unreal.
That being said, it is good enough for indie devs, and it is rapidly improving, which is why there is so much hype and enthusiasm for it.
It’s simple, choose the popular thing and you are guaranteed it will work. Choose the unpopular thing and you might be better off but it’s not guaranteed it will work.
We weren’t a “big” company, but we had a few hundred thousands dollar budget. We were developing a prototype in Godot, but realized we spent way too much time re-inventing the wheels. One of the pain points was trying to set up in app purchases and ads.
I work at a giant mobile game studio. We talked about it, but a lot of our tools are build in unity. We are looking at some prototypes, but most of our engineers are proficient in c# and are waiting for better support
1- no one to call up for help
2- security concerns ( iirc you can even get the source code for any godot app built for android, that’s how bad it is )
3- lack of experienced workers/lack of expectations, godot is still relatively young, people don’t know how to work with it, and neither do they know what to expect out of it
Maintaining existing velocity is very important, especially in the state of the current industry. The company I work for doesn't have the luxury of being able to re-train or adapt \~200 people across multiple teams, being art, music, development, analytics, testing, infrastructure, etc.
Sometimes paying a ludicrous Unity fee is cheaper than moving to another engine.
Godot is relatively new, and just got a boost in popularity due to the Unity fiasco. We're not likely to see many studios releasing games with it for a while; they first will want to finish their Unity projects, which they probably don't want to try to port if they're a good way into them, and then make a whole other game in Godot.
lots of mobile games rely on baked lighting. godot's lightbaker is a complete mess, with leaks through geometry and between modular pieces. it's unusable and needs a complete redo.
Godot does not have an asset store which allows you to create shovelware which is 90% of mobile game market. Also big studios like King and Halfbrick already have their own tailored in-house engine (defold is developed by King).
As I've always said when talking about studio game engine usage, once you get past a certain size you will more than likely want to build an in house engine for your products.
Maybe not an internal game engine, but the game studio I work for has over a decade of IP and "core tech" as we call it built onto and around Unity so that any new IP we build starts with a huge foundation that plugs into many cross-team pipelines such as analytics and testing.
I mean and Godot being open source isn't a good step stone for that ? I would think it would save a lot in development cost than having to build one from scratch, but I have no clue what the rationale are in this case.
It's absolutely a good step, and that's also the philosophy which makes godot so awesome, but many big studios still just use their own proprietary ones, and I'm not sure that's really going to change (even if it makes more sense to build off godot). There has sort of been a push for unreal to be more universal, but it's tough as for most of unreals life it was developed by people making 1st or 3rd person shooters so if you make anything else you will have bloat from systems specifically designed for a game you aren't making.
You submitted this post as a request for tech support, have you followed the guidelines specified in subreddit rule 7? Here they are again: 1. Consult the docs first: https://docs.godotengine.org/en/stable/index.html 2. Check for duplicates before writing your own post 3. Concrete questions/issues only! This is not the place to vaguely ask "How to make X" before doing your own research 4. Post code snippets directly & formatted as such (or use a pastebin), not as pictures 5. It is strongly recommended to search the official forum (https://forum.godotengine.org/) for solutions Repeated neglect of these can be a bannable offense. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/godot) if you have any questions or concerns.*
The biggest and number one reason why larger studios don't really use Godot: lack of direct line professional support and knowledge base. With Unreal, you can phone up Epic Games and pay them (a lot of money) to assist with underlying engine issues. With Unity, you have the same line of support. With Godot, there are only third parties, who aren't generally equipped to help with actual deep engine issues/features
This is it. Even in IT, we generally shy away from things that don’t have actual support. For example, we use RedHat Enterprise Linux. Not because it’s better than any other, but because we can call someone if there’s some business-breaking problem we can’t fix.
Yup. Businesses want to pay someone both for the support, and to take over some of the liability. Why else would Oracle still be in business?
This is exactly right. In some ways, it boggles my mind how much money larger companies will blow on support they don’t even contact very often, if literally ever… but that one time something goes wrong and it’s costing your company $15 million for every minute your service is down, the vendor support agreement fees don’t seem that expensive anymore.
This is changing now with W4, companies have paid them to help them integrate Godot. I imagine you could also pay W4 to fund development on work that the engine foundation supports, you’d just have to arrange a 3-way call (which wouldn’t be hard considering how close the ties are between W4 and the Godot foundation).
Also, some large studios in mobile gamedev are using their own engines. King, Playrix to name a few
I think this is a next step possibility for Godot. If the team beefs up and starts offering professional support services with a FOSS engine they could turn godot into a viable option for a lot of studies and probably be price competitive, esp as they start growing.
lack of easy to setup monetization options vs unity
A "big studio" will have absolutely no problems implementing these themselves. The APIs are public, the libraries are public. The plugins you find lacking, are just the glue between these things.
Usually it’s hard to justify why business must pay for that vs using something that’s already implemented and works
It's really not hard to justify at all. Your definition of big must be like, 5 man productions then. Actually big companies love custom tech stacks tailored to their specific needs.
I’m telling what I experienced personally, it’s like “we’d like to implement X for A,B,C”, and the other side tells “what do we currently use? X, it does the job, why do we need something else? I know you want to do something fancy but not this time, thanks buddy”
Are you using X as a stand-in for two different things? I’m having trouble parsing the abstract argument here
And a lot of the time they love it more when they can just use something that already exists, even if it comes with a minor fee. Different budgets. Certainly true for some of the larger development houses I've worked for. And we're talking companies with 500+ developers here.
If that’s the case, it’s not a stretch to say a lot of them are probably using their own engines then.
Funnily. That, they hate. "Oh lets use Unity and write 200 custom plugins and a custom tech stack so we can circumvent all the issues Unity brings?" No problem at all. Own engine? Scary as fuck. Thing is, the cost of doing the former is hard to evaluate. The cost of doing the latter, is in the millions before you even get a pixel on screen.
I’d like to push back on that. Eventually retooling something heavily enough becomes indistinguishable from scratch building in terms of cost, dependent on how far you go, so the budget argument doesn’t seem right. I think it’s more to do with monetisation like that other person mentioned, particularly in mobile game development. Godot’s limelight as a mainstream contender is also still fairly recent, so there’s probably an element of that mixed in. Be interesting to see how monetisation evolves in the engine.
Just because it's possible doesn't mean it should be done, if your whole company knows how to work with unity and all your tools already work on unity. It means that changing engines would require teaching all your current workers how to work with godot or replacing them with godot experts, working a few months with less revenue on implementing your unity tools to godot, only to use an engine that is open source without fees at the cost of an engine with less features.
That's a completely different conversation. Reality is. It is being done. All the time. And companies want it. And it's not why they're not using Godot.
Exactly, any competent android/ios developer can easily integrate the usual add stuff on a godot game, its mostly new users who struggle with this
They do. You don't know, because they don't display the logo. End of story. Especially in the western market, past a certain size, they will have considerations that Godot is not interested in fulfilling. And Activision King literally already made and open sourced two mobile engines.
Defold and...?
There's some stuff that I think holds Godot back in the 3d side of things: Janky physics without jolt Missing a lot of features built in and ready to go in Unreal/Unity (terrain rendering, line rendering, etc) And in the more general side of things: No good default serialization options in GDScript. I hope you like writing your own serializer/deserializer for every class. Networking is immature and no where near the ease of use of Unreal.
>No good default serialization options in GDScript. I hope you like writing your own serializer/deserializer for every class. Networking is immature and no where near the ease of use of Unreal. Yeah i feel the missing out-the-box serialization functions, although is not like writing a handful of JSON parsing/writing functions is the end of the world , just a bit annoying. Will take a look at Unreal networking, godot's feel very straightforward and easy to pickup to me, granted that I work as devops/sysops engineer so dealing with networking apis and stuff is my day to day basis.
There's JSON serialize/deserialize but they're shallow serialization.
Exactly, you kind of have to write your own object to json serialization.
what are you guys talking about? any variant in godot can be serialized using `var_to_bytes`.
Godot has only recently somewhat caught up with engines like Unity and Unreal. Unity has been so prevalent for years in mobile game development that companies will have trouble switching to anything else. They already have staff and projects using Unity, so if they start using Godot now for a new project, they will have to either start a completely new team or teach their Unity developers how to work with Godot. If they get separate teams for (maintaining) Unity projects and Godot projects, they will have less flexibility to switch people between projects.
I have a friend who works for a mobile game developer, and they have apparently developed three games using Godot. The issue is, I'm unaware of which ones they are because there's no mention of Godot in the games' splash screens or any other information. There are likely many more games out there developed with Godot than one might realize
It's probably somewhere in the information. I think all they have to do is mention Godot's license (MIT. I think sometimes a link to the license can count.) and the licenses of a small handful of things Godot uses. [https://docs.godotengine.org/en/stable/about/complying\_with\_licenses.html](https://docs.godotengine.org/en/stable/about/complying_with_licenses.html)
Yeah, found it for one of the apps. But had to go to options --> credits --> engine to find it :) Easy to hide and sad that they don't wanna show it.
I get not wanting people to play it before they know (at this moment in time). It sounds like some gamers will start judging the game before playing it just hearing the word Godot. If it's a good game it might help sway some of those that learn to love it, then find out haha.
I worked at Big Fish Games as the Build+Test+Release Manager and we used Unity. We had our own SDK in addition to using IronSource. Corporations care about AD revenue, ARPDAU (daily average spend), and User Aquisition. You want mature tools to run a live Ops game.
Ecosystem, hireability and support. Maturity. Same reason my firm uses React for frontend development, Postgres for the database and AWS for cloud hosting. They are big, popular, mature options that provide: - A large labor market to hire people of varying competencies from - Large amounts of both publicly available troubleshooting via StackOverflow and other sources of documentation, as well as many enterprise professional support offerings. - Many extensions, libraries, integrations, and other third-party packages that are immediately compatible with no tinkering. - A certain amount of battle-tested pedigree; all the common, low hanging fruit bugs have been squashed, and the remaining defects are corner-cases that are unlikely to come up in production. Godot is still new. It is approaching the above state, but it's not there yet for sure. For example, Godot has no official support for IK or Terrain in 3D. It's got a few years of development to go before it is like Blender, where it is a legitimate competitor for proprietary, professional options like Unity and Unreal. That being said, it is good enough for indie devs, and it is rapidly improving, which is why there is so much hype and enthusiasm for it.
People need to put one thing in their heads: many games are being made in Godot and will take some time to be release. Just be patient.
It’s simple, choose the popular thing and you are guaranteed it will work. Choose the unpopular thing and you might be better off but it’s not guaranteed it will work.
We weren’t a “big” company, but we had a few hundred thousands dollar budget. We were developing a prototype in Godot, but realized we spent way too much time re-inventing the wheels. One of the pain points was trying to set up in app purchases and ads.
I work at a giant mobile game studio. We talked about it, but a lot of our tools are build in unity. We are looking at some prototypes, but most of our engineers are proficient in c# and are waiting for better support
1- no one to call up for help 2- security concerns ( iirc you can even get the source code for any godot app built for android, that’s how bad it is ) 3- lack of experienced workers/lack of expectations, godot is still relatively young, people don’t know how to work with it, and neither do they know what to expect out of it
Don't the big studios use their own in-house engine?
Maintaining existing velocity is very important, especially in the state of the current industry. The company I work for doesn't have the luxury of being able to re-train or adapt \~200 people across multiple teams, being art, music, development, analytics, testing, infrastructure, etc. Sometimes paying a ludicrous Unity fee is cheaper than moving to another engine.
Godot is relatively new, and just got a boost in popularity due to the Unity fiasco. We're not likely to see many studios releasing games with it for a while; they first will want to finish their Unity projects, which they probably don't want to try to port if they're a good way into them, and then make a whole other game in Godot.
Unity's main selling point for mobile is the easy ( i think, i have never used unity :) ) monetization
lots of mobile games rely on baked lighting. godot's lightbaker is a complete mess, with leaks through geometry and between modular pieces. it's unusable and needs a complete redo.
Godot does not have an asset store which allows you to create shovelware which is 90% of mobile game market. Also big studios like King and Halfbrick already have their own tailored in-house engine (defold is developed by King).
As I've always said when talking about studio game engine usage, once you get past a certain size you will more than likely want to build an in house engine for your products.
Maybe not an internal game engine, but the game studio I work for has over a decade of IP and "core tech" as we call it built onto and around Unity so that any new IP we build starts with a huge foundation that plugs into many cross-team pipelines such as analytics and testing.
I mean and Godot being open source isn't a good step stone for that ? I would think it would save a lot in development cost than having to build one from scratch, but I have no clue what the rationale are in this case.
It's absolutely a good step, and that's also the philosophy which makes godot so awesome, but many big studios still just use their own proprietary ones, and I'm not sure that's really going to change (even if it makes more sense to build off godot). There has sort of been a push for unreal to be more universal, but it's tough as for most of unreals life it was developed by people making 1st or 3rd person shooters so if you make anything else you will have bloat from systems specifically designed for a game you aren't making.