Support us on Patreon
PayPalGiving a nice boost to a classic free and open source game, SuperTux has now been released on Steam and it's free to download and play.
"Run and jump through SuperTux, the sidescrolling 2D platformer starring Tux, the Linux mascot. Squish and knock out enemies, collect powerups, and solve platforming puzzles throughout the Icy Island and the Rooted Forest, as Tux tries to save his beloved Penny from her kidnapper, Nolok!"
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Direct Link
Direct Link
Features:
- Platforming gameplay similar to original Super Mario games, with some unique abilities such as backflipping and dynamic swimming
- Lovingly hand-crafted graphics contributed by a variety of artists, alongside engaging and catchy music
- Engaging levels designed with casual gameplay, puzzling and speedrunning in mind
- Weird, quirky and some not-so-adorable enemies that might be too cute to kill
- Two full worlds packed with unique and challenging levels, castles, and boss fights
- Other contrib levels, including seasonal worlds, storyless bonus islands, and downloadable Add-ons, which feature new and unique stories and levels
- Simple, flexible Level Editor, which allows for the creation and sharing of levels of any complexity
There's one weird issue it's come with for Manjaro users, who currently need to remove "appimagelauncher" and then it seems to work after a reboot. Other than that, it seems to have been received well by Steam users with it already getting a Positive rating. If you're after a classic free Mario-like, this is it. Not a complete game though, they still have plenty more to add into it and since it's open source anyone can help.
Download on Steam or grab it from the official site / Flathub.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
pleasereadthemanual Jan 22, 2022
Quoting: MayeulCIronically the Proton version works better than the native version in the Steam Flatpak.I'm not a developer, but as far as I'm aware, it's up to the developer what they include in the AppImage. And they also get to decide how they want the AppImage to be updated—it's in their hands.
Quoting: pleasereadthemanualI love the format; it's so simple, gives the developer a lot of control, and solves the age-old issue of dependencies being updated over time.
There's plenty of issues with the format too: it's harder to update said dependencies, it still relies on a bunch of dependencies on the host, it also relies on a couple of weird tricks.
Basically, the most interesting part of the format is that it's delivered as a single file. Great for running multiple versions side-by-side, and easy to use in a portable way. Besides that, not much.
Flatpaks are relatively portable too, it would probably be pretty easy to provide one-file exports, although it would require flatpak on the target computer as well to run :)
On the flip side, assuming these two points are accurate, that means a lot of the onus is on the developer to do things correctly. AppImages aren't really "standardized" in the way that Flatpak is, so there's a lot less direction. Just look at Audacity 3.0+; all of the AppImages they've ever shipped have been broken in some way on GNOME 41+.
I do have concerns about whether a Flatpak would hold up in 10 years time. I'm sure an AppImage would with the right dependencies; you just need to flip an execution bit and execute it. Flatpak just seems like a more complex system with reliance on a considerable amount of infrastructure existing in the same way it does today. Also, sandboxing makes things more complicated.
From an end-user perspective: I already have to manage both the main repositories for my distribution and the AUR for a choice few packages, I don't want to manage another package manager like Flatpak (and I really don't like the CLI interface; actually, I think I hate all package manager's interfaces except for pacman). AppImage makes things simple; I just open the application and it tells me whether it wants to update, and I update (or not).
Yes, I would rather Flatpaks than Snaps, of course.
1 Likes, Who?
Flatpak packages are not very difficult to create. The sandboxing is there mainly if you want it, otherwise you can always bypass it relatively easily (it's not advised, but it's still part of the standard).
The Flatpak manifest simplifies A LOT the dependency management, you just point to the git repo and tag, or the release tarball, or a local file, or ... and it will compile almost everything for you, you don't have to compile everything yourself and package it in an AppImmage.
So yes, Flatpak can be a bit more complex than AppImage (which is basically a bundle of files), but it's just a matter of reading a few pages of documentation and asking questions on le communication channels. After that, the aforementioned complexity becomes a helping tool for the devs. And if the dev wants to dig deeper, they can see how to sandbox the shit out of their application. (I do maintain an application installable through Flatpak).
The Flatpak manifest simplifies A LOT the dependency management, you just point to the git repo and tag, or the release tarball, or a local file, or ... and it will compile almost everything for you, you don't have to compile everything yourself and package it in an AppImmage.
So yes, Flatpak can be a bit more complex than AppImage (which is basically a bundle of files), but it's just a matter of reading a few pages of documentation and asking questions on le communication channels. After that, the aforementioned complexity becomes a helping tool for the devs. And if the dev wants to dig deeper, they can see how to sandbox the shit out of their application. (I do maintain an application installable through Flatpak).
0 Likes
See more from me