TLDR: Shipping a game with Godot is hitting all the expected rough patches around polish, tech milestones, and store compliance. The engine's great but the community's mostly hobbyist, so commercial requirements often mean rolling your own solutions. Also, please stop renaming functions in the engine - some of us are trying to ship games here.
I knew it was coming, I said as much in my Develop talk last year that the pain with Godot was always going to be felt around shipping and polish. Apoligies if I have been quiet this year. It was very much not my intention and another time I shall recount the last six months in more detail and why development has been hard. Part of it has been making a lot of mistakes and struggling to adapt to indie work patterns after years in larger studios.
After a cancelled project we decided to regroup and ship something very small. This was indeed the correct decision given the various hurdles which have come up but we are now weeks away from the Early Access launch of the title, though due to it's market fit nature I've been unable to talk about it until it is live on the store.
What is the rough patch?
Simply put getting that last bit of spit and polish on a video game project involves three areas
- Creative Polish, the feel and vibe of the project
- Hitting key technical milestones like framerate, package size ect...
- Store compliance: Console TRC, store api, legal compliance and lots of niggles
This is a pain generally not experienced by amateur or even semi professional indies often. That may seem like an inflammatory statement and in some respects they do experience the first of the three. Though ultimately the finacial pressure of paying bills and having investment compound the pressure significantly in way that is hard to understand by lightly dipping your toes in.
As for the store compliance and technical issues this is best summed up by a now infamous tweet where a indie developer complained that Steam blocked their title update because it crashed when a controller was unplugged and plugged back in. An automated check which was run on their submission no doubt and the reaction was almost perfectly split between professional gamedevs and not. On the gamer and hobbyist side their were offended at this heavy handed "censorship" and unreasonable standard. Who unplugs a controller mid game just restart the game and various other vitorial. While professional devs mostly jaded by Steam's loose quality control were mild impressed Steam was checking for this common compliance check which all consoles have had since controllers could be plugged in.
Additionally the technical milestones are often some of the hardest as a team tries to put that final gold master together, that final package for the big red button. It is a scary and often stressful times as marketing deadlines and schedule ad spends couple with a mess of proffessional calander entries bearing down on an often small programming team to find out why that character jumping really fast breaks a central check or why the build size is just over some arbitary threshold size previously committed to.
Godot is a fast progressing engine with more and more titles being worked on, though predomdiatly the community is non-professional leading to this imblance.
Unity and the PlayStation 4 Launch
This is not new, I recall this exact same issue happend when the PlayStation 4 was launching. A variety of indie developers had been lined up by Stragic Content and another initatives inside PlayStation to up the coolness of the platform off the back of work with the Vita. The old processes in some cases archaic and silly needed updating but on the other side a meaningful and important pushback for quality and core technical requirements held the line. Trying to find balance.
In this wave was a slew of Unity games. Unity was the new kid on the block with very few titles released on console, though it was in double digits by this point but on the previous generation. The issue was compounded by the fact Unity was in a massive growth phase, not disimiliar to what Godot is at the start of, but made worse by the fact it was closed source. Backroom deals and engineers rushed around but ultimatly many many indie games got screwed they missed their launch windows. Sometimes due to faults of their own, account managers but the lion shares of the blame could squarely be placed at Unity unproven engine tech.
This is why Unreal with it's closed source but build from source culture, many studios took almost a decade to upgrade to the new version from their special self cooked branches of UE3, did so much better. This is also why I feel more confident in Godot's open source approach. The issue with open source, middleware or using someone's lib is ultimately as a professional dev the buck stops with you and you have to bring all your dependcies up to the commercial standard your trying to achieve. This is the pain I am feeling with Godot at the moment.
So your just a better coder?
HOLY FUCK NO! There are much much smarter people than me and espcially in some areas. My knowledge of build systems is laughably poor to near incompetence. No we all have our blind spots. The issue is I'm building a thing. I've needed to make tech changes to achieve my goals. I will write a full post on replacing the Godot Label3d at some point. But also I needed bindings to commercial systems like leaderboards, store entitlements and commercial apis. I needed them in a way that could work across Steam, Meta Quest and PlayStation. These are not core problems to the Godot community. While some plugins exsist they tend to be single store focused and as someone who built her career on platform intergrations in some cases not up to the level I wanted.
Classic things like managing CPU affinity, respecting rate limits, pumping stuff on a thread, sleeping to avoid over stressing batteries ect... are all required elements. These stressors aren't felt by a hobby project. Even really skilled coders when they are working on something in their free time, for no pay, will often avoid the tricky problems or the ackward areas which make the project less fun. So often hobbyist libs are just missing these tricky edge cases.
Why the FUCK are you renaming shit
One big BIG difference between a mature commercial project and ameturs work is stability. Windows for all it's failing and weirdness is ROCK stable from an API point of view. Likewise Steamworks, PlayStation ect... when an API is exposed it stays still and does not move without significant pushback. This is why in Vulkan and other places you will have create_thing and create_thing2(...). So that the old one can be deprecated and people can be moved over to the new system.
While code reactoring, espcially with your fancy IDE rename tools feels quick and easy the pain is large. Recently I had to cherry pick some fixes from the main branch of Godot but I couldn't. At least not easily because some twit had renamed a bunch of function sigs! What is worse in pulling and merging the update script my build scripts all started failing because a core build command was renamed. What is worse the rename was called out in the PR as a minor ammendendment and no-one pushed back. It wasn't a junior but a senior Meta engineer and approved by key mantainers. Move fast and break my shit why don't you.
This has become a common issue with Godot mantainence. Too many people want to be involved and code janitor the code base, renaming things in a well intentioned drive to clean up and make the code base more understandable. A commendable process but it is piecemeal all over the shop, over changing function sigs or variable names for no strong reason. Making mantaining off branch variants much harder.
Any serious project will take a snapshot of all it's dependencies and keep updates to a minium to be stable. Every time an library, middleware or similiar is updated espcially on a larger team a large battery of expensive and slow tests often involving human time need to be performmed to confirm no unintended side effects. This well intentioned code janitor works makes pulling in critical patches signitificantly more time consuming and messy.
That is not to say renaming shouldn't be done but simply
- Old versions should be mantained and marked as deprecated
- Renaming due to changes in convention or similiar should be done code based wide and brought in as a single largescale change with clear approval and orcestration
- Any refactors should experience some pushback to check they are justified and not rubber stamped as "no behaviour change"
Going forward to release
Overall things are mostly looking up. I look forward to making more deep dive technical posts on the exact work undertaken and sharing more in the comming weeks. I want to keep a positive tone as I know this post can come across as a bit ranty. I'm immensely grateful to the Godot community and I hope to contribute back much of the work undertaken but as many release bits line up a large amount of work piles up.
I'm only able to write this post as I have some very long build times across multiple platforms and debug scons/cmake nightmare hell. So yes I hope to share more soon. I am still very fond of Godot but I knew this rough patch of release pain was coming and wanted to share these frustrations because I am the only dev in my various professional circles currently shipping on Godot. While I openly advocate for it, it is also important to highlight these issues. No koolaid to drink here.
If you have questions as always find me on the various socials. Bsky, Twitter and Mastodon to chat about all this or hit me up on the Godot RocketChat.