5 ms·

Why? For most games (especially a "2d hide and seek") you drop a zip file and press a single button on your dev console to publish.

usrusr 1y ago
And that zip file might be not the version you thought it was, if it's not from a build server it might include any number of uncommitted or gitignored changes, more transfer steps mean more things that can go wrong. These automations are not about reducing keypresses, they are about reducing the number of trivialities to mess up. People tend to have other things on their mind when going through that kind of routine.
diggan 1y ago
> For most games (especially a "2d hide and seek") you drop a zip file and press a single button on your dev console to publish If you read through the actual pipeline, you'll see it's not just "drop a zip file and press a single button". Firstly, you're missing everything that goes before even having a ZIP file, making that process reproducible is valuable regardless of what you do later. Secondly, doing this for three platforms would mean repeating the same thing three times, in slightly different ways. Automating it just makes sense at that point. Overall, building and publishing a game via automation just brings about every benefit from CI/CD, just to a "game development" context instead, so you'd do it for the same reason you'd automate any software release process.
simonw 1y ago
If you automate your release process: 1. You won't forget how to ship a release if you go months between releases 2. You won't make mistakes when you release code - forgetting a crucial step along the way for example 3. Related: you can add tests to your release process - so your release doesn't go out if you made some last-minute mistake that broke the build 4. You'll release more often: the automation has de-risked your release process and reduced friction around it, which means you can ship with more confidence and less ceremony 5. You can reliably share that release process with other collaborators - not end up in a situation where only one person's laptop is able to ship 6. If your laptop breaks or gets stolen it won't harm your ability to release software All of the above are true for non-game projects, I don't see why they shouldn't apply to games as well.
DonHopkins 1y ago
I recently heard some salty chap here on HN use the term "ClickOps" as opposed to "DevOps" or "GitOps" to describe the "just click on the button in the dev console web page to do that" approach. https://www.wiechtig.com/blog/clickops-is-the-worst/ https://www.wiechtig.com/blog/clickops-is-the-worst/ https://www.lastweekinaws.com/blog/clickops/ https://www.lastweekinaws.com/blog/clickops/ https://blog.equinix.com/blog/2022/12/01/what-is-clickops-and-how-can-you-prevent-it/ https://blog.equinix.com/blog/2022/12/01/what-is-clickops-an...

usrusr 1y ago

And that zip file might be not the version you thought it was, if it's not from a build server it might include any number of uncommitted or gitignored changes, more transfer steps mean more things that can go wrong. These automations are not about reducing keypresses, they are about reducing the number of trivialities to mess up. People tend to have other things on their mind when going through that kind of routine.

diggan 1y ago

> For most games (especially a "2d hide and seek") you drop a zip file and press a single button on your dev console to publish If you read through the actual pipeline, you'll see it's not just "drop a zip file and press a single button". Firstly, you're missing everything that goes before even having a ZIP file, making that process reproducible is valuable regardless of what you do later. Secondly, doing this for three platforms would mean repeating the same thing three times, in slightly different ways. Automating it just makes sense at that point. Overall, building and publishing a game via automation just brings about every benefit from CI/CD, just to a "game development" context instead, so you'd do it for the same reason you'd automate any software release process.

simonw 1y ago

If you automate your release process: 1. You won't forget how to ship a release if you go months between releases 2. You won't make mistakes when you release code - forgetting a crucial step along the way for example 3. Related: you can add tests to your release process - so your release doesn't go out if you made some last-minute mistake that broke the build 4. You'll release more often: the automation has de-risked your release process and reduced friction around it, which means you can ship with more confidence and less ceremony 5. You can reliably share that release process with other collaborators - not end up in a situation where only one person's laptop is able to ship 6. If your laptop breaks or gets stolen it won't harm your ability to release software All of the above are true for non-game projects, I don't see why they shouldn't apply to games as well.

DonHopkins 1y ago

I recently heard some salty chap here on HN use the term "ClickOps" as opposed to "DevOps" or "GitOps" to describe the "just click on the button in the dev console web page to do that" approach. https://www.wiechtig.com/blog/clickops-is-the-worst/ https://www.wiechtig.com/blog/clickops-is-the-worst/ https://www.lastweekinaws.com/blog/clickops/ https://www.lastweekinaws.com/blog/clickops/ https://blog.equinix.com/blog/2022/12/01/what-is-clickops-and-how-can-you-prevent-it/ https://blog.equinix.com/blog/2022/12/01/what-is-clickops-an...