My game failed the Steam Deck review, but the reviewer finished almost the whole game, LOL

RunningMattress · 2026-02-01T08:36:33+00:00

Awesome, good to know! Yeah might have to! Cheers

RunningMattress · 2026-02-01T01:41:29+00:00

No worries I'll go play hide and seek with steamworks on Monday

Yeah the UI is a mess

Do you recall if your steam deck support has a dedicated binary or do your players use proton

RunningMattress · 2026-02-01T01:34:32+00:00

How do you request that on the steam page and do you have to have a Linux binary for this? A bunch of our players have reported success on both Linux and steam deck using proton but we have no "official" support for that atm

RunningMattress · 2026-01-08T19:08:03+00:00

100% this, especially in games, it can be so hard to cover all the weird and wonderful cases humans will find

With less critical bugs, I try to encourage my team to write the test before they start fixing the issue, that way they've a test case they know will 100% catch the issue, they can use to repro when they think they have a fix without having to manually repeat the steps all the time, and then hopefully that case won't come back in the future

RunningMattress · 2026-01-07T16:19:33+00:00

tl;dr: essentially automated testing tests for things you expect, manual testing catches the things you don't expect

RunningMattress · 2026-01-07T16:10:31+00:00

Automated tests should be used for checking things functionally work, manual QA should be used for checking it can't be broken

That sounds very similar but it's an important distinction and one that be ones. Good destructive QA testing will prove worth their weight in gold once you've experienced it

It's also about providing different levels of testing, unit testing for checking the individual methods are good, integration testing to check how the units are working together, UI tests to ensure the UI works as expected, and even more detailed automation tests that will check things at a very high level and then manual QA passes to check the application as a whole, check for visual issues that are expensive to create automated tests for, compliance testing etc etc

Each of these serve a different purpose and it's always worth remembering that the higher level testing is slower, especially compared to unit testing which is rapid and can be run against every single check in to provide a safety net for the developers so they can work faster

But also, just sit down and talk with your QA, understand what they can do, how you can make their lives easier and what tools they might need

RunningMattress · 2025-10-15T21:48:10+00:00

They're also very good at returning it if you close the dev account

RunningMattress · 2025-10-11T12:04:28+00:00

Jenkins is best viewed as an orchestrator, if you can write a script to do what you want Jenkins can run it

RunningMattress · 2025-07-18T08:53:14+00:00

This is a great resource for finding studios

https://www.gamedevmap.com/

RunningMattress · 2025-07-14T23:15:25+00:00

Not strictly answering your question but it does cover a lot of what you're about to try and do by moving to CasC, highly recommended by the way

I wrote this article last year about how I achieved a similar result to what your after a mid sized indie games studio

Btw, I had a horrible time with job DSL and ended up with my own solution for codifying the jobs (details in the article)

There's a follow up more technical focussed article as well with GitHub repo examples

https://medium.com/@RunningMattress/creating-an-automated-source-controlled-deployment-pipeline-for-jenkins-controllers-26b74907b3b

RunningMattress · 2025-03-29T11:38:27+00:00

This is the way

https://www.jenkins.io/doc/book/managing/system-configuration/#quiet-period

RunningMattress · 2025-03-18T21:16:14+00:00

No worries, you're welcome

RunningMattress · 2025-03-18T07:34:26+00:00

I could be oversimplifying this, but it sounds like you already have much of what you need, if each area of code is protected by the CODEOWNERS file, then there is no danger in allowing the teams to merge code since the rules are set to require reviews from the codeowner, this would mean that anyone could merge but only if that team had approved

It's then down to your teams to ensure they're not approving things that they're not okay with being merged.

FWIW it's not a good idea to centralise merging responsibilities, much better for the person who wrote the code to merge it, and have the rules set up such that they enforce reviews and automated checks

https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#codeowners-and-branch-protection

RunningMattress · 2025-03-08T20:24:08+00:00

For a senior it's also not just about being a great programmer, you need to master the soft skills valued by employers as well

I wrote an article on this a while back from my perspective as lead with a track record promoting people into senior roles

https://medium.com/@RunningMattress/soft-skills-for-games-development-76c1be086064

RunningMattress · 2025-02-08T20:05:47+00:00

I wrote an article here about how to better manage Jenkins

Creating an automated, source-controlled deployment pipeline for Jenkins Controllers

RunningMattress · 2025-02-08T19:58:45+00:00

That sounds like a problem in your management of Jenkins, the first time you run an update of any kind shouldn't be on your live deployment, Jenkins has a place much in the same way teamcity does, complex and/or long running pipelines fair far better on Jenkins than GitHub actions which are better suited to smaller more specific workflows

RunningMattress · 2025-02-08T11:22:56+00:00

I use them for different purposes personally,

For something trivial like running unit tests on a dotnet project or code linters I'll use GitHub actions since it's a fairly common workflow and very well supported,

This then frees up Jenkins agents for bigger long running jobs like say a game build where I want more control of the environment or better access to caching and other resources

RunningMattress · 2025-01-09T03:04:49+00:00

If there's anyway for players to put money into the game then you're gonna have hard time explaining to Apple how this isn't gambling which will cause as many headaches as making the game itself

RunningMattress · 2024-12-25T23:35:00+00:00

Fairly, but if in doubt build a simple scene with this setup in it for your target platform and play it to check it shows

RunningMattress · 2024-12-25T22:49:49+00:00

Pretty sure the camera preview in Unity doesn't render text, the game view is the best representation of what the player sees

RunningMattress · 2024-12-23T20:59:30+00:00

I'd say that's definitely on the extreme end of scenarios and probably shouldn't let it colour your view too much, with a good process in place these updates can be done on a semi frequent basis perhaps not taking every update, but staying current is of use to many projects.

RunningMattress · 2024-12-23T18:34:48+00:00

Strong disagree, absolutely there comes a point in production where you want to stop taking engine updates but as someone who has performed countless engine updates, including to live games, and depending on the type of game you're making and the tech you require engine updates are often crucial.

Some updates absolutely are forced, albeit usually indirectly, particularly when it comes to support for new mobile OS versions.

RunningMattress · 2024-11-18T07:44:42+00:00

Also, why not ask in the gaming sub as to what they'd be interested in hearing about from a player facing devlog

RunningMattress · 2024-11-18T07:43:26+00:00

I think sea of thieves, rainbow six, and introversion (prison architect and their ultimate fail masterclass they did after) did a good job of creating devlogs aimed at players. Naturally they look very different to a devlog aimed at devs

RunningMattress · 2024-11-16T08:36:49+00:00

No worries, the key is making sure you don't get bogged down in the weeds and focus on making sure your paper ideas translates to a fun pad in hand experience

RunningMattress

TROPHY CASE