soulsource @ soulsource @discuss.tchncs.de

Posts

0

Comments

186

Joined

2 yr. ago

Turmoil is on discount. It's very simple, but a lot of fun.

Even before Proton Valve was heavily invested in Linux gaming.

SteamOS has been around way longer than Proton, and the Steam Client had a native Linux version for such a long time, I don't even remember when it was published. Also, the Steam Linux Runtime is something worth mentioning - it is a common base that game developers can target instead of the various different distributions.

There are plenty on the web (for instance on handheld.quest), but I haven't found a single one that contains all details...

So, I'll just try to sum up the details here:

First things first: SSH stands for Secure Shell, and is basically an encrypted remote command line, but it offers much more features than just a command line, including, but not limited to, file transfer. The file transfer feature is also known as sftp, and generally considered to be the successor of the more well known ftp protocol.

The very first thing I would do on the Steam Deck would be to set a host name in the settings, such that you don't need to use the IP address to address it over the network. Screenshot (I totally haven't just found by googling).

The Steam Deck comes with an SSH server pre-installed, you need to enable it though. The following steps need to be done on a terminal, in desktop mode. The terminal that's installed on the Steam Deck is called "Konsole" (if I remember correctly). Once you have a terminal running on Desktop Mode, you can enable the SSH server via the following steps (I'll link the help for all commands I mention, so that you can verify that I'm not trying to trick you into doing something bad):

• First you need to get administrator ("root") access to the Steam Deck, what can be done by setting a password for the default user. Don't worry, the Steam Deck won't start asking for a password on startup, it's just required in order to get admin access. The command to set/change the current user's password is simply passwd. While typing the password, there won't be any feedback on the screen. This is normal.
• Once the password has been set, you can use the sudo command to run other commands as administrator. sudo will ask you to confirm your identity by entering the password.
• To start the SSH server, you can use sudo systemctl start sshd. Help files: systemctl, sshd
• To stop the SSH server again, you can use sudo systemctl stop sshd.
• To enable autostart for the SSH server, sudo systemctl enable sshd (but I would not recommend this unless you disable password based logins - see below)
• To disable autostart for the SSH server, sudo systemctl disable sshd

On the PC from which you want to connect to the Deck you will need some kind of sftp client. On Linux most file managers have sftp functionality built-in. On Windows and MacOS one needs a special program for this though (afaik). There are many, many alternatives here (just search "sftp client" in your search engine of choice), but the most well known one is FileZilla, which works on Windows, macOS, Linux and many other operating systems. I recommend FileZilla for two reasons. The first is that it's open source (and free of charge), the second one is that I personally like it as a tool. At work I (have to) use Windows, and whenever I have to transfer files to a remote system like our webservers, our contractor's cloud storage, or simply to copy a few music files from my phone to the office PC (yes, I am this old), FileZilla is the go-to solution for me.

If you have started the SSH server on the deck, you should now be able to access its contents via sftp. The default user on the Steam Deck is called deck, the password is the one you set earlier using the passwd command. If you are lost using FileZilla, there's a user's guide online.

Now, as promised, a few words on security and autostarting the SSH server. If you plan on auto-starting the SSH server on the Steam Deck, I would recommend to set up a means to connect to it without a password, and then to disable password-based SSH connections. The reason is that the Steam Deck, as a mobile device, will quite likely end up in insecure or otherwise untrusted wireless networks, and passwords are really not the most secure way of user authentication... Since SSH is a full remote access protocol, anyone who guesses your password and can reach the deck over the network could do anything on it. Given that the deck's battery runtime is already short enough even if there is no bitcoin miner running in the background, you probably don't want password based logins via SSH enabled permanently.

That's where Public-key authentication comes in. You can configure the SSH server to allow users to connect without a password, if the users have access to a private key for which the corresponding public key is known to the server. To enable this, all you need to do is to create a public/private SSH key pair, and upload the public key to the SSH server on the Steam Deck. The exact process of creating those keys is again depending on the operating system. Here's a guide about SSH key generation that includes instructions for macOS and Windows. On macOS or Linux the instructions are actually identical. You just need to open a terminal, and, if they don't exist for your user yet, run ssh-keygen to create the keys. Then you can use ssh-copy-id to upload the public key to the Steam Deck. Once that is done, if your system uses ssh-agent, connecting via public key should "just work" - also in FileZilla. If you don't use ssh-agent, you can try these steps in FileZilla.

Once you have confirmed that passwordless public-key logins are working, you can edit the file /etc/ssh/sshd.conf on the steam deck. You'll need admin access, so the easiest way to do that is probably to run sudo nano /etc/ssh/sshd.conf on a terminal (nano help). The relevant change is to replace the line #PasswordAuthentication yes by PasswordAuthentication no (here's the help file for sshd.conf). In order to apply these changes, you probably need to restart the SSH server: sudo systemctl restart sshd.

Enable SSH access (but make sure it only accepts key-based logins - password based on a mobile device that might operate in untrusted networks is a bad idea).

If you enable SSH, you can transfer files from the PC over WLAN. (If you are on Windows: FileZilla is your friend.) Also, you can remote access the Steam Deck command line via SSH. (If you are on Windows: PuTTY is your friend.) That's way less annoying than having to type longer texts (think: script files to launch emulators) with the on-screen keyboard.

Oh, and if you are into Retro Gaming, my small guide on how to add DOS games to the steam library and get MIDI working for them might be worth a look.

There's another thing that might be relevant: The Game Mode UI on the Steam Deck doesn't support creation of ad-hoc wireless networks (afaik). I think (but never tried it) that it's possible in Desktop Mode though.

