• 0 Posts
  • 10 Comments
Joined 11 months ago
cake
Cake day: August 3rd, 2023

help-circle


  • I made games primarily for Windows which we also compiled for Linux. It is mostly input/output stuff, aka hardware issues. That is, audio issues, input issues, storage issues, dependency issues. Modern game engine mostly handle the rest. It wasn’t such a big deal to fix, but most gamedev lacked experience with Linux, and most projects are already over budget and late, so fixing Linux for an extra 2-5% of sales didn’t make much sense at small scale. Proton kind off fixed all of this tho.



  • Virtually no anticheat worked on Linux just a few years ago except maybe Valve and Blizzard in-house solutions. Games that are out and already committed to a specific anticheat can’t do much but to wait, so it is not really on them. Changing the anticheat solution mid-way on a released game would piss off so many people you can’t imagine. On a brand new game though, I would agree that this should be considered.




  • The best codebase I have ever seen and collaborated on was also boring as fuck.

    • Small, immutable modules.
    • Every new features was coded by extension (the ‘o’ in S.O.L.I.D)
    • All dependencies were resolved by injection.
    • All the application life cycle was managed by configurable scopes.
    • There was absolutely no boiler plate except for the initial injectors.
    • All of the tests were brain-dead and took very minimal effort to write. Tests served both as documentation and specification for modules.
    • “Refactoring” was as simple as changing a constructor or a configuration file.
    • All the input/output of the modules were configurable streams.

    There is more to it, but basically, it was a very strict codebase, and it used a lot of opinionated libraries. Not an easy codebase to understand if you’re a newbie, but it was absolutely brain dead to maintain and extend on.

    Coding actually took very little time of our day, most of it consisted of researching the best tech or what to add next. I think the codebase was objectively strictly better than all other similar software I’ve seen and worked on. We joked A LOT when it came time to change something in the app pretending it would take weeks and many 8 pointers, then we’d casually make the change while joking about it.

    It might sound mythical and bullshity, and it wasn’t perfect, it should be said that dependency injection often come in the form of highly opinionated frameworks, but it really felt like what software development should be. It really felt like engineering, boring and predictable, every PO dreams.

    That being said, I given up trying to convince people that having life-cycle logic are over the place and fetching dependencies left and right always lead to chaos. Unfortunately I cannot really tell you guys what the software was about because I am not allowed to, but there was a lot of moving parts (hence why we decided to go with this approach). I will also reiterate that it was boring as fuck. If anything, my hot take would be that most programmers are subconsciously lying to themselves, and prefer to code whatever it is they like, instead of what the codebase need, and using whatever tool they like, instead of the tools the project and the team need. Programming like and engineer is not “fun”, programming like a cowboy and ignoring the tests is a whole lot of fun.