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?
In my experience working with devs at game studios (i’m a sysadmin/infra engineer type by trade), 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. Most of the devs I have dealt with would like nothing more than to see the thing they created live on and be enjoyed by people, even if they are not personally getting paid for it 10 years down the line.
It is nearly always the executives looking to make sure no one manages to enjoy something the people that work for them created without the c-suite getting paid for it first that is the road block.
I crunched like hell in my mid 20s on a live service game that I enjoyed playing, was well loved and consistently played 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. We couldn’t even get much approved to show in a portfolio once the studio closed and the assets went to the publisher. It makes me really sad and I’m no longer in game dev / tech at large professionally for that reason. This story is not unique, this is pretty much just how the industry works and devs near-universally feel screwed over by it.
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.
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!”
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
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”?
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?
In my experience working with devs at game studios (i’m a sysadmin/infra engineer type by trade), 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. Most of the devs I have dealt with would like nothing more than to see the thing they created live on and be enjoyed by people, even if they are not personally getting paid for it 10 years down the line.
It is nearly always the executives looking to make sure no one manages to enjoy something the people that work for them created without the c-suite getting paid for it first that is the road block.
I crunched like hell in my mid 20s on a live service game that I enjoyed playing, was well loved and consistently played 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. We couldn’t even get much approved to show in a portfolio once the studio closed and the assets went to the publisher. It makes me really sad and I’m no longer in game dev / tech at large professionally for that reason. This story is not unique, this is pretty much just how the industry works and devs near-universally feel screwed over by it.
Devs geting screwed over by management (not even just game devs but all devs) is a tale older than time, sadly.
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.
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!”
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
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”?
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.