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?
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
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’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.
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. Technically AzerothCore was just building on top of MaNGOS but that was created using packets.
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.
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?
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
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.
Most devs are shit at their jobs.
Not that this is exclusive to devs. Most people in general are shit at their jobs.
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.
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. Technically AzerothCore was just building on top of MaNGOS but that was created using packets.
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.
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.