Comment by perching_aix
6 days ago
> But the server program has to be released when the official servers are shut down. Which means this possibility has to be prepared for throughout development.
... which is why it doesn't pass my smell test.
Say you're working on either a monolithic game server codebase, or just a microservice that's a part of a larger service mesh fulfilling that role. Are you writing any tests? You probably (hopefully) do. So where's that code gonna run the first time before it's even pushed up to version control? Locally. So some extents of it definitely have to run locally, or if you have good test coverage, all of it.
But okay, let's go a layer further. Say you're trying to go into production with this. As the saying goes, everyone has a production environment, but the lucky folks "even" have others. This sarcastically implies that you need to be able to deploy your solution into multiple environments. And you don't want to be doing this manually, because then e.g. you have no CI/CD, and thus no automated testing on code push. That's not even considering multi-geo stuff, because for multiplayer games I imagine latency matters, so you really want to deploy either to the edge or close to it, and will definitely want to be all around the world, at least in a few key places.
So you can test locally, and can deploy automatically. Tell me, what is the hold up then? It would take me approximately one entire minute to give you the binaries for anything I ever touch, because if I couldn't do that, the automation wouldn't be able to do so either. At some point, the bullshit has to end, and that's at operations. Not much docs to write either: if your stuff does anything super super custom, you're doing something very wrong. And respectfully, if the aforementioned do not apply to you, you shouldn't be operating any online service at scale in production for anyone in 2025.
Really the only technical wrenches you can throw into this that I can think of are licensing and dependencies. Neither of these are reasonable spots to be in from an economical or a technical standpoint. Like what, you can't mock other services? How are you testing your stuff then? Can't change suppliers / providers? How is that reasonable from a business agility standpoint?
So clearly if there is a salient technical rationale for this, it's going to have to be a very sharp departure from anything I've ever experienced in non-gaming enterprise, or my common sense.
Regarding all the other points (and this will read dismissive because I've already rambled on way too long and I'm trying to keep it short, I genuinely don't mean it like that):
- if you're writing an MMORPG as a small up-and-coming indie, you're definitely going bankrupt
- if you're writing an MMORPG, I'm pretty sure you'll have more than just one or two servers running, or there's nothing massive about that multiplayer online role playing game after all
- it does not require you to continually release anything
- it does not request you to release documentation (what is there to "document" btw? I'm certainly not imagining too much)
- it does not request you to support different systems
- it does not request you to release anything before EOS, thus, security concerns for the official client are null and void - and even if it wasn't (e.g. sequels), security by obscurity is not a reasonable security story anyways
- the dangerous parts of the reverse engineering efforts still routinely happen without access to server binaries anyways (see all COD games and their players getting hacked to pieces right as we type away)
- possibly liable is not liable, and I trust you're not a lawyer, just like I'm not
- it's just a client-server setup like any other - remember, other environments must be possible to connect to as well, if nothing else then for testing
All of this is completely ignoring how we had dedicated servers and competition events with private setups since forever.
I legitimately cannot imagine that you can cock up an online service architecture and codebase bad enough, that a team of devs and devops/SREs/ops, or even just a few of those dudes, couldn't get something mostly operational out the door in a few day(!) hackathon at most. Even without planning for all this. And how this would skyrocket the costs especially mystifies me. Surely asset development, staffing, operational costs and marketing are the cost drivers here? How would you surpass ALL or even ANY of that? Just doesn't make sense!
No comments yet
Contribute on Hacker News ↗