Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
I've decided against an Android phone or tablet several times based on the fragmentation and confusion of the ecosystem. The feature confusion barrier is too difficult to surmount. Will this play all the iOS games that I enjoy? Whose app store do I use? Is a storefront for that available on the device? Will I have to rebuy all my apps (ans: yep). Am I going to feel like the device is obsolete three months after I buy it? Will it run the right OS version? Am I getting locked into one app store? Am I going to have to root it to feel like I'm getting everything I paid for? If so, how easy is that to do? Is it the pain in the ass that maintaining a jailbroken iphone is?
All that, plus rebuying all my apps roots my feet to the ground of Apple's walled garden. I just don't have to worry about any of that if I just stick with iOS. I'd love to broaden my view of the mobile space with an Android device, maybe with a rooted Nook Color (I love my Nook B&W), but it's a headache, for all the reasons above, and I shouldn't have to buy into a headache.
HTML and other web-related specs have never been truly written in stone, as the author seems to want. XMLHttpRequest, and innerHTML were functionalities written outside the spec and then later added to their respective spec documents. How many of us, as developers, have had a Business Requirements documenter interrupt our day to ask for details on how the system currently works so that they can go back and write the Requirements Specification docs to match? This back-asswards process is so common in my experience that I have come to empathize with those who believe that Req. Specs are essentially useless. They're a form of procedural ass-covering by businesspeople who want to be able to point at a document when something goes wrong.
The idea that the HTML spec from the WHATWG is functioning in the same manner is neither unexpected nor worrisome to me. I'm glad that they're acknowledging that it's code shippers who are truly defining the HTML world for us developers on a day-to-day basis. We don't worry about "what version of HTML does your site support", but instead worry about "which functionality does your site support"?
The real shift that's occurred in the code is that we're now (if we're doing as we're supposed to be doing) testing for client functionality instead of browser version, and certainly not for HTML version. Your site either supports the <video> tag or it doesn't. It either supports WebWorkers or it doesn't.
While I think it's an egregious error to omit Microsoft from the WHATWG, as they, more than anyone, could use some ears to the ground for following real-world standards, I think that having industry leaders all around a table, discussing a technology direction that will provide the next steps for HTML is a good thing.
Really, who else would the author have take over? It's implicit in his voiced distrust of private companies that he'd rather hand this off to some kind of governmental agency, or at least give it some kind of oversight powers. As to that: I don't want to give the future of HTML and the web to the same people who came up with the US Income Tax system--the poster-child for bureaucratic gobbledygook.
Team Fortress from Valve is what I see as the gold standard for DLC. The game updates significantly and frequently through Steam, adding features and fun without an iota of effort (or money!) on the part of the player. The Orange Box was the first digital game I bought, and it's one of the few that I've played regularly for over a year.
Valve's made me into a loyal customer with that single purchase. How could a property like Call of Duty benefit if they were to do something similar? Would it torpedo their scattergun title release business plan, or would more people (like me) actually consider buying another one if they knew the game would age like whiskey?
That's why people with decisive creative drive are so important, regardless of the type of software project you're working on.
I think you're overlooking the fact that preorders are a huge segment of the user base. We, the preorderers, have no ability to weigh bugginess into our purchasing decision. I suppose everyone could stop preordering, but the chances of that are extremely slim. Think of any AAA title, its fans, and trying to convince one of them to not preorder. Riiiight.
I've worked in software development for too many years to be so intolerant of game defects. There are always realities that impinge a developer's ability to deliver a bug-free product. Some moronic business person could look at a spreadsheet and declare a release date, regardless of the state of the product. That happens all too frequently. It hurts the end product, how its received by the public, and the developer's and publisher's reputations. However, it does provide that all-important first-month income. Sometimes the developers work their asses off, know the product isn't ready for release, and have to watch like a father sending his 18-year-old off to war as the product is thrown to the wolves by management.
Is this bad? Yeah. Should this happen with a responsible developer and publisher? No.
Is there a solution? It depends on the product. When you're in late-stage development and your product is bug-ridden (assuming your Q.A. department is skilled enough to find the bugs!), you can either: delay your release date, or keep your current date and shrink the scope of your product so that you can finish it in time.
I'm sure the dev team from F:NV had that discussion at some point. I'm assuming their Q.A. department (of ~300 people, I've heard), recognized the product was shaky. F:NV would have been very difficult to scope back, I think. The nature of sandbox games with such broad and varied quest trees means you can put yourself in a position where a major branch may have a serious problem early on, and you have to excise the entire thing, cutting out huge swaths of content. I think that would have cut to the core of what makes the Fallout games so great. Some of the defects I've heard with F:NV have sounded like engine issues, though, which should have put them as priority one, and affected the whole game. *shrug* Who knows what happened there. I wonder if Obsidian might have had some limitations placed on how they could mess with the core engine, even if it was to fix defects.
The other choice, to delay release, was probably not in the cards for them. Release in October means being under the Xmas tree for a lot of folks. Delay that a month, and you position yourself poorly against all the other AAA titles. It's also easy for that month to turn into two, or three. Business doesn't like to hear things like that, so they likely got stuck with a firm release date.
I'd love to hear a post-mortem from the developers.
In all, I'm enjoying the game thoroughly. I just updated my nvidia drivers, so we'll see if that takes care of the frame rate drop in places like Gamorrah and The Thorn.
I wasn't implying that to make scientific discoveries, you can't believe in God. What I am saying is that you have to be willing to push back the boundaries of the divine domain.
If, instead, you are rigid in your belief that the immutable secrets of the universe were figured out by a bunch of guys who had to be conquered by the Romans in order to get running water, you might be happier in a monastery than in a lab.