That solely depends on the question what you consider "Casual". I'll go with the definition "a game that doesn't need a significant time investment per play-session".

• Super Hexagon: Amazing music, simple game, but challenging.
• Triptych: Tetris with soft body physics. The game is great, the sound a bit annoying. Also, I don't think it's available on Steam, so it needs manual installation (and input bindings).
• Cultist Simulator: While the game is very obscure, it doesn't require a lot of time per session - you can start it, play 5 minutes, and exit it again.
• Hades: It's a Roguelite. You die. A lot. That's why each session can be rather short.
• Loop Hero: It's not as "casual" as the others, as it takes some time for each run, but not too much.

And up to now we have zero indication that the current approach isn't a dead end. Bill Gates, for instance, thinks that GPT-4 is a development plateau: https://heise.de/-9337989

Okay, Youtube was maybe a bad example. They aren't that far with the enshittification yet, and just started increasing the amounts of ads...

Things I do expect:

• Price increase
• Tiered pricing (okay, that's already a thing for GamePass with the "PC" and "Ultimate" plan)
• Lower price tiers including advertisements (could for instance be placed in games streamed from the cloud)
• Other things that aren't beneficial for consumers.

If you want to know how Games Streaming will look like in 10 years, compare today's YouTube to how it was 10 years ago.

Given how bad the WIFI chip of the current Steam Deck is (it just doesn't like some access points and has frequent connection losses with them), waiting for an updated one might be worth it.

I liked it a lot, before they added base-building and all that other stuff that doesn't align with the game's original vision.

I'm not an artist - my 3D modelling experience can be summed up as "none", so I can't really answer your last point. I know for certain that we don't use normal maps to the extent they could be used, and therefore have way more detail in the meshes than they would need to have. I'm also pretty certain that we don't do any tesselation on player pawns, and I think (but am not certain) that this is due to some engine limitation (again, don't quote me on that, but iirc Unreal doesn't support tesselation on skeletal meshes on all our target platforms).

Tell that to our artists 😉. As a coder I'm all for procedurally generated content. I did replace several heavy textures in our games by procedural materials, to squeeze out a couple of extra MB. However, that's not the way artists traditionally work. They often don't have the programming knowledge needed to develop procedural materials on their own, and would need to rely on technical artists or programmers to do so. Drawing a texture however, is very much part of their skillset...

But yeah, the mention of "squeezing out a couple of MB" brings me to another topic, namely that (at least in our games) the on-disk textures are only part of the RAM usage, and a relativley small one on comparison. In the games I worked on, meshes made up a significantly larger amount of RAM usage. We have several unique assets, which need to fulfill a certain quality standard due to licensing terms, such that in the end we had several dozens of meshes, each over 100 MB, that the player can freely place... Of course there would still be optimization potential on those assets, but as always, there's a point where further optimization hits diminishing returns... In the end we had to resort to brute-force solutions, like unloading high quality LODs for meshes even if they are relatively close to the player... Not the most beautiful solution, but luckily not often needed during normal gameplay (that is: if the player doesn't intentioally try to make the game go out-of-memory).

But I'm rambling. The tl;dr is: The memory constraints would not be a big deal if there was enough time/money for optimization. If there is one thing that's never enough in game dev, it's time/money.

I was talking about the person(s) at Microsoft, who decided that it's a good idea to have less RAM on the Series S than on the Series X...

(And for context: I work in gamedev, and in my experience making games stay within the memory budget is one of the toughest parts of porting games to consoles.)

Thanks! I caught it more or less by chance though. I was just scanning all moons in the system, and thought that landing would be a nice break from the scanning routine. And then this happened. It looked even better a few moments before, when the sun that's visible in the shot was still partially occluded by the gas giant. Took me too long to fire up camera mode to catch that though...

Yes. It's in the Xbox Requirements, as in, the checklist of stuff you need to fulfill if you want to release a game on Xbox. To be precise, it's test case 130-04: Featured Game Modes.

Whoever made that decision obviously never worked in gamedev.

My recommendation list is going to be a wild mix of different styles. Basically aynthing in my Games Library that I find visually appealing...

• Gibbous - A Cthulu Adventure: While it isn't my favourite point&click (that price goes to the Deponia Trilogy), it's by far the most beautiful I've played up to now. The attention the devs paid to detail is astounding. The animations are perfect. In other words: A work of art.
• Euro Truck Simulator 2: I might be an exception here, but to me the main selling point of this game is the scenery, not the trucks.
• Elite: Dangerous: Most of the times this game looks utterly boring. Sometimes however, you catch an exceptional sight. Here's a screenshot of an eclipse in a binary system, as seen from an icy moon of a gas giant (behind which the primary star is hidden).
• Space Engine: Same argument as for Elite. Most of the stuff is boring. Sometimes you find an exceptional sight. Also, Space Engine isn't really a game, but rather a "beautiful picture generator", as there is no real gameplay as of yet.
• Dwarf Fortress in ASCII mode: The ASCII "graphics" are a work of art on their own. Especially the animations. And the best part: The ASCII version can be downloaded for free, while the (imho less beautiful) graphical version costs money.
• Pyre: A mix of Visual Novel and Sports Game. The backgrounds and characters are beautifully drawn.
• Beat Hazard: The colours of the effects are stunning.

For obvious reasons I can't post it publicly before MS discloses it. They are currently migrating more and more GDK docs to the public site, so I wouldn't be surprised if the link became publicly available soon, but currently one still needs to register a dev account to access it.

That number is - well, let's just say, the correct value can be found in the docs here: https://learn.microsoft.com/en-us/gaming/gdk/_content/gc/intro/whatsnew/archive/whats-new-2206