Comment

Comment on The 'Stop Killing Games' initiative is close to its final deadline, and after that, its leader is understandably done: 'Either the frog hops out of the pot, or it's dead'

RedFrank24@lemmy.world ⁨9⁩ ⁨months⁩ ago

Every time I see the argument that “Oooh no you can’t release server code, there’s proprietary code there!”, I question my software development skills.

You mean to tell me when you have licensed code, you don’t wrap it with your own interfaces? I was always under the impression that it was best practice to never rely on one single concrete implementation of your interface, hence the Dependency Inversion Principle.

If you have a proprietary library you use for determining the positioning of players on a map, you wouldn’t be directly instantiating BinglyBooCharacterPositionWhatsit, you’d be using ICharacterPositioner and then using BinglyBooCharacterPositionWhatsit as the implementation of that interface, surely?

source

Sort:hotnew top

thesmokingman@programming.dev ⁨9⁩ ⁨months⁩ ago
I don’t follow this argument. In this context, proprietary code is work product that has value to its owner. Often large swathes of said work product is reused across games so the theory is that releasing the work product means your competitors can make your work product. I do not understand how wrapping someone else’s work product in your own work product doesn’t require them to first release their work product.

Note I don’t necessarily buy the company mindset on proprietary code; I explained here because I don’t understand where you’re coming from.

source
- RedFrank24@lemmy.world ⁨9⁩ ⁨months⁩ ago
  I mean if you are required to release a server dev kit, or at least make best efforts to release one, you can release what code you have and go “Here are the interfaces, but I can’t legally release this code because I don’t own it, so someone else is going to have to create an alternative”.
  
  It’s about making it easier for other devs to make up for the gaps, rather than going “Nope! Proprietary code, can’t do anything!”
  
  source
theneverfox@pawb.social ⁨9⁩ ⁨months⁩ ago
Abstraction is a trade off. You don’t want to build interface layers between everything… It’s a pain in the ass, and if there’s a 1-1 relationship between parts of a system then you’re basically putting in a minimum cost to modify that area in any way. So if you do it, it’ll probably be once you’ve locked down the design pretty well

Game development is pretty different than normal development too. You have a lot of one off and lose ends based on creative decisions… You aren’t building up on top of your system, you’re building out

And frankly, it leads to a mix of mind blowingly good code and a lot of terrible code

So no, I don’t think it’s that easy. I think it’s also a bullshit argument, and they should release the “proprietary” code when they finish supporting the game, or put in the time to make the interfaces

source
Justdaveisfine@midwest.social ⁨9⁩ ⁨months⁩ ago
I’m not a smart nor good developer so maybe I’m looking at this wrong, but if you’re a game Dev and you’re using Unreal Engine or Unity, aren’t you already bound to whatever license they have?

I believe if you’re following say Unreal’s structure, you’re using their server/client netcode, and while you can release whatever you’ve made you can’t use or share any of Epic’s code. That would still require users to agree to Epic’s EULA to get the full engine to compile your server setup.

Add in server handling for VoIP, audio middleware like FMOD, proprietary stuff like Xbox/PS crossplay, Steam’s SDK, etc and I feel like that’s a tangled web.

I’m also very tired and am probably not fully registering here.

