Yes you are right, its that simple.
I just made a Github Action wrapper around this 2 commands, that download and then caches the godot/butler files, so the next tun gets the files from the cache.
After a week of faffing I managed to fork the three repos Simon made and upgrade them from 3.x to 4.x . Very untested and maybe there's stuff there you don't need. But by gum it works! I'll slim it down in the future, and remove echo messages. Big thanks Simon for your work!
Cool to see that my work was useful for you!
Yeah, I have to update the default version to 4.x now, but you could have use the `godot-version` parameter to set it to 4.x like this
Did you test that with 4.x? Because when I did I got toooooonnnnnessss of errors. Godot changed path names on a lot of things - and there's no headless download binary, you have to use headless as a command option in the bash file settings.
Please take a look at my copy of your Godot export repo, if it helps :) took me a week to figure out the intricacies... a lot of path names changed, headless changed, the export command changed...
But then again it was my first ever GitHub action :D
I'd be interested to know what works for you, especially making sure the caching works optionally as that is out of my perview
Hey not bad. 3 years ago now (ugghh wow) I chose what engine to go all in on as a hobbyist. At the time only Unity supported producing web based games and I wanted to make games for the web so I went all in on Unity.
Unity is great. Unity is also horrible, especially on devx. It takes anywhere from 10-30 seconds to recompile code or changes on each save. Making a unity html game takes 5-30 minutes. There are things that can be done to reduce these times but requires knowing a bunch of info (usage of asset database, dividing code into assemblies, etc). Writing a container image to run Unity CLI commands requires you deal with license. Ugghh I wish Unity was just better to use.
I may scope out godot again. I’m working on a multiplayer game and it’d be interesting to evaluate how I’d plug a godot game into AWS gamelift.
Raster, all the assets are hi rez pngs. We play around with mipmaps and filtering algorithms to make the assets scale down nicely. Mostly just using large .pngs will get you all the way.
Pretty cool. I am on iPhone 14 and it plays really fluid in it, which surprised me. There is a small weird loading thing in the border right interacting with the ground, when scrolling either left or right.
I am impressed on how sharp the PNG looks though! I thought filtering in WebGL was like nearest neighbor and bilinear and that's it, perhaps there is additional things that can be accomplished with shaders that you are using.
The frame rate on an iPhone 13 Pro is pretty bad. Seems to average around 20 FPS. Granted, Safari sucks, but it’s not exactly a ringing endorsement of Godot given that your game appears to be 2D?
It's not optimized to run on mobile iPhone. Apple deliberately doesn't support open gl on the web. We previously disabled mobile iPhone from playing the game, and redirecting to the store.
I wouldn't lay this issue at Godots feet.
The difference between 2D and 3D in terms of performance demand is not significant.
We are running some serious shaders to render the terrain. They are pure SDFs that are absolutely massive mathematical functions that run on both the cpu and GPU. These shaders run better on android phones than on iOS phones, largely because apple does not iterate on webgl, because it undermines their app store to do so.
The menu is poorly optimized in terms of draw calls. The poor performance is largely our fault and apples fault. Godot could offer some tooling to make optimizing draw calls easier, but the way we built the menu is just not optimal for the GPU.
The biggest endorsement of Godot is the smallness of the download for our game. ~20mb iirc. It's not the smallest download in the world, but it's way smaller than a unity web game.
Mobile Safari was advertised to have gotten a WebGL upgrade (w 2.0 support) about 1.5 years[1] ago but has since been plagued by reports of performance problems. It seems to take a long time to mature there. Chrome shipped WebGL 2 in 2017, hopefully WebGPU case won't take 6+ years for Safari to catch up.
Can you elaborate on your system architecture for your game? It’s interesting that you’re deploying on k8s and implies a more complex app than a simple game client.
This is a multiplayer game with dedicated game servers, a matchmaker, agones to orchestrate those game servers, a client that runs on the web, a second client that runs on the web but doesnt use threads, an account system/api server, a database, a couple reverse proxies and some generic tooling like grafana and pyroscope.
We also deploy the client to steam for windows, mac and linux, the mac app store, google play, the ios app store, and we have custom web clients for some international portals.
I wish Godot allowed for smaller file sizes. The very lowest I've seen someone get a project down to is 10 MB. It's a little disappointing when your files work out to barely a few megabytes.
You can disable dome features of Godot by using a custom build of the engine. I did that for my F-Droid builds, since a F-Droid build recipe builds all dependencies from source. But I don't know how many MB I saved.
That's specific to the refactoring of godots internals in 4.0. specifically the performance will suffer in single threaded systems.
Note that we are running a multithreaded Godot 3 game on the web. It only uses threads when sharedarraybuffer is available, otherwise uses single threaded mode. Mostly just affects the latency of audio.
There are a lot of restrictions when using multiple threads in the browser. You need to spawn workers and they can only share certain things in memory between the threads (transferable objects and SharedArrayBuffer for generic data). For everything else you need to pass messages back and forth between the workers.
Another problem is that SharedArrayBuffer was disabled by default after Spectre and in order to enable it you need to send certain headers from the server (Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy). I don't know if itch.io has support for that, but maybe.
I haven't used Godot but I'm thinking that the multithreaded models game engines are using don't convert very well to SharedArrayBuffers. It's a very crippled form if you're used to say C#.
Itch does support the headers for SharedArrayBuffer, but it causes problems if you want to have both a web player and a downloadable version of the game. It was recently fixed for Chrome, but in Firefox trying to download a game from a page with SharedArrayBuffer results in the browser blocking the download from the CDN.