soulsource

As dumb as this sounds: Playing Ring Fit Adventure on the Nintendo Switch.

I play a custom training routine (or however that's called in the English version of the game) four days a week that has active time of 17 minutes, and another custom routine that takes about 27 minutes active time plus at least two levels in adventure mode on the other 3 days of the week (what brings the active time on those days up to something around 40 minutes).

The 27 minutes routine is mostly for stamina, so it has relatively light exercises. The other routine is much more demanding, and meant to get my heart rate up and my muscles burning (I won't go into details, that would be bragging...).

I have lost about 10 kg by doing this, and by no longer eating after 8pm.

However, this weight loss happened in the first couple of months after I started this. My weight has now been constant again for about a year.

What is stopping you from playing Minecraft itself on Linux?

I haven't played it in a while, but it did work perfectly fine last time I tried it. It is written in Java, after all.

This is so fucking stupid, I can't even.

For your mental health, have some reasonable arguments about Rust: https://www.heise.de/hintergrund/Entwicklung-Warum-Rust-die-Antwort-auf-miese-Software-und-Programmierfehler-ist-4879795.html

Since it's in German, here are the key points of the article (written from memory - the article is quite old, so I might misremember - best read the article yourself):

• Software development is stuck in a vicious cycle regarding project budgets.
  • Some competitors don't know better and just budget the "happy path", that assumes that everything during development goes right.
    • The author uses a term for this which I like a lot: "Hybris of the programmer"
  • Other competitors know better, but still have to lie in order to remain competitive when it comes to prices
  • Therefore almost all software projects end up with a way too low budget
    • So we get buggy software
• Rust might be a way out of this misery, because
  • it is understood that it takes longer to develop something with Rust
  • but on the flip-side the safety-guarantees rule out a lot of bugs
  • so customers who choose to have their project implemented using Rust are fully aware of the higher costs, but also the higher quality
  • and developers have a well known argument for the higher costs, and also have data that shows how this higher investment will yield a better quality product.

While I am not aware of any way to run custom software on the Steam Deck while it is on standby, you can drastically reduce the power drain if you shut it down fully instead of leaving it on standby. You can either use the "Power" menu after pressing the steam key, or long-press the power button to get the option to do so.

I would not say "lazy".

There are a lot of bold promises in Unreal Engine 5 advertisements, that get taken up by publishers and producers - and then end up in the game budgets...

And then, near the end of the project, when it turns out that performance isn't good because the advertisement promises have been a bit too bold, there is no money for optimization left...

Also, if I am allowed to do some absolutely shameless self promotion: Bus Simulator 21 is verified, and 18 is playable.

I need to give two perspectives here. One from my day-job as a gamedev, and one from my hobby as a gamedev.

The main difference is that in my spare time I do not have to suffer working on Windows.

So, first about work: I have switched from an nVidia card to an AMD one in 2022, because my work PC's nVidia card had too little VRAM to run the editor of Unreal Engine 5. Editor performance was abysmal (due to the nVidia card's limited VRAM) and running out of VRAM also frequently caused the editor to crash.

After I switched to an AMD card, those crashes were gone and performance of the editor was way better too (because it now had enough VRAM to no longer fall back to system RAM). However, Unreal kept complaining about a driver bug regarding synchronization, that never led to any observable issues other than running into a (continuable) assert on editor startup. I am still using this card, and after some driver update, that warning went away.

The AMD card is working flawlessly for me, and I honestly do not want to switch back.

There is one thing that I need to highlight though: The nVidia rendering debugging tools (most important: nVidia Insights) are locked to nVidia hardware. AMD's tools are not locked to AMD hardware. So, if you use an nVidia card, you get access to all tools, while on AMD cards you need to make do with the tools you get from AMD (or Intel, or Microsoft).

In my spare time I luckily don't have to use Windows, and on Linux the AMD drivers are, in my opinion, superior to the nVidia drivers in almost all aspects. The most important thing about them is that they are open source, so you can actually edit the drivers, and mesa (the open source project that contains the OpenGL runtime) has some pretty amazing debugging features.

The AMD Linux drivers also integrate way better with the various desktop environments. With the nVidia drivers you more or less need to use the nVidia Control Center for some settings, what is not the case with the AMD ones.

The one drawback I see on Linux, compared to the nVidia drivers, is that setting up OpenCL is a little bit more involved with the AMD drivers - but since you nowadays can combine the open source drivers with the ROCm OpenCL runtime, that's not that a big deal any more.

Last, but not least: In my experience the AMD drivers are "more strict" when it comes to using graphics APIs and shader languages correctly. Back when I still used an nVidia card, I caused several bugs that only surfaced on a coworkers' AMD card. In all of those cases the bugs were actual bugs in my code, that only worked because they accidentally did the right thing on nVidia due to implementation-defined behaviour...

It's the Windows way. There applications typically also ship all dependencies. Either statically linked, or as a DLL files in their install folder.

It's not a good solution, but for games that's imho OK.

I'll give you my point of view as game developer.

Disclaimer first: I work as a coder, everything I say about publisher interaction is second-hand knowledge.

We have made one Linux game. It was the first one of our two "indie" titles (quotation marks, because both of them ended up being partially funded by a publisher, so they weren't really indie in the end), where we had promised a Linux build on Kickstarter, long before a publisher got involved.

The main reason why we did not do native Linux in our publisher-funded games is quite simple: Our publishers didn't pay us for it.

There are actually some publishers who are very keen on getting native Linux versions for their games, but we sadly have not released a game with any of them yet...

The publishers we released games with did not agree to the buget that we think is needed to do a Linux port of sufficient quality. If we would lower the price for doing a Linux port to the point where our publishers would agree to it, we would take on a lot of financial risk ourselves, so this is sadly not an option.

If everything worked as it is advertised by engine developers, making a Linux version would be quite cheap: Just click a few buttons and ship it. This is, sadly, not the case in real-life, as there are always platform specific bugs in game-engines. Our one Linux game was made with Unity, and we had quite a few Linux-only bugs that we forwarded to the Unity devs (we didn't have engine source code access), and had to wait for them to fix... For the engine we mainly use nowadays, Unreal, we have a rule-of-thumb: "Engine features that are used by Fortnite are usually well maintained." There is no native Linux version of Fortnite... (We did try Unreal's Vulkan RHI in Unreal 4.26 for Steam Deck support in one of our games. Let me put it this way: The game in question still uses Direct3D on Steam Deck.)

So, from experience we expect that the chance that we would have to find and fix Linux-specific engine bugs is quite high. Therefore we have to budget for this, what makes offering a native Linux version relatively costly compared to the platform's market share. Costly enough to make our publishers say "no".

This, by the way, also answers the question why publishers are willing to pay for the way more expensive console ports. There are also way more console players, and therefore potential customers out there...

(I can only guess, but I would expect publishers to be even more reluctant to pay for native Linux, now that WINE works so well that getting a game running on Linux needs typically zero extra work.)

As a gamedev I never saw this as a big issue. Just run Debian Oldstable on your build server, link whatever you can statically, and you are good.

(However, I am talking on a purely theoretical level here - we only released one Linux game, and that was before I joined the company. I will explain our actual reasons in a separate post.)

Takeaway message here: Beko support person does everything they can to recommend not buying from Beko.

It isn't that easy to go indie though, unless you do gamedev as a hobby and have another source of income.

I am working at what was a small studio (about 10 persons) when I joined, and has meanwhile grown to more than 50 employees.

I am a coder, and therefore don't have direct insight into our finances, so please take everything below with a grain of salt. It is also intentionally vague because I don't want to violate any NDAs.

Over the years we have started two indie projects, that both were completed and released, but both in the end had a publisher funding a part of the development. So, while they were indie initially, the released products cannot be called indie any more... The reason why we went for publisher contracts for those two projects were manyfold, but an important part was simply that we needed a way to cover our running costs. We are doing gamedev as a day-job, after all, so it needs to pay for our rent, food, etc... (Other important reason for going with a publisher were marketing, customer support,... All the things that we as developers have no experience in.)

Now that we have grown to medium studio size, we are hoping that we can at some point fund an indie project by making enough profit with other, publisher-funded projects. We have several projects running in parallel anyhow, and if 3 of them would yield enough money to pay a 4th project that would be fully our own, we would definitely go for it.

However, the market situation is tough, and we currently cannot afford to do that. Almost all profit we make goes into developing prototypes that we need in order to have a realistic chance to get the next publisher-funded project...

Two years ago it was a lot easier to get publisher contracts. Back then we were quite optimistic about being able to fund a fully independent project, but then the market changed, getting new publisher-funded projects has become a lot more difficult, and right now doing an indie project is (for us) not financially possible...

So, what we are doing now is that we are taking our game ideas and presenting them to publishers. The prottypes I mentioned? Most of them are for our own ideas. Having something the people at the publisher can play goes a long way in convincing them that a game-idea is fun. That's not indie, but it is as close as we can get to making the games we want to make. While the last year has been tough, with publishers being very, very, very cautious about new ideas, the situation seems to slowly change, and we might eventually get funding for one of our own ideas. Maybe. If we are lucky.