source
- RedFrank24@lemmy.world ⁨9⁩ ⁨months⁩ ago
  I’ve never worked with Unreal’s server setup, but I imagine it doesn’t absolutely require to use their code, right? You can still make an Unreal game on the client and use something else for your server, meaning there must be some sort of common interface between them.
  
  The point is yes, there is going to be code you can’t legally release, libraries you can’t use, but you can release what code you can, and then leave the interfaces for code you can’t, leaving hobbyist devs to pick up the slack. You can even make servers from scratch that way, as with stuff like AzerothCore, where all of the code was figured out from scratch based on packets from client to server and studying hex code for hours.
  
  Even if you strip out the code you can’t legally release, that’s a hell of a boost to development that you wouldn’t otherwise get.
  
  source
  - Justdaveisfine@midwest.social ⁨9⁩ ⁨months⁩ ago
    Taking a cursory glance through the solutions that already exist for this (which are largely standalone MMO style servers):
    
    You lose out on many network troubleshooting tools unreal has built-in, as well as some of Unreal’s play-in-editor testing tools. Its also common to add roughly 1.25-2x netcode development time as you’re going to be coding things in on the Unreal client side as well as the server side.
    
    I can see why this is feasible but rare to see in the wild. I think anything you pitch to an exec with a note that it may add 6 months to a year of extra development time (and QA time) is going to cause people to start swinging.
    
    source
    RedFrank24@lemmy.world ⁨9⁩ ⁨months⁩ ago
    Ideally though, if this became law, you would be accounting for the fact you might have to swap out the server implementation into your initial development of the game.
    
    Also, some of those tools you might not need for production client code. Yes it’s gonna be a pain in the arse to develop server code without those tools, but not necessarily impossible. You could release server code with those tools stripped out, or able to be configured to work with those tools if someone else has the license for them.
    
    In essence, you could modify the client to include configuration points that can point to specific servers, and then release documentation to say “Hey, this is what tool was originally used, these are the kinds of packets the client is sending (and whether they are expecting a response), and these are the kinds of packets the server is sending to the clients”. You then leave the actual server development to whoever wants to build one. That is, effectively, how private MMO servers are made, but regardless of the type of game, you’re still sending UDP packets to a server and receiving UDP packets from the server. You just need to know the purpose of those packets.
    
    source
    -> View More Comments
catloaf@lemm.ee ⁨9⁩ ⁨months⁩ ago
Most devs are shit at their jobs.

Not that this is exclusive to devs. Most people in general are shit at their jobs.

source
NuXCOM_90Percent@lemmy.zip ⁨9⁩ ⁨months⁩ ago
Understand that significant percentages of any game are made under crunch conditions. And there is no real “okay, let’s go back and reduce our technical debt” for the majority of games.

So all those best software practices go out the window when you have slept in your cube for the past four nights and your well rested boss is screaming at you wondering why the cape physics still look so shit.

But also… how does that change anything? “Here is our end of life offline mode. We reference these packages you will never have access to and that have no open source equivalent because they are so specific to the proprietary way this auth system works”?

source
flop_leash_973@lemmy.world ⁨9⁩ ⁨months⁩ ago
In my experience working with devs at game studios, it is rarely them that is so against open sourcing code, or giving fans of the game the tools needed to keep it going on their own once the devs move on.

It is nearly always the executives looking to make sure no one manages to enjoy something the people that work for them created without them getting paid for it.

source
- eupraxia@lemmy.blahaj.zone ⁨9⁩ ⁨months⁩ ago
  I crunched like hell in my mid 20s on a live service game that I enjoyed playing, was well loved by a few fans, and had a few unique ideas in its niche. I gave up a lot of life for that game to see the light of day, under extremely tight timelines and wavering support from a flakey publisher.
  
  It lasted less than a year in release because of a few mistakes in early access and it inhabited a saturated market that seems near impossible to penetrate now. The console ports that caused the worst months of the crunch never even saw a release.
  
  Me and the rest of the devs would love to just play the game again, but the game’s kinda just rotting somewhere in storage of a publisher that long ago tried to pivot toward NFT/metaverse bullshit, to predictable results. Outside of a few early playtest builds a few people have (and definitely aren’t supposed to) we have basically no way of playing it ourselves, much less letting others play it. It makes me really sad and I’m very happy to no longer be in tech professionally for that reason.
  
  source
  - ipkpjersi@lemmy.ml ⁨9⁩ ⁨months⁩ ago
    Devs geting screwed over by management (not even just game devs but all devs) is a tale older than time, sadly.
    
    source
vala@lemmy.world ⁨9⁩ ⁨months⁩ ago
Idk if most software developers know this is what they should be doing and ignore it completely or if they just don’t know.

There are so, so many reasons to do this.

But I don’t think this really happens very often in the real world because it’s not the shortest line from A to B.

source