soulsource

The best part is the job opening...

Actively use and promote AI-assisted development tools to increase team efficiency and code quality

Probably the boss of the person who had to write the job opening demanded they include something about AI, and the person who wrote it decided to turn their sarcasm up to 100. The only way to make it more clear would have been sarcastic casing:

Actively use and promote AI-assisted development tools to InCrEaSe TeAm EfFiCiEnCy AnD cOdE qUaLiTy

Thanks, gonna do that first before I start my next print. This sounds like a really plausible cause!

The actual writing of course isn't pure. Loading isn't either, but we only support loading on level transition, so we can supply the data already when constructing the game state. Saving is done by gathering all the data that should be saved in a struct, what is pure and happens at a well defined point in the frame, where the game state is known to be consistent (-> I think it's after all systems have been updated), and then this struct is written out to a file.

As said, we try to. Not that we managed to reach this ideal in any existing project yet. We did manage to get Auto-Save implemented without affecting the "purity" of computations, but as you said, achievements and analytics are a PITA. I think those are possible with pure computations too, but we did not yet manage to build the game architecture in a way that makes that work. Yet.

I'm currently on a research project to investigate how much of a game we can move into pure Embedded Domain Specific Languages. So, basically a set of gameplay scripting languages that enforce the "everything that happens during the frame is pure" constraint. Buuut, again, this project is still at its early stages, and under very strict budget constraints, so I cannot say yet if the outcome will be a feasible architecture or not...

Every function has side effects and variables will need to be modified in multiple places in the same frame

We try to avoid exactly that, because it is what caused us man-years of bug-hunting and bug-fixing over our past projects. Our end-goal (that is still very far away...) would be to have the state from the previous frame and the user inputs, do only pure computations based on this data, and write out a new state before rendering the current frame.

We do use C++ though (because Unreal, and console platforms), what makes this extra hard, because C++ is a language for writing bugs, not for writing software.

I don't know if there are direct USB-C to PS/2 adapters, but assuming not: USB-C to USB-A adapter followed by USB-A to PS/2.

small performance hit

How big the performance hit is depends on the game. If the game logic itself is CPU-heavy, the performance hit will be big. If the game spends most of the CPU time in system-supplied libraries or isn't CPU-heavy to begin with, it's gonna be small.

The good news is that many VR titles aren't CPU-heavy.

For $50 I'd get (afaict current prices):

• Hades ($7.49)
• Pathfinder: Kingmaker ($2.99) (make sure to force-enable the Windows build on the Steam Deck, the Linux build has issues with gamepad input on the kingdom management screen)
• One Deck Dungeon ($1.99)
• Slay the Spire ($2.49)
• Wildermyth ($16.24)
• Against the Storm ($8.99)
• Terraformers ($7.99)

This totals now $48.18. If you have an additional dollar to spare, I'd also recommend to get something to scratch that retro-gaming itch:

• The Settlers 2 ($2.73 on GoG - needs DOSBox, for which I've written an install guide)

That's now $50.91 in total.

Oh, sorry. I stand corrected then.

I'm willing to bet that it's AI. It soft-contradicts itself quite often, emphasising that C++ is "Performance First", but then also claiming stuff like "Rust achieves memory safety with zero runtime overhead".

Edit: What I am trying to say is that I have seen text like this in LLM output quite often, if the LLM is mixing text from different sources in its training data.

Also, there is just wrong stuff in the text itself, not only in the conclusion. For instance the claim that Rust's type system makes data races impossible. They are easier to avoid, but there is nothing stopping you from writing data races... Here, for instance, have a data race in safe Rust...

I'm new to both, FreeCAD and Blender, but what I've been doing up to now:

• Draw the to-measure parts in FreeCAD
• Export them as STL
• Import STL in Blender
• Add decorative elements there in Sculpt Mode.
• Profit

Oh, and a small follow-up:

I just asked my partner which gamepad feels "better". She chose the Xbox Series X controller, so maybe my opinion isn't the most objective one.