As far as I'm concerned the portals are fine for the stage the game is at, they work and they don't send you too far from your base and there's a workaround.
Say that to the guy who ended up over 5 chunks away separated by a huge mountain range *sob*.
However, i am having fun with them for now. I have a feeling they'll be a lot less random eventually. For now the work around would require me to dig far to much, as well as possibly finding a way to empty a lake of lava in hell.... not going to happen any time soon.
Rollback Post to RevisionRollBack
"No one shall be able to drive us from the wonderland that ZUN created for us."
-ChaosAngel092
Chiming in from the career programmer's corner with my 2c.
Ignore a bug for too long and it becomes a bear. Some bugs are pretty benign, often when the programmer has forgotten to account for an uncommon occurrence, and fixing it is as simple as finding where it is and adding a few lines of code to handle the particular situation. Sometimes it's more than a few lines and it's rare enough or a pain in the butt enough to just leave it, knowing the reason why it happens and what it will take to fix it. Notch sometimes tweets about these. The bugs that attract the most attention on these forums are not like these, since they break major game-play elements they would be fixed already if they were simple to fix. It's reasonable to conclude that fixing them is not a matter of a few extra lines of code, that it's going to require changes to other parts internally.
The trouble is, and as attested to by other programmers in the thread this happens all the time, changing little bits across the codebase almost inevitably precipitates the need to refactor - to restructure the program so that all the little bits of code recently added are in their correct places - what "correct" means depends on the development model being used, but a universal truth is that unless a project is very carefully specified in advance there is going to be refactoring at some stage and you just need to incorporate it into your time estimates. There's a whole sub-field of computer science which tries to quantify these factors, called software metrics. It's very boring. Most (certainly not all!) programmers hate refactoring because it's extra effort for little to no show-off value, and it usually snowballs as changing the structure of one part necessitates a change in structure for another part. The consequences are often quite unpredictable. Not completely unpredictable, just difficult if you don't come from a metrics background.
The idea that software development happens in two relatively separate steps of adding content then fixing bugs is laughable, the idea of it working like that for minecraft is hysterical. The waterfall model is similar, but even notch has openly mocked that. By not addressing every user-facing issue as it comes, a developer can never know if it's going to reveal a major oversight, a crack in the foundations which might otherwise be built on top of and require major changes all the way up if the foundations are modified.
I'm not sure if any of the current bugs in minecraft are going to require extensive refactoring to fix properly, but neither do you. Notch is a good programmer working on an excellent game but it takes more than that to avoid such chronic structural problems on a large project - this is why big software firms hire metrics guys or programmers experienced enough to have an intuitive sense for it with titles like 'software engineer' and occasionally loftier terms like 'enterprise architect' to spot potential issues before they become big problems.
Anyway my point is that bug tracking in software is a complex beast and if you take either side of an argument over whether notch is in the right or wrong to be adding features instead of fixing bugs then you are only showcasing your ignorance. It seems to be widely be considered taboo to make any criticism of notch here so instead of saying that I think he would be better off chasing down these bugs I suggest to you all that perhaps a perceived lull in new features and bug fixes could be partially explained by more and more time being spent refactoring just to be in the position move forward. It's an all too common story.
meanwhile the strongest opinions still seem to be in the posts of the most poorly informed and nothing changes
Emily:
You asked for an example of an emergent behaviour that unit testing would be difficult to test, but that isn't really what I meant. I meant it's hard to think of the potential uses of something to make the unit test for.
EG:
Water elevators. Bug, feature, or just emergent?
Paintings are non-collision objects.
Using furnaces/craft benches as "Hidden in the wall/floor" storage.
Being able to 'shape' trees into big or small as the player chooses
Using water to automatically harvest wheat.
TNT cannons.
All of these are situations that I am positive Notch did not think of when making the game, and therefore there is NO way he could write a unit test for them. I'm not saying it's hard to write the unit test, I'm saying it's hard to think of what unit test to write.
This thread is the best thread in the forums right now, except maybe some of the picture threads. I like pictures.]
Meanwhile the strongest opinions still seem to be in the posts of the most poorly informed and nothing changes.
Poorly informed? You will need to justify this. I assume your referring to immature internet users, who are often extremely biased. However Minecraft is very open to the public, it is very easy to access details of upcoming features (his blog, twitter or even interviews). SittenSpynne has already highlighted the cracks in such a method of documentation. I could argue the opposite, but the bottom line is both sides would be valid. Deep down, we all know that the community over hyped the Halloween update. In retrospect, it was a large update, but general view was that the update was bigger than what it actually is. I do agree that the update was rushed due to a unrealistic deadline (that wasn't needed) and other external influences.
But what can we, as a community (in particular to the "poorly informed") and Notch learn from this?
Should we doubt any announcements that Notch makes ? Should Notch do a Christmas update? Should Notch send previews of an update (during development) to "gaming news sites," such as PCgamer?
I agree with too many posters to quote them all (my apologies).
@Emily - I agree with what you are saying regarding TDD. Properly implementing this model requires code that heavily relies on testing itself at every stage of development and every feature added. Unfortunately a lot of software development is environment-sensitive (I admit, this is from my experience/observation), meaning that "waterfall model" is implemented during the planning stages, then skips straight to "rapid application development" unless someone realizes what is happening and takes steps to prevent this. Under these conditions it can be difficult (if not impossible) to implement TDD. What often emerges (given previously stated conditions/environment, and assuming someone puts the brakes on in time) is a hybrid of waterfall/agile/rapid method - not ideal and wearing on everyone involved. TDD makes sense, but is (in my experience) hard to sell.
@WeeMan0701 - Your arguments for constructive criticism/support are inarguable. Hmmm...
@Grelot - I have seen this "developer's blindness" with my own eyes and experience. I understand what you are saying and unfortunately agree with it. It does not apply to EVERY developer and as aforementioned depends on environment - some developers are not allowed the time/resources to properly do full-scale testing for every variable. How can they, when demands for changes/fixes is a constant pressure? (whether from users, testers, management, executive committee)
@SittenSpyne - Fascinating essay you prepared for us. I agree with many if not most points. The points I agree on are your observations on software development in general as relates to corporation-released games. Even a few other points have merit, such as the hype that the community built around this latest update. I don't think that "Notch is god" or any such thing - though I do appreciate the gift he has given us through this game, not to mention the insight and involvement he has given us through not only playtesting but also the development process (both general and specific) and the ongoing progress of Mojang and his personal life in general.
After reviewing software development models (it has been awhile since my Comp Sci classes) I think that Notch is following more of a "Spiral" model of programming and development (source: http://codebetter.com/blogs/raymond.lew ... 29114.aspx). Disagree or discuss - that is what makes us better!
EDIT: Emily made a comment about Spiral Development previously, which prompted my search.
Rollback Post to RevisionRollBack
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
Water elevators. Bug, feature, or just emergent?
Paintings are non-collision objects.
Using furnaces/craft benches as "Hidden in the wall/floor" storage.
Being able to 'shape' trees into big or small as the player chooses
Using water to automatically harvest wheat.
TNT cannons.
Those aren't bugs though. If Notch hasn't considered whether or not something is the intended behavior it isn't a bug. Once he decides that it's not the intended behavior, he writes a test for it and then off he goes.
@argentwolf - And it's unfortunate that it occurs, because what tends to happen (well... what I've seen interning places) is relative chaos that could so easily be mitigated by some simple paradigm changes.
Those aren't bugs though. If Notch hasn't considered whether or not something is the intended behavior it isn't a bug. Once he decides that it's not the intended behavior, he writes a test for it and then off he goes.
That makes unit testing largely useless then, as these 'unintended behaviours' are EXTREMELY unlikely to be discovered by the developer.
Once it gets found and he decides it's not an intended behaviour, that's the very definition of a bug. It's already too late.
Don't get me wrong, I'm not trying to bash unit testing. It's invaluable in strongly definable development projects. But unfortunately Minecraft is not easy to define all the rigid boundaries for what should and shouldn't happen.
You don't think it's a bug that you can walk through the middle of a painting?
(Emerged due to the fact that it's an 'edge' style block, like torches and mounted signs, so the block should be walk through-able. However, the other items are all only one block big and so must be fixed to something, whereas the bigger paintings can have a few blocks removed and still be there.)
You don't think it's a bug that putting a boat between two waterfalls lifts the boat upwards (at astonishing speed)?
(I've never tried this, but I'm guessing it works on the idea that boat's float. Therefore, if in water, send boat upwards.)
You don't think it's a bug that you can use put TNT in some water and negate it's destructive power, but none of it's kinetic power?
(Not sure why this is like this to be honest)
I stand by the following progression:
1: Notch had no idea that these could occur
2: He could therefore never specifically design a test to work out whether they acted properly until after it was discovered that they don't.
@argentwolf - And it's unfortunate that it occurs, because what tends to happen (well... what I've seen interning places) is relative chaos that could so easily be mitigated by some simple paradigm changes.
Please forgive the off-topic. Do you have suggestions in the area of the "simple paradigm changes"?
On-Topic: Game development is a difficult beast. You can't approach it like a "corporate" project, at least not in the "plan, program, test, sell" format. It is more organic, though I think Minecraft fits this "organic" definition more than any other game or pseudo-game I have seen to date. It is a product of imagination both between the programmer and the player... Fascinating stuff. Has a new development model been created? Is it viable?
There is no question that changes are needed, whether you are an SSP or SMP player (or both). I find it encouraging that Mojang is becoming a more formal structure, to be honest as this will positively (to some, perhaps negatively) impact the changes to come. As usual, some percentage of us will not get what we want, life goes on. I remain a loyal Minecraft player.
Rollback Post to RevisionRollBack
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
As usual, some percentage of us will not get what we want, life goes on. I remain a loyal Minecraft player.
At the risk of dragging this ever-more-amazing thread a bit off-topic, that called to mind an observation about all of this that keeps recurring to me.
Beyond the additional pressure and the inclination at least to do things in an order that might not be optimal in order to please the customers, I keep wondering if a public alpha is a questionable choice for the simple reason that "some percentage of us will not get what we want." What I mean is: there's some portion of the previous content of the game that's already been removed or altered relatively dramatically. There will be more. That's just about certain. Some number of things will probably be substantially revised if not dropped altogether. And each time that that's done, there's some number of players who are going to insist that the game has been completely ruined, are going to stalk off in a huff and potentially (and this is the troubling bit) tell anyone who'll listen how horrible the game is.
And the thing is that those same players would almost certainly, had they never seen the alpha version (or the beta), love the game and tell all those same people how wonderful it is. And that simply because all they'd know is what's in the game at release-- they'd never know that there was a stage in its development at which some other feature was there, so they'd never know what they were missing.
Nothing much to do about that I guess, and as noted it's a bit off-topic, so there's two arguments against even bringing it up, but it's something that keeps floating through my head and I have this habit of typing such things out and posting them on forums, so.....
Good topic here. Was happily suprised to see the reasonable discussion going on.
It is worth noting, that since we do not see what his minds-eye-vision of what he (notch) intends to do/go with various features.. it is entirely possible that some bugs are simply unimportant or not worth fixing in the grand scheme of things. For example.. if the tree growth code/foliage rot, is going to be totally reworked to come up with new vegetation models for biomes.. WHY go in and waste time trying to fix code for foliage decay when the whole thing is going to be redone anyhow. (that is just one example of such a thing.) I certainly have used placeholder code that allows the system to run... with the intention of scrapping it entirely with a different function later. I am not going to go back and fix bugs in my placeholder code.... well.. maybe.. if it was crippling something else I needed to get working on I would... maybe.. but thats the sort of thing that needs consideration. I love that I get to see the process of development going on from early stages... people should look on it as a bonus feature. (like director commentary on a movie) Plus... the game IS fun as it is... Loving it. Even love finding bugs sometimes and playing around with them.
Note: To the person who wanted to get into a "playtesting" field of work... thats usually something people do for a couple games and then thats it.... and having some knowledge of it... It kinda sucks... You have reports to fill out on bugs and then there is the need to replicate what happened... I know we had to make sure we could reproduce the circumstances, and that the bug would keep happening. 100 times in some cases.... although there was one time my partner and I just screwing around covered an entire globe with fog of war as a team... took about an hour and a half to do... and the game crashed... They told us eh... because it took so long we only needed to reproduce that 50 times. (Fun... now we know what we are going to be doing the rest of the week.) So... its not like you just get to sit around and play games like your playing them to 'have fun'. You are doing stupid repetitive things over and over to test code... not to achieve the games goals. Anyhow, good luck though.. it is kinda interesting once or twice... doing it for a lifetime of work would be torture.....
It's true everywhere that strong opinions go hand in hand with weak understandings, you can see this just by picking up a newspaper and seeing the latest immensely complex decisions in monetary policy be forced through the mold of the paper's agenda into some half-baked but purportedly obvious injustice. The more we learn, the less we know. Notice how all the cleverest posts in this thread are carefully considering both sides and only coming to a tenuous conclusion or no conclusion at all? Notice how the posters taking a firm stance one way or another are not doing this at all?
I also don't understand why people think this is the best thread on the forums, really just seems like a bunch of programmers stroking their beards and nodding thoughtfully at each other while they rehash mundane development paradigms as a bunch of admiring "mature" teenagers try to insert themselves into the conversation with tangentially-related bits of information they read on wikipedia.
I'll say it again: there are no meaningful conclusions to be drawn on whether it is better to fix bugs now or leave them for later in the general case. Since none of us know the specifics of the current minecraft bug internals we can't make any reasonable conclusions about what the correct approach towards them is at all. You can try to fit a particular development model around the minecraft release cycle if it makes you happy but if you have to call a particular decision a mistake to make it fit, or if you use the model to explain away choices that you are yourself not happy about, then you are practising self-delusion.
I also don't understand why people think this is the best thread on the forums, really just seems like a bunch of programmers stroking their beards and nodding thoughtfully at each other while they rehash mundane development paradigms as a bunch of admiring "mature" teenagers try to insert themselves into the conversation with tangentially-related bits of information they read on wikipedia.*
Wait, am I am "mature" teenager, or stroking my... "beard"? Or did you forget a third option?
It's true everywhere that strong opinions go hand in hand with weak understandings, you can see this just by picking up a newspaper and seeing the latest immensely complex decisions in monetary policy be forced through the mold of the paper's agenda into some half-baked but purportedly obvious injustice. The more we learn, the less we know. Notice how all the cleverest posts in this thread are carefully considering both sides and only coming to a tenuous conclusion or no conclusion at all? Notice how the posters taking a firm stance one way or another are not doing this at all?
I also don't understand why people think this is the best thread on the forums, really just seems like a bunch of programmers stroking their beards and nodding thoughtfully at each other while they rehash mundane development paradigms as a bunch of admiring "mature" teenagers try to insert themselves into the conversation with tangentially-related bits of information they read on wikipedia.
I'll say it again: there are no meaningful conclusions to be drawn on whether it is better to fix bugs now or leave them for later in the general case. Since none of us know the specifics of the current minecraft bug internals we can't make any reasonable conclusions about what the correct approach towards them is at all. You can try to fit a particular development model around the minecraft release cycle if it makes you happy but if you have to call a particular decision a mistake to make it fit, or if you use the model to explain away choices that you are yourself not happy about, then you are practising self-delusion.
*strokes beard, nods thoughtfully*
This thread is very informative if you don't have any prior experience in the game industry or programming experience and helps to clear up some of the misconceptions surrounding this game. Lets be honest any thread that doesn't end in CAPS matches on this forum are a real boon to everyone.
This thread is very informative if you don't have any prior experience in the game industry or programming experience and helps to clear up some of the misconceptions surrounding this game. Lets be honest any thread that doesn't end in CAPS matches on this forum are a real boon to everyone.
Ah right I hadn't considered that, glad to hear you're getting something out of it.
This thread is very informative if you don't have any prior experience in the game industry or programming experience and helps to clear up some of the misconceptions surrounding this game. Lets be honest any thread that doesn't end in CAPS matches on this forum are a real boon to everyone.
Ah right I hadn't considered that, glad to hear you're getting something out of it.
Yes, this thread is mostly informative (also being persuasive at times), but who is likely to read this thread? The answer being "mature teenagers" (and other mature internet users). The "poorly informed" are very unlikely to invest the time to read and more importantly understand this thread. So the bottom line is that "nothing changes."
This thread is very informative if you don't have any prior experience in the game industry or programming experience and helps to clear up some of the misconceptions surrounding this game. Lets be honest any thread that doesn't end in CAPS matches on this forum are a real boon to everyone.
Ah right I hadn't considered that, glad to hear you're getting something out of it.
Yes, this thread is mostly informative (also being persuasive at times), but who is likely to read this thread? The answer being "mature teenagers" (and other mature internet users). The "poorly informed" are very unlikely to invest the time to read and more importantly understand this thread. So the bottom line is that "nothing changes."
It's true everywhere that strong opinions go hand in hand with weak understandings, you can see this just by picking up a newspaper and seeing the latest immensely complex decisions in monetary policy be forced through the mold of the paper's agenda into some half-baked but purportedly obvious injustice. The more we learn, the less we know. Notice how all the cleverest posts in this thread are carefully considering both sides and only coming to a tenuous conclusion or no conclusion at all? Notice how the posters taking a firm stance one way or another are not doing this at all?
/agree
Quote from seriously man »
I also don't understand why people think this is the best thread on the forums, really just seems like a bunch of programmers stroking their beards and nodding thoughtfully at each other while they rehash mundane development paradigms as a bunch of admiring "mature" teenagers try to insert themselves into the conversation with tangentially-related bits of information they read on wikipedia.
Honestly I felt right at home in this thread. I am not a programmer, but I work with them and have a have been able to observe a variety of "development paradigms" being implemented. Most professional forums follow the pattern seen in this thread; intelligent people discussing things in a rational way, opinions presented, examined, discarded, etc. One example of this (which I have referred to heavily in troubleshooting issues) can be seen here: http://www.experts-exchange.com/
*strokes beard, nods thoughtfully* (This was too good, had to borrow it!)
Rollback Post to RevisionRollBack
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
Have you ever done any serious programming or game development? No? Didn't think so.
I have a BTEC in Games Devolpment which includes learning about the industry and the series of steps needed in creating a game and yes he is correct. You don't even need to know anything about the industry when your common logic tells it is better also not many games are public beta until it is polish and qaulity assured let alone Public alpha which is why bugs are not a big thing until the end.
While I agree with you Dragondj0 on this topic it is only in the area of corporately developed games. By definition, this is an Indie game - corporations want an orderly development process (preferred one varies) because what matters to them most is one thing... ROI (Return on Investment, i.e. money).
Notch, on the other hand, as an Indie developer can make up the rules as he goes. If you don't like what he provides, you are free to discontinue playing while the rest of us enjoy not only the further development of the game but also the community and personal touch that many of us value when it comes to Notch's involvement.
Rollback Post to RevisionRollBack
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
Say that to the guy who ended up over 5 chunks away separated by a huge mountain range *sob*.
However, i am having fun with them for now. I have a feeling they'll be a lot less random eventually. For now the work around would require me to dig far to much, as well as possibly finding a way to empty a lake of lava in hell.... not going to happen any time soon.
-ChaosAngel092
Ignore a bug for too long and it becomes a bear. Some bugs are pretty benign, often when the programmer has forgotten to account for an uncommon occurrence, and fixing it is as simple as finding where it is and adding a few lines of code to handle the particular situation. Sometimes it's more than a few lines and it's rare enough or a pain in the butt enough to just leave it, knowing the reason why it happens and what it will take to fix it. Notch sometimes tweets about these. The bugs that attract the most attention on these forums are not like these, since they break major game-play elements they would be fixed already if they were simple to fix. It's reasonable to conclude that fixing them is not a matter of a few extra lines of code, that it's going to require changes to other parts internally.
The trouble is, and as attested to by other programmers in the thread this happens all the time, changing little bits across the codebase almost inevitably precipitates the need to refactor - to restructure the program so that all the little bits of code recently added are in their correct places - what "correct" means depends on the development model being used, but a universal truth is that unless a project is very carefully specified in advance there is going to be refactoring at some stage and you just need to incorporate it into your time estimates. There's a whole sub-field of computer science which tries to quantify these factors, called software metrics. It's very boring. Most (certainly not all!) programmers hate refactoring because it's extra effort for little to no show-off value, and it usually snowballs as changing the structure of one part necessitates a change in structure for another part. The consequences are often quite unpredictable. Not completely unpredictable, just difficult if you don't come from a metrics background.
The idea that software development happens in two relatively separate steps of adding content then fixing bugs is laughable, the idea of it working like that for minecraft is hysterical. The waterfall model is similar, but even notch has openly mocked that. By not addressing every user-facing issue as it comes, a developer can never know if it's going to reveal a major oversight, a crack in the foundations which might otherwise be built on top of and require major changes all the way up if the foundations are modified.
I'm not sure if any of the current bugs in minecraft are going to require extensive refactoring to fix properly, but neither do you. Notch is a good programmer working on an excellent game but it takes more than that to avoid such chronic structural problems on a large project - this is why big software firms hire metrics guys or programmers experienced enough to have an intuitive sense for it with titles like 'software engineer' and occasionally loftier terms like 'enterprise architect' to spot potential issues before they become big problems.
Anyway my point is that bug tracking in software is a complex beast and if you take either side of an argument over whether notch is in the right or wrong to be adding features instead of fixing bugs then you are only showcasing your ignorance. It seems to be widely be considered taboo to make any criticism of notch here so instead of saying that I think he would be better off chasing down these bugs I suggest to you all that perhaps a perceived lull in new features and bug fixes could be partially explained by more and more time being spent refactoring just to be in the position move forward. It's an all too common story.
meanwhile the strongest opinions still seem to be in the posts of the most poorly informed and nothing changes
You asked for an example of an emergent behaviour that unit testing would be difficult to test, but that isn't really what I meant. I meant it's hard to think of the potential uses of something to make the unit test for.
EG:
Water elevators. Bug, feature, or just emergent?
Paintings are non-collision objects.
Using furnaces/craft benches as "Hidden in the wall/floor" storage.
Being able to 'shape' trees into big or small as the player chooses
Using water to automatically harvest wheat.
TNT cannons.
All of these are situations that I am positive Notch did not think of when making the game, and therefore there is NO way he could write a unit test for them. I'm not saying it's hard to write the unit test, I'm saying it's hard to think of what unit test to write.
This thread is the best thread in the forums right now, except maybe some of the picture threads. I like pictures.]
Poorly informed? You will need to justify this. I assume your referring to immature internet users, who are often extremely biased. However Minecraft is very open to the public, it is very easy to access details of upcoming features (his blog, twitter or even interviews). SittenSpynne has already highlighted the cracks in such a method of documentation. I could argue the opposite, but the bottom line is both sides would be valid. Deep down, we all know that the community over hyped the Halloween update. In retrospect, it was a large update, but general view was that the update was bigger than what it actually is. I do agree that the update was rushed due to a unrealistic deadline (that wasn't needed) and other external influences.
But what can we, as a community (in particular to the "poorly informed") and Notch learn from this?
Should we doubt any announcements that Notch makes ? Should Notch do a Christmas update? Should Notch send previews of an update (during development) to "gaming news sites," such as PCgamer?
@Emily - I agree with what you are saying regarding TDD. Properly implementing this model requires code that heavily relies on testing itself at every stage of development and every feature added. Unfortunately a lot of software development is environment-sensitive (I admit, this is from my experience/observation), meaning that "waterfall model" is implemented during the planning stages, then skips straight to "rapid application development" unless someone realizes what is happening and takes steps to prevent this. Under these conditions it can be difficult (if not impossible) to implement TDD. What often emerges (given previously stated conditions/environment, and assuming someone puts the brakes on in time) is a hybrid of waterfall/agile/rapid method - not ideal and wearing on everyone involved. TDD makes sense, but is (in my experience) hard to sell.
@WeeMan0701 - Your arguments for constructive criticism/support are inarguable. Hmmm...
@Grelot - I have seen this "developer's blindness" with my own eyes and experience. I understand what you are saying and unfortunately agree with it. It does not apply to EVERY developer and as aforementioned depends on environment - some developers are not allowed the time/resources to properly do full-scale testing for every variable. How can they, when demands for changes/fixes is a constant pressure? (whether from users, testers, management, executive committee)
@SittenSpyne - Fascinating essay you prepared for us. I agree with many if not most points. The points I agree on are your observations on software development in general as relates to corporation-released games. Even a few other points have merit, such as the hype that the community built around this latest update. I don't think that "Notch is god" or any such thing - though I do appreciate the gift he has given us through this game, not to mention the insight and involvement he has given us through not only playtesting but also the development process (both general and specific) and the ongoing progress of Mojang and his personal life in general.
After reviewing software development models (it has been awhile since my Comp Sci classes) I think that Notch is following more of a "Spiral" model of programming and development (source: http://codebetter.com/blogs/raymond.lew ... 29114.aspx). Disagree or discuss - that is what makes us better!
EDIT: Emily made a comment about Spiral Development previously, which prompted my search.
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
Those aren't bugs though. If Notch hasn't considered whether or not something is the intended behavior it isn't a bug. Once he decides that it's not the intended behavior, he writes a test for it and then off he goes.
@argentwolf - And it's unfortunate that it occurs, because what tends to happen (well... what I've seen interning places) is relative chaos that could so easily be mitigated by some simple paradigm changes.
That makes unit testing largely useless then, as these 'unintended behaviours' are EXTREMELY unlikely to be discovered by the developer.
Once it gets found and he decides it's not an intended behaviour, that's the very definition of a bug. It's already too late.
Don't get me wrong, I'm not trying to bash unit testing. It's invaluable in strongly definable development projects. But unfortunately Minecraft is not easy to define all the rigid boundaries for what should and shouldn't happen.
You don't think it's a bug that you can walk through the middle of a painting?
(Emerged due to the fact that it's an 'edge' style block, like torches and mounted signs, so the block should be walk through-able. However, the other items are all only one block big and so must be fixed to something, whereas the bigger paintings can have a few blocks removed and still be there.)
You don't think it's a bug that putting a boat between two waterfalls lifts the boat upwards (at astonishing speed)?
(I've never tried this, but I'm guessing it works on the idea that boat's float. Therefore, if in water, send boat upwards.)
You don't think it's a bug that you can use put TNT in some water and negate it's destructive power, but none of it's kinetic power?
(Not sure why this is like this to be honest)
I stand by the following progression:
1: Notch had no idea that these could occur
2: He could therefore never specifically design a test to work out whether they acted properly until after it was discovered that they don't.
Please forgive the off-topic. Do you have suggestions in the area of the "simple paradigm changes"?
On-Topic: Game development is a difficult beast. You can't approach it like a "corporate" project, at least not in the "plan, program, test, sell" format. It is more organic, though I think Minecraft fits this "organic" definition more than any other game or pseudo-game I have seen to date. It is a product of imagination both between the programmer and the player... Fascinating stuff. Has a new development model been created? Is it viable?
There is no question that changes are needed, whether you are an SSP or SMP player (or both). I find it encouraging that Mojang is becoming a more formal structure, to be honest as this will positively (to some, perhaps negatively) impact the changes to come. As usual, some percentage of us will not get what we want, life goes on. I remain a loyal Minecraft player.
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
At the risk of dragging this ever-more-amazing thread a bit off-topic, that called to mind an observation about all of this that keeps recurring to me.
Beyond the additional pressure and the inclination at least to do things in an order that might not be optimal in order to please the customers, I keep wondering if a public alpha is a questionable choice for the simple reason that "some percentage of us will not get what we want." What I mean is: there's some portion of the previous content of the game that's already been removed or altered relatively dramatically. There will be more. That's just about certain. Some number of things will probably be substantially revised if not dropped altogether. And each time that that's done, there's some number of players who are going to insist that the game has been completely ruined, are going to stalk off in a huff and potentially (and this is the troubling bit) tell anyone who'll listen how horrible the game is.
And the thing is that those same players would almost certainly, had they never seen the alpha version (or the beta), love the game and tell all those same people how wonderful it is. And that simply because all they'd know is what's in the game at release-- they'd never know that there was a stage in its development at which some other feature was there, so they'd never know what they were missing.
Nothing much to do about that I guess, and as noted it's a bit off-topic, so there's two arguments against even bringing it up, but it's something that keeps floating through my head and I have this habit of typing such things out and posting them on forums, so.....
It is worth noting, that since we do not see what his minds-eye-vision of what he (notch) intends to do/go with various features.. it is entirely possible that some bugs are simply unimportant or not worth fixing in the grand scheme of things. For example.. if the tree growth code/foliage rot, is going to be totally reworked to come up with new vegetation models for biomes.. WHY go in and waste time trying to fix code for foliage decay when the whole thing is going to be redone anyhow. (that is just one example of such a thing.) I certainly have used placeholder code that allows the system to run... with the intention of scrapping it entirely with a different function later. I am not going to go back and fix bugs in my placeholder code.... well.. maybe.. if it was crippling something else I needed to get working on I would... maybe.. but thats the sort of thing that needs consideration. I love that I get to see the process of development going on from early stages... people should look on it as a bonus feature. (like director commentary on a movie) Plus... the game IS fun as it is... Loving it. Even love finding bugs sometimes and playing around with them.
Note: To the person who wanted to get into a "playtesting" field of work... thats usually something people do for a couple games and then thats it.... and having some knowledge of it... It kinda sucks... You have reports to fill out on bugs and then there is the need to replicate what happened... I know we had to make sure we could reproduce the circumstances, and that the bug would keep happening. 100 times in some cases.... although there was one time my partner and I just screwing around covered an entire globe with fog of war as a team... took about an hour and a half to do... and the game crashed... They told us eh... because it took so long we only needed to reproduce that 50 times. (Fun... now we know what we are going to be doing the rest of the week.) So... its not like you just get to sit around and play games like your playing them to 'have fun'. You are doing stupid repetitive things over and over to test code... not to achieve the games goals. Anyhow, good luck though.. it is kinda interesting once or twice... doing it for a lifetime of work would be torture.....
It's true everywhere that strong opinions go hand in hand with weak understandings, you can see this just by picking up a newspaper and seeing the latest immensely complex decisions in monetary policy be forced through the mold of the paper's agenda into some half-baked but purportedly obvious injustice. The more we learn, the less we know. Notice how all the cleverest posts in this thread are carefully considering both sides and only coming to a tenuous conclusion or no conclusion at all? Notice how the posters taking a firm stance one way or another are not doing this at all?
I also don't understand why people think this is the best thread on the forums, really just seems like a bunch of programmers stroking their beards and nodding thoughtfully at each other while they rehash mundane development paradigms as a bunch of admiring "mature" teenagers try to insert themselves into the conversation with tangentially-related bits of information they read on wikipedia.
I'll say it again: there are no meaningful conclusions to be drawn on whether it is better to fix bugs now or leave them for later in the general case. Since none of us know the specifics of the current minecraft bug internals we can't make any reasonable conclusions about what the correct approach towards them is at all. You can try to fit a particular development model around the minecraft release cycle if it makes you happy but if you have to call a particular decision a mistake to make it fit, or if you use the model to explain away choices that you are yourself not happy about, then you are practising self-delusion.
*strokes beard, nods thoughtfully*
Wait, am I am "mature" teenager, or stroking my... "beard"? Or did you forget a third option?
I was being facetious, I don't have beard either.
edit: but if I did I would be stroking it thoughtfully that's for sure
This thread is very informative if you don't have any prior experience in the game industry or programming experience and helps to clear up some of the misconceptions surrounding this game. Lets be honest any thread that doesn't end in CAPS matches on this forum are a real boon to everyone.
Ah right I hadn't considered that, glad to hear you're getting something out of it.
Yes, this thread is mostly informative (also being persuasive at times), but who is likely to read this thread? The answer being "mature teenagers" (and other mature internet users). The "poorly informed" are very unlikely to invest the time to read and more importantly understand this thread. So the bottom line is that "nothing changes."
As long as someone gets something out of it.
/agree
Honestly I felt right at home in this thread. I am not a programmer, but I work with them and have a have been able to observe a variety of "development paradigms" being implemented. Most professional forums follow the pattern seen in this thread; intelligent people discussing things in a rational way, opinions presented, examined, discarded, etc. One example of this (which I have referred to heavily in troubleshooting issues) can be seen here: http://www.experts-exchange.com/
*strokes beard, nods thoughtfully* (This was too good, had to borrow it!)
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
While I agree with you Dragondj0 on this topic it is only in the area of corporately developed games. By definition, this is an Indie game - corporations want an orderly development process (preferred one varies) because what matters to them most is one thing... ROI (Return on Investment, i.e. money).
Notch, on the other hand, as an Indie developer can make up the rules as he goes. If you don't like what he provides, you are free to discontinue playing while the rest of us enjoy not only the further development of the game but also the community and personal touch that many of us value when it comes to Notch's involvement.
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb