Patch Every Other Week?
AaronEl
Join Date: 2009-11-01 Member: 69214Members
Join Date: 2009-11-01 Member: 69214Members
Who else is in favor of a patch every third week? Possibly month? Maybe it would take too long to get feedback every month but it's nigh time we saw a glimpse of the almighty Onos or at least another map or two. For this game's potential to emerge we need to see a lot of maps.
Comments
Putting out a patch takes time, hell just releasing a new map version for me takes several hours, it's not efficient to do it constantly.
Patch when you have something that needs testing, if that's every week or two then lovely, if not, wait until you have something.
this
Just release a patch either when it is necessary (i.e. Soundbug) or there are really big changes (i.e. Onos/Heavy, ARC, the one magical performance improoving patch, new map, <b>nerfed shotgun</b>)
If it takes you only one week it's fine, but if you need 3-4 weeks it's finde too.
Actually i'd say its more than double, assuming they spend 1 day for testing, thats 9 days for "work" on the patch, compared to 1-4. Doesnt take into account the push, or energy that having a release date imminent though, but that can be a little draining also every week.
Schedules are good for getting stuff done, but if your schedule starts to negatively impact efficiency, it needs to change.
Releasing patches regularly is good for PR, but releasing them when they are helpful and convenient to the dev team gets the game done faster, and a finished game is far better for PR than constant patching.
It is professional, and it allows you to judge your progress over time.
What you are proposing is that you <b>wait</b> for half-finished tasks to complete before patching. Meanwhile sending out a patch with all the currently-finished tasks allows more common and consistent progress, and maintains interest, but barely affects the half-finished tasks whatsoever - it is not inefficient. It is also more partial to pleasant surprises (because of lower expectations) because chances are most fortnights, changes will be relatively minimal, but those frequent patches may sometimes contain larger changes. Whereas with waiting for 'milestone' tasks to complete before patching, it's always just a waiting game for expected large changes, and expectations will be high - more prone to disappointment.
Post-v1.0 though, patches <b>should</b> be large and sporadic, or small for tweaks, or quick fixes following a large patch.
don't worry, this will happen anyway ;)
Its not really a waste of time. We are basically substituting for the internal playtesters of large game studios. The problem is expectations. People preorder the game thinking it will be mostly finished and lag-free (like the SC2 'beta' or other major game 'beta) and instead its not feature complete and still quite buggy.
Public play testers may be able to find bugs and balance issues but they are not the same. They are your target audience and you need to impress them, keep them happy "and maintains interest" as Harimau said or you risk losing them. This all takes time away from real development.
Some public play testers understand that NS2 is still in an early state of development and that means the game will not necessarily be a pleasure to play but you only need to look into any thread in this forum to find that many if not most do not and this can have consequences for future sales.
It is professional, and it allows you to judge your progress over time.
What you are proposing is that you <b>wait</b> for half-finished tasks to complete before patching. Meanwhile sending out a patch with all the currently-finished tasks allows more common and consistent progress, and maintains interest, but barely affects the half-finished tasks whatsoever - it is not inefficient. It is also more partial to pleasant surprises (because of lower expectations) because chances are most fortnights, changes will be relatively minimal, but those frequent patches may sometimes contain larger changes. Whereas with waiting for 'milestone' tasks to complete before patching, it's always just a waiting game for expected large changes, and expectations will be high - more prone to disappointment.
Post-v1.0 though, patches <b>should</b> be large and sporadic, or small for tweaks, or quick fixes following a large patch.<!--QuoteEnd--></div><!--QuoteEEnd-->
The point of having an open test is to get feedback on things, be it to test if they work on everyone's machine, or to see if what you added is intuitive and people understand it, or in some cases to see if your entire design in general works.
There isn't any point releasing a patch if it doesn't fulfil those criteria, I certainly wouldn't spend time packaging together a map to meet a regular version release schedule, I would wait until I have all of the stuff I know needs doing done, then I'd release it with those changes and ask people to test the things I added, and tell me if they have any further problems.
Packaging and releasing a version when I'm halfway through the changes doesn't help in the slightest, even if I did say half the changes completely and release it it's still pointless, because if there's still stuff I know is wrong and needs fixing, when I release it people are just going to continue to tell me that it's broken and needs fixing, and I'm not going to get good feedback on the stuff I did fix.
Obviously for something as large as NS2 you are going to have to do that somewhat, but if they work on say, a bunch of different things which improve the lag problems, and maybe put a new building in, then release a patch, people can say 'yeah the lag is better and the building works nicely.' If they release a patch that says 'well the building is modelled, textured and coded but we haven't done the collision mesh yet and the animations aren't complete so we can't put it in yet and also the lag is still kinda bad because we still have a bunch of other code changes to do on top of the hundred or so we made this week but here's a patch anyway because it's tuesday' that's not very helpful. People are going to give the same feedback as before, and you wasted half a day, and you're going to have to spend another half a day later releasing the <i>actual</i> patch.
Different tasks are going to take different amounts of time to complete, and it is much easier to test a feature (and much easier to work on features) if you test and release when a major feature is complete. Otherwise you're going to get bits of features half done, or you're going to have to deal with the headache of making up a release version a few days before the deadline and holding it somewhere until release date, and if you're going to do that just release it early. Regular patch schedules simply do not make sense, because you can't break game development down into helpful two or three week chunks, unless you want to waste an awful lot of time stretching out a project over a week when it really doesn't take that long.
Patch as is helpful to development, not at regular intervals for the sake of doing it at regular intervals.
Might as well extend things until this area has been cleaned up, and if you have the time and resources to go back to weekly updates then feel free to do so.
Public play testers may be able to find bugs and balance issues but they are not the same. They are your target audience and you need to impress them, keep them happy "and maintains interest" as Harimau said or you risk losing them. This all takes time away from real development.
Some public play testers understand that NS2 is still in an early state of development and that means the game will not necessarily be a pleasure to play but you only need to look into any thread in this forum to find that many if not most do not and this can have consequences for future sales.<!--QuoteEnd--></div><!--QuoteEEnd-->
Fair enough. Its a delicate balance that I think UWE upset a bit when they declared NS2 a beta where, by the most common definition I've seen, the game is still really just an alpha. As long as they release NS2 within a reasonable amount of time, I think most players will forget how upset they were when they first started playing the alpha/beta. Essentially, we all preordered based on the promise that UWE would deliver an amazing game called NS2, rather than a finished product. I think they should have made that clearer for people who preordered the alpha/beta.
There isn't any point releasing a patch if it doesn't fulfil those criteria, I certainly wouldn't spend time packaging together a map to meet a regular version release schedule, I would wait until I have all of the stuff I know needs doing done, then I'd release it with those changes and ask people to test the things I added, and tell me if they have any further problems.
Packaging and releasing a version when I'm halfway through the changes doesn't help in the slightest, even if I did say half the changes completely and release it it's still pointless, because if there's still stuff I know is wrong and needs fixing, when I release it people are just going to continue to tell me that it's broken and needs fixing, and I'm not going to get good feedback on the stuff I did fix.
Obviously for something as large as NS2 you are going to have to do that somewhat, but if they work on say, a bunch of different things which improve the lag problems, and maybe put a new building in, then release a patch, people can say 'yeah the lag is better and the building works nicely.' If they release a patch that says 'well the building is modelled, textured and coded but we haven't done the collision mesh yet and the animations aren't complete so we can't put it in yet and also the lag is still kinda bad because we still have a bunch of other code changes to do on top of the hundred or so we made this week but here's a patch anyway because it's tuesday' that's not very helpful. People are going to give the same feedback as before, and you wasted half a day, and you're going to have to spend another half a day later releasing the <i>actual</i> patch.
Different tasks are going to take different amounts of time to complete, and it is much easier to test a feature (and much easier to work on features) if you test and release when a major feature is complete. Otherwise you're going to get bits of features half done, or you're going to have to deal with the headache of making up a release version a few days before the deadline and holding it somewhere until release date, and if you're going to do that just release it early. Regular patch schedules simply do not make sense, because you can't break game development down into helpful two or three week chunks, unless you want to waste an awful lot of time stretching out a project over a week when it really doesn't take that long.
Patch as is helpful to development, not at regular intervals for the sake of doing it at regular intervals.<!--QuoteEnd--></div><!--QuoteEEnd-->
And with a major change patch, likely you'll have a whole tonne of smaller changes. And if issues arise, how will you be able to track which of the myriad of small changes caused that issue? Your reasoning is flawed.
I don't understand how you can say 'patch as is helpful to development'. The developers have their own internal builds - they are always up to date, even if their build has only got half-finished tasks - they will always be able to continue development; only part of that makes it to the public tester build - how, then, does this limit development whatsoever? It doesn't, you're making it up.
A schedule is important because you can chop up your time each fortnight. The first small portion of the fortnight will be spent fixing what broke in the latest patch, most of the rest will be spent on new or unfinished tasks, then there will be a content lock, and there'll be testing and refining the new finished tasks (or if too broken, put off til the next patch), then packaging the patch.
Such a schedule allows you to feel good about the myriad of small tasks you accomplish, and allows you to gauge your progress from fortnight to fortnight. A consistent, frequent patch schedule also helps to maintain player interest. Those who complain about lag are just whiners who complain about the same things hundreds of people before them have complained about, because they are incapable of reading or basic research.
Ideally, you wouldn't release patches at all, because it saves a lot of headache. Patches are annoying to put together and essentially a waste of time, you don't get anything from doing it, unless you actually need them for something.
You do need to patch for some things, somtimes you put a feature in and you need to mass test it, so you stick it in a patch, release it, and see what people say about it. At these times it is helpful to patch and you should do it, but other times no, you shouldn't, because you are expending precious time in order to do something that doesn't benefit you.
So, patch as is helpful to development, if you need something mass testing, put it in a patch, if you don't, get on with useful stuff.
I don't feel any sort of accomplishment by releasing a new version of something, I feel the accomplishment (such as it is) when I run it on MY machine and see what it looks like, and if it looks good I am pleased. Releasing things doesn't help me gauge my progress either, because again, I know what I need to do and when by, and I can run it on my machine and see if it is done at the time it should be, but this isn't split up into weeks, it's split up into jobs, I know how long each job is supposed to take and what it's supposed to look like at the end, and usually each of the smaller jobs makes up a bigger job, and the big ones take a few days to a few weeks, depending on what they are.
Translate this into a games company, they will have an internal schedule of tasks, which will probably be very irregular for the most part because different tasks take different amounts of time, and in games especially it can be difficult to predict how long something will take, so some things will overrun and some things will go faster than expected. This is what you use to judge progress, progress occurs without patching, it occurs faster without patching because people have more time to work on things other than the patch, which will all need doing again for the next patch. It's been said that a patch takes half a day or so to build, that's half a day every two weeks, nearly 1/20th of their possible time spent on patches, which translates to that's a lot of wasted time. Nearly three work weeks of time a year in fact.
Say I have a small building to make, it might take a day, say I have a really big building to make, it might take a week, I might have some complex scripted sequences to set up, those don't really seem like much but are important and time consuming, so they can take a very long time for little payoff. Ultimately it's really only me who can judge how good my progress is, and when it is helpful to patch the thing I'm working on. The one thing I can say with absolute certainty is that it is most definitely not helpful to patch on a bi-weekly schedule for the sake of it. Unless you have a separate set of people you are releasing it to who are themselves running on a strict schedule (and UWE doesn't, because these are public patches, and the public doesn't have a schedule) The ONLY reason to patch regularly is to pander to impatient people, who will still complain and whine about the results anyway, so why waste the effort?
Completely false, as I have already mentioned a great number of reasons. At best, this is your opinion. At worst, this is a lie.