Jimmer -> RE: anyone else about read to give up?????? (5/6/2008 7:30:46 PM)
|
quote:
ORIGINAL: Erik Rutins When I say that we will be enhancing the AI after we get through with fixing the serious bugs, I'm not calling the AI a new feature. I can vouch for this being true. I started posting here the very day I found out about this game. Which just happened to be the release day (12/5, I think). From the very first time Matrix said anything at all about priorities, they (you, in most cases) plainly stated the obvious: Bugs must be fixed first. Game-stopping bugs at the top of the list. Rules mistake and other bugs below that. Only AFTER those were fixed was there any thought going to be given to the other two major areas: Interface corrections and changes AI enhancement Virtually everybody who posted in response agreed with that line of thinking. In fact, it would crazy to think otherwise (and we said so to the small number of people who disagreed). One can't upgrade or enhance until the game actually works. The one point I would debate is that I think there HAVE been both interface corrections and AI enhancements. In fact, this may very well be part of the reason for the ongoing instability. In a perfect world, I would like to see absolutely NO changes to interface or AI until the major game-stopping bugs are all gone. There are only maybe 30 of those, so it should be relatively easy to make the list. Sticking to it could be more difficult. This was the original purpose of 1.01, but some "features" crept into that release, and they may very well be part of the reason for the ongoing issues count to be going up. Write me an email some time, and I'll explain what we used to call "a release manager" when I was coding for mainframes. The principles still apply, and could be very useful to this project (and, other projects). The basic idea, though, is that a different person, completely unrelated business-wise to ANY developer, tester, etc., is "god" when it comes to release. The RM says "We're releasing this version on mm/dd/yyyy." Then, he puts a timetable together for the release cycle. There are checkpoints in the process. Once a particular checkpoint is crossed, ONLY the release manager can override the decision of what code is to be included in this release. Developers are not allowed to do ANYTHING to the code other than fixing bugs in code already included (i.e. bugs that crop up during testing). Further, if someone claims that "we absolutely have to include this", the reason why must be ascertained. If it's because of a problem elsewhere, then instead of adding the new code, the old code is removed, and saved for the next release.
|
|
|
|