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.
Edit: This comes off as negative and I don’t mean it to be - A lot of companies do their own Unreal engine tweaks and I could see if a company built it up, they could have something solid and easily reworkable for future projects.
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.
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.
Edit: This comes off as negative and I don’t mean it to be - A lot of companies do their own Unreal engine tweaks and I could see if a company built it up, they could have something solid and easily reworkable for future projects.
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.