(I don’t know why jamstack has taken over that site, but the list itself seems to be intact.)

Not really taken over, more just a rebranding. Both are owned by netlify, started off as a list of static site generators you could use with netlify (aka all of them they could find) but then they just rebranded the site and gave it a fancy name like you have with all the other web stacks you have these days.

I think their though process is more along the line of:

Hey, Microsoft is getting all the bad attention ATM, let’s see how much shit we can sneak in while people are distracted.

You are forgetting about Nintendo. And that is only mentioning gaming companies… look outside gaming and there is a whole shit-show going on at the moment for that position.

Players get sustained access to the game.

That should be the default for any game you have brought… not a compromise… Forcing everyone to have an account only serve to benefit Sony.

If they can make it such that you can have a placeholder Sony account that can’t access all PSN features, for the sole purpose to play this and other Sony games on Steam, that anyone in the world can access, that would be an acceptable compromise to me.

If they did that then what is the point in requiring a login at all… just remove the damned feature that is not required and very few want. We know it is not required as the game has been working fine for months without it. There is zero need for you to need a login for this game. Except that sony wants more user information they can sell to others.

Whatever language you chose you might want to also look at the htmx JS library. It lets you write in your html snippets better interactivity without actually needing to write JS. It basically lets you do things like when you click on an element, it can make a request to your server and replace some other element with the contents your server responds with - all with attributes on HTML tags instead of writing JS. This lets you keep all the state on the backend and lets you write more backend logic without only relying on full page refreshes to update small sections of the page.

For a backend language I would use rust as that is what I am most familiar with now and enjoy using the most. Most languages are adequate at serving backend code though so it is hard to go wrong with anything that you enjoy using. Though with rust I tend to find I have fewer issues when I deploy something as appose to other languages which can cause all sorts of runtime errors as they let you ignore the error paths by default.

Yup, and that is because people only ever lean DRY coding by its name. It is never really what it originally meant, when to use it and more importantly when not to use it. So loads of people apply it religiously and over use it. This is true of all the popular catchy named methodologies/principals etc.

Yup, this is part of what’s lead me to advocate for SRP (the single responsibility principle).

Even that gets overused and abused. My big problem with it is what is a single responsibility. It is poorly defined and leads to people thinking that the smallest possible thing is one responsibility. But when people think like that they create thousands of one to three line functions which just ends up losing the what the program is trying to do. Following logic through deeply nested function calls IMO is just as bad if not worst than having everything in a single function.

There is a nice middle ground where SRP makes sense but like all patterns they never talk about where that line is. Overuse of any pattern, methodology or principle is a bad thing and it is very easy to do if you don’t think about what it is trying to achieve and when applying it no longer fits that goal.

Basically, everything in moderation and never lean on a single thing.

Refactoring should not be a separate task that a boss can deny. You need to do feature X, feature X benefits from reworking some abstraction a bit, then you rework that abstraction before starting on feature X. And then maybe refactor a bit more after feature X now you know what it looks like. None of that should take substantially longer, and saves vast amounts of time later on if you don’t include it as part of the feature work.

You can occasionally squeeze in a feature without reworking things first if time for something is tight, but you will run into problems if you do this too often and start thinking refactoring is a separate task to feature work.

“Best practices” might help you to avoid writing worse code.

TBH I am not sure about this. I have seen many “Best practices” make code worst not better. Not because the rules themselves are bad but people take them as religious gospel and apply them to every situation in hopes of making their code better without actually looking at if it is making their code better.

For instance I see this a lot in DRY code. While the rules themselves are useful to know and apply they are too easily over applied removing any benefit they originally gave and result in overly abstract code. The number of times I have added duplication back into code to remove a layer of abstraction that was not working only to maybe reapply it in a different way, often keeping some duplication.

Suddenly requirements change and now it’s bad code.

This only leads to bad code when people get to afraid to refactor things in light of the new requirements.Which sadly happens far to often. People seem to like to keep what was there already and follow existing patterns even well after they are no longer suitable. I have made quite a lot of bad code better by just ripping out the old patterns and putting back something that better fits the current requirements - quite often in code I have written before and others have added to over time.

Never seen anyone change it for the mouse, but I think for a joystick and especially gyro it is more common to have them different. Same basic principal applies to all three inputs though.

In first person games the distance you need to move horizontally is often far more then the distance you need to move vertically, quite often only needing to look up/down a small amount. So you can get better accuracy in the vertical direction by turning down the sensitivity without sacrificing the ability to move quickly up and down. But in the horizontal direction being able to move quickly is generally more important than better accuracy.

Not sure how important the difference is for the mouse though, likely why people don’t use it. But it is an easy setting to split up for the developers so why not give players control over it and set it however they like? Would be nice if you could lock them together, but that is a little more complex and requires more thought to do. And I don’t see game devs giving that much thought about the minor user experience improvements in their games settings when they have a load of gameplay still to worry about.

How do we know these are the AI chatbots instructions and not just instructions it made up? They make things up all the time, why do we trust it in this instance?

The license is MIT, so should be fine for most things

From the article:

A quick Microsoft demo video shows the Copilot key in between the cluster of arrow keys and the right Alt button, a place where many keyboards usually put a menu button, a right Ctrl key, another Windows key, or something similar. The exact positioning, and the key being replaced, may vary depending on the size and layout of the keyboard.

What is sad is that 6 of the 12 platinum games rated by top revenue are free to play games - so must be making money on micro transactions. Sad that model works so well for extracting cash out of players.

Many hyped up games fail immensely at some parts

Well, yeah… that is so vague that it cannot help but be true. Almost all games fail in some way (especially more complex ones), they can all be improved by making some changes somewhere especially when everyone has different preferences for how things should work and what annoys them.

And by definition almost any hyped up game is going to fall short of expectations. Hype is born by imagination and has no limits, but games are delivered in reality where compromises need to be made, especially when time pressure is involved. And by nature the more hype a game is the more likely it is going to be over-hyped and fall far shorter of the expectations.

I am wary of any hyped up game. Hell, I would be wary of any AAA game on release day these days. Wait for real reviews to come in and not what the prerelease hype says about it. And even after remember that what games one person enjoys a lot another might absolutely hate.

But, I will not be purchasing another AAA game from CDPR until at least 6 months post-release

FTFY, unfinished release day games seems to be more than just a CDPR problem.

As long as I can remember

Just use the search bar… the only one they have that is on every page at the top right. That takes you to the results which defaults to code, but you can change it on the side to show repos, issues, prs, etc. You can even limit it to single repos or whole organisations.

I would start by learning rust at a user level via the rust book to get you familiar with the language without the extra layers that embedded systems tend to add on top of things. Keep in mind that the embedded space in rust is still maturing, though it is maturing quite quickly. However one of the biggest limitations ATM is the amount of architectures available - if you need to target one not supported then you cannot use rust ATM (though there is quite a few different projects bringing in support for more architectures).

If you only need to use architectures that rust supports than once you have the basics of rust down take a look at the embedded book, the Discovery book and the Embedonomicon. Then there are various crates for different boards such as ruduino for the arduino uno, or the rp-pico for the raspberry pi pico, or various other crates for specific boards. There are also higher and lower level crates for things - like ones specific to a dev board and ones that are specific to a chipset.

Lastly, there are embedded frameworks like Embassy that are helpful for more complex applications.