As others have said, tiny market, but also that it often requires more development for the Linux port to get going, and even more development to actually make it run well. Like for instance, Civilization series usually release with Linux and Mac ports, but those are done by a third-party company which I imagine does add additional costs, and those suck regardless.
Not like it’s a bad thing necessarily, the vast majority of native Linux ports I’ve tried were either severely out of date, had significant performance issues, crashed a lot or had some quirks that would make it not worth playing anyway. It’s probably just easier if developers focused on proton compatibility instead.
It’s not about compiling, it’s about testing and support. Each officially supported version needs to be tested - which means having yet another set of test systems sitting around - and supported by the support team. And not only is Linux a splintered market in its own right, making testing and support a significant operation, but there isn’t the same kind of single-point OS support that you get from Microsoft and Apple.
On Steam store.steampowered.com/hwsurvey/, all Linux operating systems combined have around ~2% users, compared to the MacOSX ~1.4%. This is only a recent trend, as for the longest run Mac had more Steam users than before. And building a native Mac game was more straight forward than on Linux.
Nowadays its completely different than before, thanks to Proton integrated into Steam. This means even though there is a higher percentage of Linux players on Steam, there is less reason to make native Linux games. That has some advantages: Windows binary through Proton has feature parity without the devs needing to understand the underlying Linux system and libraries, less work for the developers means higher probability of supporting Linux for longer time, thanks to Proton and the auto selection of Proton version for each game its also less worry for the end user. It does not matter what system libraries you have installed or what operating system you are using.
It would be nice to have, but in reality there is no real need for native Linux games from developers or for the end user / player.
Market share and yes, Proton/WINE ultimately lessens the need for a native Linux port.
In a fair number of cases, even when there is a native Linux port, Proton/WINE has worked better than the native game.
If Linux gets to 5-10% of the market, we’ll probably see them come back for platform specific optimization reasons. However, without a larger market share and with the translation being so good these days, there’s not a lot of need.
If the least used operating system. Why limit your audience to such a small niche to begin with? Game development isn’t cheap. You tend to not want to lock out your chances of recouping that by blocking 90% of potential players
It’s still an argument, given that this historically wasn’t the case. And Mac used to have a bigger share of the pie. Do they even make Mac only games anymore?
But those numbers pretty much prove my point. Unless you’re already set up to be making games specific to a system, there’s no point in starting from scratch to only name something for 1-2% of the market.
If the least used operating system. Why limit your audience to such a small niche to begin with?
… which is no longer true. Also supporting Linux does not mean its limited to Linux only. This is in addition to Windows. And supporting Steam Deck comes with some extra goodies for the publisher, as they get some extra marketing in Steam itself and by videogame outlets, fans and YouTubers speaking about it. Do not make the mistake and look at numbers without taking context into account.
Your argumentation only explains why devs didn’t create Linux native applications in the past. I said its no longer the case. So don’t misunderstand me. What you said is true for the past, not today.
The short answer is in many cases it’s just not worth it. Maintaining a Linux build is not free and the possible market share gain is fairly minimal. Add to that the possibility you get it for free through proton and your reasons for investing the dev effort shrink.
I’ve heard an argument for maintaining Linux builds because Linux users will provide better bug reports but that mindset is unlikely to ever survive in a big studio
It does not matter. The point I was referring to you is that Linux is no longer the least used operating system and why its not limiting to that operating system when creating native Linux support. And no, its not about Native Linux Only games, its Native Linux games in addition to Windows games.
Your argument which I quoted is no longer an argument today.
This is not what you said. This is not pedantic. ok you know what you are right and happy birthday. No need for toxicity here. If you don’t even know what you are saying and changing your argumentation over the discussion we had.
I didn’t say anything (you might notice I’m not op). What I am saying is that you are willfully misinterpreting the spirit of op’s argument. Also, nice touch saying no toxicity and then being toxic. Very classy
You added “only” in there. You can compile a game for each OS natively (and many games do). Native in this context refers to the binary itself (ELF, EXE, bin, etc), and the OSes that can run it without using some kind of compatibility layer.
I was playing Apex and any time there was a Playstation player on my team the framerate dropped down to like 5FPS for minutes at a time. So I think it’s still struggling
Interesting. Once you are in the game, I think it’s all Epic servers, so should work, but it’s possible there’s still some weird PSN connection that may stop it from working.
As others have said start with 5. The rule of thumb for civ games is to wait for the expansion dlc to release and buy the game on sale. 7 is also a significant departure from the previous games, so it’s probably even more important to wait or outright skip it until they get it more polished.
Also it’s worth looking into endless legend or endless space 2 if you want to try more 4x games.
That’s harder to implement. Suddenly you need to store that extra state somewhere and don’t mess it up. The last save should already have a timestamp and is immutable. A lot less likely to get bugs that way.
The state “the game is paused” is different from " the game is paused and saved". Sure that could be another key in some atate machine but like above: it’s the “not mess it up” part that is harder.
Plus all the lines to update the state, when the menu is closed, when the game is closed (i.e should it be true or false at startup), when the game is saved obviously.
That’s at least three more lines plus the one you mentioned for no extra value. And again it’s easier to screw it up e.g. while refactoring.
I think we write our code in different enough ways that we’re not seeing eye to eye.
Tracking the state of the game being paused, when the menu is open and when the game is saved can all be a single match statement on a current “game state” variable which just holds “running/paused/paused and saved/exit” and when it becomes exit, it checks the save time. Only 2 lines of code and adding an enumerated state to the variable to add this functionality. Since the variable is enumerated, it’s really difficult to mess it up when refactoring because if you can’t pass the wrong code or else your game doesn’t save or close
Ok, I mentioned a state machine in another sub thread. It’s not as bad if you already have a state machine.
It’s still adding more complexity though - again when the value is updated. You still need to change the state when saving. You need to decide which state to use when starting the game.
There is still risk of screwing that up when refactoring. And still the value is nearly none.
Regarding state mchines, it’s a complexity in itaelf to add random flags ro the state machine. Next time you want to add another flag you need to double all the states again, e.g. PAUSED, PAUSED_AND_SAVED, PAUSED_AND_MUTED, PAUSED_AND_SAVED_AND_MUTED. I would never add mute to the logic of the menu but that’s the pnly example I could come up with. Maybe you see my point there, at least?
Complexity being added at updating also feels wrong to me. Let me pseudo code some rust (just the language I know best off the top of my head right now) at you, cause it feels like maybe I’m just not understanding something that’s making this seem easier than it is.
<span style="color:#323232;">Enum Game_State
</span><span style="color:#323232;"> Paused
</span><span style="color:#323232;"> Paused_Saved
</span><span style="color:#323232;"> Running
</span><span style="color:#323232;"> Loading
</span><span style="color:#323232;"> Exit
</span><span style="color:#323232;">
</span><span style="font-style:italic;color:#969896;">///Technically you could make Menu() part of the enum but I'd probably leave it elsewhere
</span><span style="color:#323232;">
</span><span style="color:#323232;">Match Game_State
</span><span style="color:#323232;"> Paused </span><span style="font-weight:bold;color:#a71d5d;">=></span><span style="color:#323232;"> Menu()
</span><span style="color:#323232;"> Paused_Saved </span><span style="font-weight:bold;color:#a71d5d;">=></span><span style="color:#323232;"> Menu()
</span><span style="color:#323232;"> Running </span><span style="font-weight:bold;color:#a71d5d;">=></span><span style="color:#323232;"> Main_Loop()
</span><span style="color:#323232;"> Exit </span><span style="font-weight:bold;color:#a71d5d;">=></span><span style="color:#323232;"> Exit()
</span>
And then your other functions always return a game_state. You’re right that adding that return would be a huge undertaking if it’s not handled in the initial building of the game, but it’s a QoL for the user that’s easily maintainable and is therefore worth doing IMO. But these two things, defining the possible game states and then always routing decisions through that game state, makes this kind of feature relatively doable
I’m sorry I don’t getting your point . You start off by agreeing that you don’t like the extra complexity that the update statements give. Then do some pseudo code of something entirely different where we all already agree is not an issue.
Then at the end your conclusion is that it is totally feasible. Why? You still didn’t adress the problem of updating the state
My point was “are state machines really that complicated? Isn’t it just something like this pseudo code and a return value from your functions?”
Basically I feel like this is a 2 step process but you seem like you either know more than I do or have a different philosophy about how this would be implemented, so I want to understand what I’m missing
bin.pol.social
Gorące