Oh hell! Reinforcements.
Hiya LT, welcome to the argument... relax and have fun.
Anyway, the rollback isn't bad provided:
1. The bug you've got is widespread and obvious.
2. The guys at Epic aren't asleep at the switch.
#2 there is a dicey proposition, but #1 isn't that uncommon. Plenty of times you'll see a post go up in INA troubleshooting about somebody who's got one of those oddball bugs from a patch that most people don't have. Sometimes this is a case of somebody who needs to update their drivers, or who have an alternative firewall that's not treating them right... sometimes it's not.
The result, currently, is that you have a small minority (5% or less) of players running a couple of patches behind. And as things stand, that causes 0 issues. It's best for them and it's best for the game at large.
If everybody was forced to patch whenever Epic decided it was ready, you'd have that 5% minority just outright screwed, with no recourse but to desperately try to get the issue recognized... which may or may not happen. And if it does get recognized, what do you do? Roll back the whole thing which worked for the other 95%? Seems a bit unreasonable...
As it stands, those with minority bugs can report the bug and then rollback themselves and still enjoy the game while Epic (hopefully) fixes at their leisure.
Then, you're still ignoring two other admittedly quirky but nonetheless crucial elements of the game: alternate OSes and mods.
Mac users are not an insignificant portion of the UT playing community, but the big mover here is Linux. Linux clients probably number slightly less than Mac clients (to take a guess) but the number of servers running Linux is huge.
The way things stand, Epic has farmed out the OSX/ Linux development to one guy, Ryan Gordon. This is economical for Epic and still manages to work for alternate OS users because 1. it's still OK if the patches for those OSes are a little late and 2. Mr. Gordon is kickass enough not to let things go too far behind.
Consequently, any autopatching system that required current versions from everybody would either have a lot of "latency" built into it because of crossplatform issues or else Epic would have to expand at not inconsiderable cost just in order to get all OSes patched concurrently. And there's still the issue of "it works on one but not on the other."
As for the mods, well, those things are running an almost completely altered set of code on top of whatever it is that may or may not be getting patched. Under the current system the mod teams get plenty of notice as to what's getting changed and can decide for themselves if a patch needs to be skipped (which decision may or may not be in line with the good of the rest of the playing community).
And then there's the issue of beta testing. Epic's current formula is to sign up a certain amount of beta testers and allow the patch to be tested in the general population. This works well for the beta testers inasmuch as, assuming no major foul- ups, they can continue playing the game they paid for on whatever server they choose. It works well for Epic in that the patch gets tested on a wide variety of hardware/ software configs.
If there were autopatch with no backward- compatability, beta tests would have to be segregated from the general population and would be much more limited in the number of server configs they were tested on. Which is fine for a MMORPG since the server population is fixed and controlled... not so for UT, where end users run the servers.
What you've got to remember, Kafros, is that when you do this on your job you're dealing with a much cleaner environment. All the hardware is probably extremely similar if not identical, in all likelihood you've got one OS to deal with, and users are paid to work with what you give them and are furthermore almost definitely banned from adding or deleting software/ hardware.
With UT it's all the reverse. There's no telling what's running on any of these machines (sales statistics and questionnaires can give you a rough idea, but nothing terribly accurate), there are 3 OSes currently in the mix with consoles on the way, and the end- user is paying you... not the other way around.
Further, if something goes wrong on your job it's reasonably obvious... dept. X suddenly isn't getting squat done. If something goes wrong with a game, you might have 200 out of (at peak times) 6 or 7 thousand players not show up on the servers one day. And what to make of that? It's completely normal. Beyond that you've got ranting bug reports from 15 year- olds (and those who emulate them) to go on.
In short, an in- house commercial setup (which even sort of extends to the MMORPG and some RTS games) is built for that kind of efficiency and a game like UT isn't.
UT is designed to be as different as possible from one place to the next. That's both it's greatest strenght and most damning weakness, I'll admit, and it's also a big part of the charm. It's the DIY nature of the game that helps endear people to it, and the current system of patching reflects that by handling all that hard- to- wrangle diversity in the simplest, most convenient and above all flexible way possible. Trying to impose uniformity on that from one angle and one angle alone would in all likelihood make a considerable hash of things, particularly if you went for the kinds of sweeping changes you referred to earlier.
And as to the argument that "other games are doing it," take a look at the top 15 games on
csports.net's stats page. Among those top 15, you'll find two types of FPS game: the type that uses Steam, and the type that doesn't autopatch.
. To answer, currently I drive a truck and also do some light drone work with "distributed" software (as a user, not a developer). ![Kirin[SC]](/data/avatars/s/21/21081.jpg?1424422883){kind=avatar}
