[HN Gopher] Developing Games on Linux: An Interview with Little ...
___________________________________________________________________
Developing Games on Linux: An Interview with Little Red Dog Games
Author : nixcraft
Score : 215 points
Date : 2021-06-24 16:32 UTC (6 hours ago)
(HTM) web link (blog.system76.com)
(TXT) w3m dump (blog.system76.com)
| DizzyDoo wrote:
| I published my first Steam game on Linux as well as Windows and
| MacOS, but I don't think I'll do it again because for a single
| person developer (as indie as it gets) the time spent supporting
| Linux doesn't pay off. Within days of publishing my game I had
| support request emails that said "so I'm on this specific Red Hat
| version, with this oddball graphics driver and three monitors and
| full-screen doesn't work with your game properly". As I only
| officially supported Ubuntu I couldn't really help each exotic
| (to me) setup that came into my email inbox, and there was more
| than a few. Which I still think is a shame.
|
| But that was five years ago. I'm pretty sure Photon supports my
| Windows builds on Linux better than I was ever able to do with
| the native executables, and at least there's that.
| bachmeier wrote:
| > As I only officially supported Ubuntu
|
| Why not just tell them that? Is it really better to give up
| those dollars because someone is using a setup you don't
| support?
| DizzyDoo wrote:
| I did? Both on the store page and in my email replies. Most
| people were understanding though some weren't.
|
| However, those dollars you seem anxious I don't give up
| _still_ didn 't really cover the time investment of dealing
| with Linux - not just the support requests, but getting the
| build environment setup and performing the testing and all of
| that.
|
| For reference, the game in question did ~75% of units sold on
| Windows, ~25% on Mac, and some fraction of a percent on
| Linux. If I hadn't of released on Ubuntu I would have
| probably lost less $1000, gross.
| z3ncyberpunk wrote:
| Considering forum text messages have no emotion, you are
| the one projecting your anxiety by your accusal, not the
| other way around. If you told them, why are YOU so anxious
| about support for Linux enough to complain about it here?
| "I don't support your distribution", case closed.
| steeleduncan wrote:
| Steam has the "Steam Linux Runtime" these days[1]. It runs
| games inside a container with a fixed set of libraries. As long
| as it runs in there you don't need to worry about the host
| distribution.
|
| [1] https://github.com/ValveSoftware/steam-runtime
| tsimionescu wrote:
| You're still using the system specific X/Wayland, Pulseaudio,
| and the system video drivers. I would bet that a majority of
| game bugs come out of one of those.
| smoldesu wrote:
| Honestly, developers will probably have a better time
| maintaining Proton versions than writing native Linux ones. As
| long as your game has silver or higher on ProtonDB, you can
| have my money.
| freedomben wrote:
| As a linux user, thank you for at least trying. Also I don't
| know if this is applicable but don't let a few rude users color
| your perspective too much. There are lots of people like me who
| are thrilled if you just support "Ubuntu". That at least makes
| it _possible_ for me to get it working.
| OhSoHumble wrote:
| I've always wondered how feasible it would be if an indie
| developer (or maybe even a big studio) could just put out a
| Linux build of their game and just say "we're not going to
| support this outside of these very specific constraints - or
| even at all - we'll fix issues with our Linux build if we can
| reproduce those issues in the environment we developed the game
| in... but that's it."
|
| Then the Linux community gets another game. Does it not work on
| K.I.S.S Linux running sowm as a window manager and an entire
| custom userspace? Probably not. Does it work using the latest
| Ubuntu version? Probably.
|
| But the notion that developers _have_ to support every possible
| Linux configuration out there just seems toxic to the Linux
| game development effort as a whole.
| aidenn0 wrote:
| From my point of view, one person telling all their friends
| that your game sucks can completely offset the nearly zero
| sales of native linux games. On the other hand most linux
| gamers know how to run games under wine, so I really don't
| see any advantage for a developer to make a native linux
| version.
| bscphil wrote:
| > On the other hand most linux gamers know how to run games
| under wine, so I really don't see any advantage for a
| developer to make a native linux version.
|
| Maybe I'm in the minority, but I've never bought a game
| because it could theoretically run under Wine, while I've
| bought quite a few games that run on Linux. Very rarely do
| I buy a game that does _not_ natively run on Linux.
|
| Wine seems like kind of an ugly hack even in the best case
| scenario. You don't know what performance is going to be
| like with your hardware, and you usually don't have anyone
| who's tested the program on your hardware to make sure it
| runs correctly and doesn't crash, and obviously games are
| extremely sensitive to these kinds of hardware dependent
| things. Installing Wine can be gross too, you have to
| install a bunch of 32 bit libraries on an otherwise clean
| 64 bit system.
|
| I'd say the appeal of making a native Linux game is that it
| gets you access to the market of people who will buy a
| native Linux game. It's true that you already had the
| market of people who are technically running Linux and
| playing Windows games via Wine, but presumably there are
| many people who aren't going to go to that much trouble.
| (Obviously, there are many cases where supporting Linux
| isn't financially viable anyway, Wine _or_ native.)
| aidenn0 wrote:
| I have more than once bought a native linux game, gave up
| getting it to work, and run the windows version under
| wine.
|
| At this point I just buy windows games, and if they don't
| work under wine, I run them in a VM.
| arp242 wrote:
| Personally I'd just respond to stuff like that with "Sorry,
| but that's a very obscure combination, and as a single indie
| dev I unfortunately don't have the bandwidth to support that,
| I can send you a refund if you want".
|
| As long as you're nice about it and don't turn it in to a
| bland cookie-cutter "corporate" response most people will
| understand.
|
| As someone who just runs Linux, and occasionally runs some
| games on it, I'm always a bit annoyed when people report
| these kind of very specific bugs with old/weird
| drivers/distros that aren't in the supported platforms list.
| It turns developers off for completely understandable
| reasons.
|
| I run Void Linux, it almost always works, but I'd never
| report these kind of bugs without testing Ubuntu (or whatever
| else is supported) first.
| danudey wrote:
| > Does it work using the latest Ubuntu version? Probably.
|
| KDE doesn't even work on the latest Ubuntu version - on my
| hardware, at least.
|
| I have an Ubuntu system with an Intel graphics card, and my
| system won't boot into KDE unless I remove the old Intel
| driver that it defaults to, so that it then tries the new
| Intel driver which actually works. Gnome, Enlightenment, and
| whatever Ubuntu defaults to, they all work fine regardless,
| but KDE doesn't.
|
| Note that this is _after_ removing the 'Intel' driver for
| xorg, which had tons of screen tearing issues, in favor of
| the apparently "correct" modesetting driver, which is the
| preferred option for newish Intel cards. Except that at some
| point I was installing something else which explicitly
| depended on the Intel driver package...
|
| And then we all ended up working from home and now I don't
| have to deal with any of that crap. Now I just use xorgxrdp
| from my Windows machine and it just works.
|
| I can't imagine the gigantic hassle that would be trying to
| game on Linux in that kind of environment, where the
| "supported" and "default" options are the wrong choice and
| you have to manually uninstall things if you want stuff to
| work properly. No thanks. I love Linux (way, WAY more than
| Windows), but I'm not going to waste time and energy trying
| to play games on it.
| insraq wrote:
| I recently did exactly this for my game (Industry Idle) on
| Steam. I added Linux build but pinned a post that says "Linux
| and Mac support are considered experimental and are supported
| on best effort basis" (https://steamcommunity.com/app/1574000
| /discussions/0/3122659...)
|
| Most people are very helpful and quite understanding that as
| a sole indie developer, it would be hard to support all the
| configurations. But occasionally I get angry emails and
| negative reviews about game not running on Linux.
|
| Given the sales (Linux is 1% of the total sales, Mac is 3%),
| I would say for an indie developer, it makes more sense to
| put Linux support on a low priority. It is unfortunate for
| Linux gaming community but it is what it is.
|
| Also even though Proton has come a long way and has become
| relatively stable - occassionally there are some strange
| issues (like Steam Cloud sync fails, etc) here and there. But
| overall the effort is much lower compared to maintain a
| separate Linux build.
| kevincox wrote:
| This is partly the fault of Steam. They simple have a
| single "supported" boolean. It would be nice if you could
| provide a warning or "partial support" label so that people
| had these expectations when buying the game.
|
| Right now the flow for the user is 1. See store page 2. Buy
| 3. Play 4. Hit bug.
|
| This is the moment when they find out that they bought a
| game that was not in fact supported. That is super
| frustrating (and possibly legally requires a fix or a
| refund). If there was a 1.5 step of "This game offers no
| support for Linux" or "This game offers no support for any
| distribution except Ubuntu 21.04" then it is much more
| acceptable, because I accept that detail before purchasing.
| infogulch wrote:
| The most obvious solution imo is to offer a free trial
| mode. If it fails during the free trial then don't buy
| it.
| bscphil wrote:
| Steam is quite generous about refunding games, either
| because you purchased them accidentally or they didn't
| run correctly or any other reason, as long as you don't
| have more than a few hours in the game. I think that's a
| much better approach than having to implement what's
| effectively a DRM system in software, or a completely
| separate trial binary containing only part of the game.
| RussianCow wrote:
| I don't disagree that this would be beneficial, but I
| also don't think it would do anything to prevent the
| additional support burden and negative reviews in
| aggregate. If you need proof of this, see the amount of
| negative reviews on some Early Access games that are very
| up front about the lack of polish in their current state.
| atum47 wrote:
| I think you can support only debian distros like ubuntu. Then
| you would reach the common linux users that install things
| with the package manager. More advanced linux users would
| know how to get things running under gentoo or arch, I guess.
| danudey wrote:
| As others have said, if you want to distribute on Steam,
| you have to support "SteamOS and Linux", and can't just say
| "Supports SteamOS and Ubuntu" or "Partial Linux support" or
| something like that. If you support any Linux at all, Steam
| tells every Linux user that your game will work for them.
| DizzyDoo wrote:
| I suppose I can only speak for myself but I don't see that as
| an attractive option, and what you're describing is mostly
| what I did do for the game release I mentioned.
|
| If I sell on Windows (I do) and Mac (I do) then I have to
| support a certain range of OS versions and ongoing OS
| releases - even if that means (for example) I have to figure
| out how to 'notarise' a Mac executable so that a user doesn't
| have a big scary Security Warning pop-up. Not ideal, but
| fine. The challenge with Linux is that I would have to
| communicate _against_ expectations - that I would have to
| make it clear that when I 'support Linux' it looks different
| to the support for Windows or Mac. I do genuinely think that
| 99% of Linux people get this, it's just the 1% that's maybe
| less forgiving of different standards.
|
| For me, just personally and selfishly, passing the buck to
| Photon or Wine is an easier sell for my business.
| stavros wrote:
| Could you say "supports Ubuntu" instead?
| mdoms wrote:
| Steam for example has a "SteamOS + Linux" filter so
| exposing your game as Linux compatible means exposing it
| to all Linux users.
| DizzyDoo wrote:
| Not only did I say that but I also gave the specific
| Ubuntu version as well!
| stavros wrote:
| That's too bad :( As a Linux user, I love it when game
| studios support Linux and make a point to buy their games
| more often.
| frozenport wrote:
| The emails are likely bug reports?
| bscphil wrote:
| This is unfairly downvoted IMO, because I think you're
| actually hitting on a very important point. Linux users
| tend to be enthusiasts, people who love software, and
| also primarily interact with a community where the
| "developer/user" is the most important figure, the one
| whom everything is designed around.
|
| In the Linux community, at least unless a project has a
| toxic developer (there are a few), bug reports are Always
| Good. They're how we make the software WE use better on
| the systems that WE use it on. Even if a report isn't
| fully actionable (e.g. it's a problem with graphics
| drivers), the report is often helpful because the bug
| tracker is probably public and we can try to find
| workarounds, or at least flag the issue for others.
|
| For closed source commercial software, especially cases
| where a tiny number of developers are working on the
| code, bug reports are Always Bad. They represent more
| work, work that you don't want to have to do, because at
| the end of the day these are people who _already_ bought
| the game. You 've gotten as much out of them as you're
| going to get out of them. If they're more trouble than
| they're worth (someone else in this thread claimed 90% of
| bug reports out of 1% of purchases), then it's obvious
| you should just ignore them or not port your game to
| their platform at all. You'd think this attitude would be
| different for issues that affect a lot of people: a good
| bug report can help you fix widespread problems that are
| hurting your players, but actually even this is rare. See
| the story of this guy fixing a bug causing 6 minute
| startup times that affected at least thousands of people
| using reverse engineering, when the developer ignored the
| problem for years: https://nee.lv/2021/02/28/How-I-cut-
| GTA-Online-loading-times...
|
| So I think you're right, these are mostly people
| enthusiastic about a piece of computer software
| instinctively trying to collaboratively improve it for
| everyone. But because development is so limited (there's
| only one person reading bug reports and working on the
| code), those reports are experienced as frustrating
| rather than helpful. Worse still, because the software is
| commercial there may be an unspoken feeling that support
| is _owed_ for the software because the user paid for it.
| godelski wrote:
| While I agree with the spirit of what you're saying (as a
| linux user myself) the problem is that we have to
| recognize that developers have limited bandwidth. Windows
| is also generating more revenue for them, so it is going
| to take priority.
|
| Though for an indie game it probably isn't crazy to make
| the code open sourced and then put those users to work
| for you. That can really help reduce the burden. But of
| course opens you up for people stealing your software
| (which let's also be real, happens anyways).
| bscphil wrote:
| No, I agree totally with that. I think that the situation
| that exists, while unfortunate, is pretty understandable
| from all sides.
| vetinari wrote:
| I wonder - what's wrong with supporting just the Steam
| runtime and that's it? Why deferring to Photon/Wine at all?
| DizzyDoo wrote:
| Do you mean just support SteamOS? The biggest problem is,
| as a few other commenters have mentioned, there's no
| further break-down in categories other than "SteamOS +
| Linux" (and the url is .../linux). So you can't tell the
| Steam Store "I only support distro x, y and not z". I
| can't hide it for those who I am not _actually_
| supporting, Steam will advertise it to them regardless.
| edgyquant wrote:
| But Steam only really supports the latest stable Ubuntu.
| It works on most distros because package maintainers put
| a bit of work into make it but it isn't officially
| supported on them,
| RussianCow wrote:
| That doesn't stop people from making support requests,
| though, which is the entire problem OP is talking about.
| godelski wrote:
| TBF isn't this going to happen no matter what? As a linux
| user I have absolutely no problem with the OP saying "we
| don't support that distro, sorry" and closing the ticket.
| vetinari wrote:
| No, Steam runtime:
| https://github.com/ValveSoftware/steam-runtime
|
| When your game runs under Steam runtime, the real
| distribution is (almost) irrelevant - everything in your
| address space is supplied by the runtime, the things you
| get from the host system is the kernel/kernel modules and
| services you talk to via IPC (i.e. X11/Wayland,
| Pulseaudio).
|
| It solves the problem of what version of what library is
| installed (if at all, maybe user removed it as "bloat")
| on the host system. You get known set of binaries that
| you can test against / coherent SDK target like with
| Windows or Mac.
| arp242 wrote:
| I believe that GOG.com doesn't accept games that rely on
| the steam runtime; I know some games which have Linux
| ports aren't available on GOG.com because of this.
|
| Whether this matters is up to the developer. But it's a
| potential downside.
| remram wrote:
| Doesn't "X11/Wayland, Pulseaudio" include almost all the
| surface where my game's bugs will arise? It certainly
| includes the full-screen bug described by the GGGGP.
| newobj wrote:
| yes and then the vocal minority of linux users roast you on
| steam and tank your rating. chef's kiss
| sandworm101 wrote:
| My advice would be that if you cannot give full support to
| linux, at least be open about your software. The linux
| community is very good at getting things working. They can
| figure most problems out for themselves, but only if they have
| some information to work with. Toss them some documentation,
| anything, and 99% of the time they will come up with a solution
| on their own.
|
| Except DRM. Attach DRM or anti-cheat to your project, software
| that actively doesn't want to run on anything but a specific
| OS, and the linux community will turn on you.
| cortesoft wrote:
| Multiplayer games without any anti-cheat are really not much
| fun. What is the solution there for Linux?
| swebs wrote:
| Dedicated servers and active admins.
| gsich wrote:
| Last one also introduces other problems.
| x4e wrote:
| You can make a pretty good experience server side anti
| cheat and authoritative networking. Trust factor systems
| like CSGO has also work well (as long as you prevent abuse
| which is basically what went wrong with CSGOs
| implementation). You can also design your game in a way
| where cheating just isn't effective (e.g. rocket league).
|
| Ultimately the best way to have fair games is to promote
| finding players through avenues other than official
| matchmaking: friends or even just random people on
| something like discord.
| ThatPlayer wrote:
| >Ultimately the best way to have fair games is to promote
| finding players through avenues other than official
| matchmaking: friends or even just random people on
| something like discord.
|
| I think that's too high a barrier of entry. If I'm
| interested in a game, I want to jump into a game right
| away, not convince my friends to buy it, or jump into a
| random discord and talk to people to set up a game.
| RussianCow wrote:
| I imagine you could implement a majority of what
| traditional anti-cheat software gives you as a server-side
| machine learning algorithm. In my experience as a gamer,
| the vast majority of cheaters are completely obvious, so
| that would likely be as true for machines as it is for
| human players. This comes with the added benefit that your
| anti-cheat mechanisms would be much more difficult for
| cheaters to reverse engineer, since they won't have access
| to the binary. Of course, I'm not aware of any such off-
| the-shelf solutions, so this point is moot for indie
| developers who can't afford to build their own anti-cheat
| software.
|
| Disclaimer: I'm not a game dev and don't really know what
| I'm talking about.
| madpata wrote:
| Don't play multiplayer games on Linux.
| Arnavion wrote:
| It depends on the game. SNKRX is popular right now. It's
| written entirely in cross-platform Lua, uses the cross-platform
| Love2D engine which is packaged by Linux distros already, and
| is open-source on GitHub. So it was very easy to make it run on
| Linux.
|
| I just had to fix a crash because my distro's Love2D uses
| LuaJIT which only supports Lua 5.1, but the game's source
| contains a bit that requires Lua 5.4. But it was an easy patch
| (which unfortunately cannot be upstreamed because upstream
| doesn't want PRs).
|
| For other games, as long as the game provides an Ubuntu
| version, it'd work for me. I run an Ubuntu Docker container for
| Steam and other "first-party software" (binary packages
| directly from the software manufacturer as opposed to distro
| repos), because when such software says "it supports Linux" it
| almost always means "it supports Ubuntu".
| AnIdiotOnTheNet wrote:
| Yeah, I think it says a lot about desktop Linux that running
| the Windows version under Wine is often a better experience
| than the native version.
| Aeolun wrote:
| There's as many variations of linux as there are people
| running it. There's only a few authoritative versions of OSX
| and Windows. I don't think it's too susprising.
| darthrupert wrote:
| Windows is essentially the primary gaming API which has a
| pretty damned good secondary cross-platform implementation in
| Wine/Proton.
| eloisant wrote:
| It's only a better experience because developers spend all
| their efforts on the Windows build and the Linux build is
| just an afterthought.
| bee_rider wrote:
| Also because people (justifiably) don't want to distribute
| their games as source, so they can't be packaged sanely.
| badsectoracula wrote:
| It is also because on Linux developers above the kernel
| have very little concern in keeping their APIs and ABIs
| stable _and improving_ (it isn 't just keeping some
| 29839283 year old library around that never receives any
| updates, you need to keep stuff up to date - imagine, e.g.
| SDL1.2 without support for HiDPI - though sadly most of the
| time not even that keeping around happens with distros
| dropping older libs left and right). Notable exception
| being Xorg, so of course the CADT model ensured that it has
| to be abandoned in favor of Wayland which while being
| barely usable has already managed to break compatibility
| with itself.
| only_as_i_fall wrote:
| I haven't seriously tried to game on Linux in a number of
| years so this may have changed, but every time I've tried I
| get some kind of horrid tearing or stutter or low frame cap
| across a number of games that seems to be caused by
| inferior graphics drivers.
|
| If by "developers" you mean the ones working on the unity
| engine or Nvidia proprietary graphics drivers then you're
| right, but in my experience there are a number of problems
| and pitfalls further down the stack which game developers
| can't reasonably be expected to mitigate.
| vbezhenar wrote:
| I recently installed Fedora on laptop with Intel GPU, I'm
| playing Factorio and it just works, smooth and nice.
| arp242 wrote:
| I've been running Linux exclusively for years, and never
| had any problems. For the most part, everything Just
| Works(tm). My previous laptop had just integrated Intel
| graphics, which worked well enough. My current is a Ryzen
| integrated graphics, which also works well enough.
|
| The only problem I ever had was in Wasteland 2 where the
| second part of the game there was some bug with the fog
| on the world map with Intel drivers. Setting some obscure
| environment variable fixed that.
| bitwize wrote:
| The Linux build isn't an afterthought, it's deliberately
| ignored because the costs of supporting Linux vastly
| exceeds the returns from Linux gamers.
|
| If you want to sell your game, the smart money is in
| putting all your resources into the Windows version.
| listic wrote:
| What's Photon?
| jszymborski wrote:
| I believe GP is talking about Proton.
|
| It's a Linux/Windows compatibility layer from Steam. It's
| pretty great!
|
| A lot of the incompatability between Linux/Windows in my
| experience has actually been from the Anti-Cheat systems.
| Apex Legends and Intruder being examples that come to mind.
|
| https://www.protondb.com/
| godshatter wrote:
| Proton has been a game changer. Once they get the anti-
| cheat systems working (and they are making progress), linux
| will be much more of a valid choice for gaming than it has
| ever been. I used to do what gaming I couldn't do without
| on a Windows laptop, but now I do it all on my main linux
| desktop and haven't booted the laptop for months. Even some
| of the mod makers are making tools for linux now. It's a
| completely different world than it was even a few years
| ago.
|
| There are still games that have problems, but Valve and the
| wine devs and others are knocking those down one by one. So
| those 15 people that wanted to switch to linux but couldn't
| because it couldn't run their games can now do so :)
| jszymborski wrote:
| Similar experience on my end. The only time I find myself
| booting into my Windows partition is when I play a game
| with Easy Anti-Cheat.
| Aeolun wrote:
| I have just given up on games with EAC. Much better than
| constantly switching back and forth, and they're the
| exception rather than the rule now.
| gambiting wrote:
| I do remember reading an analysis by a bigger studio here
| recently who basically said the same thing - the Linux userbase
| was less than 5% of all users, but over 90% of their support
| requests were for Linux. It was just unfeasible to support long
| term, the support was costing them more money than those users
| could ever bring.
| slim wrote:
| You should give the linux version for free without support and
| encourage linux users to support you through donations
| gentleman11 wrote:
| You spend so much time worrying that you will sell enough
| copies to break even. Linux support time could be spent fixing
| a bug, marketing, polishing a feature. Plus, negative reviews
| can hurt you a lot so you can't really support Linux half
| heartedly. Needs to work as well as the other versions. The
| average serious indie game makes $14k (edit: 16k). Steam
| changed their recommendation algorithms to promote aaa and top
| sellers
| schmorptron wrote:
| > Steam changed their recommendation algorithms to promote
| aaa and top sellers
|
| This was very noticable, even as just a user. Where on the
| pages of games you liked you'd routinely discover more
| smaller titles that looked really cool under the "more like
| this" section, it's now the exact same set of games
| recommended for most of them, and it's really really
| annoying.
| spywaregorilla wrote:
| > The average serious indie game makes $14k.
|
| Source?
| DizzyDoo wrote:
| If the parent's main point is that indie game developers,
| on average, don't make tons of money, he's right:
| https://twitter.com/GreyAlien/status/1227557601786912769
| [deleted]
| gentleman11 wrote:
| Might actually be 16k. Research is from mike Rose, an indie
| publisher
|
| https://drive.google.com/file/d/1W6lZir97bUU0KdvIGNIVWG0O-_
| A...
| MeinBlutIstBlau wrote:
| For reference Eric Barone, Stardew Valley dev, he made it
| exclusively for Windows with C#. When he was approached by
| Chucklefish, they said they'd handle porting it to other OS's
| and console for a cut.
| Yuioup wrote:
| That is exactly why I have been saying for quite some time now
| that Proton has killed native Linux games. Developers would be
| crazy to publish a native Linux game right now. Sure middleware
| like Godot helps but even then it's still probably not worth
| it.
|
| Witb Proton you can publish a game and deny all reponsibily for
| Linux support. "Sorry we don't support Linux but we hear it
| runs great on Proton!"
| vngzs wrote:
| It wouldn't be unreasonable to officially target Proton
| support. Hell, I'd like that almost as much as native
| support. And we can give back to a community that is bringing
| a massive catalog of Windows software to Linux by sending our
| patches to the compatibility layer instead of just our
| proprietary source tree.
| ThatPlayer wrote:
| I think that runs into issues with anti-cheat though.
| Neither the very popular Easy Anti Cheat or even Valve's
| own Valve Anti Cheat work through Proton. While Linux
| native versions of both work fine.
| npteljes wrote:
| I mean, you could deny Linux support without Proton too. I
| think that's a separate issue.
|
| Now, _supporting_ Linux via Proton, that 's where Proton can
| kill native Linux builds. But I'm not sure how common that
| is, or will be.
| UnpossibleJim wrote:
| I hate to say it (as I type this comment on a Linux box), but
| you're almost better off pushing a 2D game in a browser if you
| want to support Linux =( The variations in Linux distros just
| get a little too varied
| forrestthewoods wrote:
| Linux just isn't worth supporting financially. At best you do
| slightly better then break even. But the opportunity cost is so
| high that time is almost always better spent making the game
| better for the 99% dor non-Linux players.
|
| If you say this publicly then angry anime avatars will yell at
| you on Twitter.
| felipemnoa wrote:
| Link to game
| zxzax wrote:
| That has nothing to do with Linux at all, you can just as
| easily get some weird requests from people trying to run your
| game at 640x480 on Windows 98 or some other strange thing like
| that.
|
| The usual response here (from any vendor, not just an
| independent game developer) is to say you only support the
| latest LTS version of Ubuntu/SteamOS with the officially
| supported drivers there and that's it. You're absolutely right
| to do that. If you want obscure distros to be able to run your
| program, you can open source it and let them deal with the
| packaging/testing/maintenance. The fact that all the OS
| packages are open source is the only reason all the random
| distros are even able to exist, so you're already making it
| difficult for them when you don't do this. No reason to dance
| around that.
| alphachloride wrote:
| "just as easily"?
| stingraycharles wrote:
| As a Linux gamer, I'd say: just make sure the Proton version
| works, focus on fixing glitches there, don't bother spending
| time on porting any code otherwise.
|
| Pretty much all games I play are through Steam's compatibility
| layer anyway, and nowadays it's a very smooth experience.
| A4ET8a8uTh0 wrote:
| I agree. The few times I can't run it via Proton ( Fallout 4,
| FF11 come to mind ) I jump on Windows VM anyway. It is
| absolutely bananas how powerful hardware is these days.
| darthrupert wrote:
| > Make sure the Proton version works
|
| On which distro and graphics hardware? ;)
| stingraycharles wrote:
| Good one. I'd say, take either Steam or Lutris or something
| like that, so that the distro is abstracted away as much as
| possible.
|
| I'm not a game dev so I don't know how much you still
| actually notice of the distro / hardware once you're
| running in Proton or Wine.
| darthrupert wrote:
| You do. You totally do.
| mothsonasloth wrote:
| Is Godot a good game engine to learn?
|
| I am looking to make an RTS 2D game on a global map, similar to
| an old game called Red Storm Rising -
| https://www.myabandonware.com/media/screenshots/r/red-storm-...
|
| Any suggestions?
|
| I am a Java/C++ dev
| eloisant wrote:
| It's good but not quite as complete as Unity, so unless you
| care about using an Open Source engine you might check Unity
| instead.
| spywaregorilla wrote:
| Given the state of multiplayer in Unity and the needs of an
| RTS game I would advise otherwise.
| jay_kyburz wrote:
| There are solid third party networking solutions for Unity.
| MichaelEstes wrote:
| It's surprisingly solid, I've made a couple weekend projects in
| it, but I see it being to Unity/Unreal what Blender is to
| Maya/Zbrush. I still wouldn't use Godot for anything I hope to
| make money from, or if your looking to gain skills that will
| land you a job at a studio. If you're new to game dev as a
| whole I'd recommend starting with Unity.
| jokethrowaway wrote:
| I mostly agree with your distinction but there is a large gap
| between Unity and Unreal: Godot is Gimp Unity is Paint.net
| Unreal is Photoshop
|
| I understand mid/big studios don't want to give away a
| percentage to Epic (over 1mln) - which translates to "learn
| unity to land a job" - but for indies unlikely to reach 1
| million in revenue, Unreal is basically free technology from
| the future.
| void_mint wrote:
| If you're a competent C++ dev it might be easier to go with
| Unreal Engine, but Godot is a much nicer user experience than
| Unity (IMO) if you're looking to use C#. The price you'll pay
| is far far less instructional content as Godot's newer/not
| "enterprise" supported.
| okamiueru wrote:
| I would like to add to this a caveat that it assumes a
| windows development platform. I would not recommend UE
| otherwise. It should also be mentioned that Godot is
| generally much simpler and easier to get something up and
| running quickly. If graphic fidelity is important, then godot
| is quite a ways behind both Unity and UE.
|
| A final note is that you can also fairly easily develop games
| for godot with C++ using gdnative, though you might be better
| off using gdscript, even though it means learning a new
| syntax.
| entelechy0 wrote:
| I'm actually dev-ing a game for Windows, Mac, and Linux
| entirely in C++ and libsdl and it has been a GREAT
| experience so far!
| gameswithgo wrote:
| Yes it is pretty good for that type of game. People enjoy it,
| there are no royalties to worry about. You can use C# which
| will be familiar to you as a Java dev.
| iwebdevfromhome wrote:
| They don't have support to export to consoles afaik but for a
| pc game it should be enough. I've tried some tutorials in the
| past with success and enjoyment but I'm in the process of
| learning gamedev myself
| extrememacaroni wrote:
| I never thought I'd say this but... there's a good course for
| Godot on Udemy. I have no idea how it ended up there.
| Operyl wrote:
| There've been companies which ported the engine over who are
| available for contracting/consulting, for what its worth:
| https://lonewolftechnology.com
|
| Also, iirc Xbox support is available via UWP in the main
| branch.
| jay_kyburz wrote:
| I spent about 3 months full time with Godot and was enjoying
| it, but ran into some bugs that undermined my trust in the
| Godot developers to the point where I had to move away.
|
| For example: if you hold a reference to object in your script,
| and the object is removed from the scene, the engine can reuse
| the address for a new object, but it will result in your script
| holding a reference to the wrong object.
|
| I believe its the object pooling system not talking to the
| scrips. This bug is a few years old and I believe it wont be
| fixed till v4.
|
| Most people don't seem to encounter it, and I worked around it
| fine buy just making sure I manually null out any references
| when they leave the scene.
|
| The real WTF which made me finally say this engine is not for
| me is that they changed the behavior so that it won't happen in
| Debug, but will still happen in Release. Different behavior for
| Debug and Release is an even bigger bug!
|
| Its such a rare and sneaky bug, and when it starts happening in
| your release you can't even debug it!
|
| Small update: I reported the issue on Github in September 2019.
| From reading the comments it sounds like the inconstant
| behavior was only in from 3.2.2 to 3.2.3 version (~6 months)
| then fixed in 3.3. However a user is reporting that the issue
| is still happening in 3.3 as recently as May this year.
| jvalencia wrote:
| I've found it to be really intuitive with a great community
| fwiw.
| EamonnMR wrote:
| If you want any pointers on RTS networking the gold standard is
| this paper:
|
| https://www.gamasutra.com/view/feature/131503/1500_archers_o...
|
| I did a toy implementation here:
| http://github.com/eamonnmr/openlockstep
|
| I haven't rebuilt that in Godot yet, but I will eventually.
| Godot's workflow is well worth using it's bespoke language.
| void_mint wrote:
| I found Godot + Mono/C# to be a great user experience
| compared to Unity.
| chamakits wrote:
| I'd say yes!
|
| I'm also a Java dev, and have dabbled in making simple "hello
| world" types examples for different game engines, and Godot was
| the first one that just clicked right away. Beyond that, I was
| able to stick to it, and was able to fully publish a game for
| the first time! (Puck Fantasy:
| https://www.lowkeyart.com/puckfantasy)
|
| Setting expectations though, if you are expecting GDScript (the
| scripting language it uses) to be as full featured as Java (or
| C++), you'll be left wanting. It took some getting used to, to
| understand the limitations of the language, and adapt
| accordingly. After moving forward from that mental block,
| things have been even smoother. And if you really want it,
| there is C#/mono support, though I recommend your first project
| to be with GDScript, since it integrates very well with the
| editor, and creates a smooth learning experience.
| bkanber wrote:
| I absolutely love Godot, and I've used them all. The only
| reason _not_ to use Godot is if you 're already entrenched in
| one of the other engines' ecosystems, like if you're working in
| a large team that already has processes around Unity's
| workflow. Some Unity features are more evolved, but if you're a
| novice game developer, these things won't matter. And IMO Godot
| is much much more intuitive to someone who is already a
| software developer.
| pengaru wrote:
| I shipped a tiny game on Steam developed entirely in GNU/Linux
| with Windows/MacOS/Linux builds all produced from within
| GNU/Linux without virtualization of other OSes.
|
| MINGW covered the Windows build, clang/osxcross for the MacOS
| build, and plain old gcc for Linux. It's all oldschool
| autotools+pkg-config dances for the cross-compilation. Plain C
| and SDL2+OpenGL under the hood, no engine.
|
| It's nice being able to do it all from my preferred GNU/Linux
| environment, and I was able to at least smoke test the windows
| builds successfully via WINE. The main shortcoming currently is
| there's no MacOS WINE-equivalent that's mature enough to run a
| graphical GPU-accelerated video game AFAIK.
| Scramblejams wrote:
| At a Steam Dev Days event I hit up a dev from a popular flight
| sim that ran on Win/Mac/Linux and asked him to rank the support
| costs for different platforms. I was surprised by his answer. He
| said:
|
| Mac users were effectively the most expensive because his team
| was (then) spending a lot of time porting their graphics code to
| Metal.
|
| Linux users were the least expensive because they tended to be
| sophisticated users who were accustomed to solving their own
| problems. He cited a particular customer who he said had a solid
| track record of finding graphical glitches in the game, then
| opening bugs against Intel GPU drivers and getting them fixed.
|
| Windows users were somewhere in between.
|
| Of course we didn't discuss the opportunity cost of supporting
| Linux (financially probably not worth it), I'm not sure how much
| his view was a function of (maybe) not having to personally
| answer support requests, or whether his experience could be
| generalized beyond his particular customer demographic, but I
| learned quite a bit from his response.
|
| ==========
|
| If I ever ship my own game I hope to support Linux not because I
| think it's the right financial move, but because I think offering
| cross-platform compatibility is just part of being a good digital
| citizen. A lot of us lived through a time where Windows was about
| the only game in town, and I don't want to ever go back there.
| (Plus there's a selfish element: I develop on Linux, so I want to
| play on Linux!)
| seaorg wrote:
| Back-button hijacking. How charming...
|
| I can't wait for webgpu and wasm to be more mature. You'll be
| able to truly write a game once and release it literally
| everywhere. Like what Java was supposed to be. I think it's going
| to be a nice little golden age for games and other software. But
| the last time I checked webgpu wasn't ready yet.
| MintPaw wrote:
| Doesn't webgpu impose a new unique shading language? That's
| gonna be even harder to support than opengl on Linux.
| vbezhenar wrote:
| I think that most developers use game engines, and game
| engines probably will implement it.
| yepthatsreality wrote:
| The pandemic made me appreciate Valve's original games push for
| Linux a few years ago because I switched and found myself
| appreciating the only-a-few-years-old games that had Linux Native
| versions in my backlog.
___________________________________________________________________
(page generated 2021-06-24 23:00 UTC)