Top Mud Sites Forum - View Single Post

shadowfyr · 03-13-2004, 03:29 PM

You know.. Maybe mudders are just not equipped to deal with this, considering the comments. lol

But seriously, look at something like the POV-Ray raytracer. This was developed by a small team, but giving out full source, so there is an official version plus MegaPOV (sometimes several). MegaPOV is the bleeding edge version that everyone tries to impliment new ideas in, which if they are decently documented and actually useful, will eventually end up in the official version. This system has worked quite well. The current version 3.6 is a bug fix beta for 3.5, which is the last major version before they do a complete redesign (and probably add quite a few additional features that where impractical in the current one).

In terms if capabilities, it runs on virtually anything, has 90% of the features of high end programs like Maya, can simulate much of the stuff not directly supported through its script, etc. It has no inbuilt modelling program, due to the complications of making such cross-platform, but that is about the only thing that keeps it from being noticed by the types of people that do buy Maya, Cinema 4D or the like.

Point is, a text based system, even if it provided the ability to extend itself and use things like graphics as well, is significantly less complicated than POV-Ray was even in version 1.0, when it was little more than a rewrite of DKBTrace. What you need is a core group that can build a really good base, then maintains control over the official version. As long as they allow feedback and pay attention to what features other people add in to the unofficial versions, these features can, if really useful, be integrated into the next official version. The result if done right can be a very stable and exceptional system.

The problem imho with most currently is that some group developes one that does what they need, release it to the public and a few years later you have no official version (since the originators don't want to deal with what anyone else did to it) and 500 variations, none of which are as good as version 1.0 of some new codebase that comes along. This cannot by definition generate the kind of long term progress needed to keep a codebase on the top of the list of ones new people will be using ten years from now. And it definitely doesn't improve the system any of those 500 variations are based on.

In the case of KaVir's and erdos's example, most likely you would end up with one server that combines #56's good ideas with #37's and an option to allow someone to change one setting to make it workl like #79 wanted. Plugin modules shouldn't imho be at that low a level anyway, though a single player module that included a 'client' that plugged directly into the driver for local control would make sense. You might therefor provide a 'internet' module that handles output over telnet or other methods and a single user one that just displays local. You could have one or both plugged in as needed. The other two though don't make sense as seperate entities. That is what you need a core group for, so that you don't get people designing stuff that makes no sense as seperate modules and screaming about how no one wants to try their new toy. Someone needs to decide what does make sense to modularize, what shouldn't be and how to adjust the code to keep the creation of such a module for some function doesn't flat out break the driver or library used on it.

03-13-2004, 03:29 PM	#18
shadowfyr Senior Member Join Date: Oct 2002 Posts: 310	You know.. Maybe mudders are just not equipped to deal with this, considering the comments. lol But seriously, look at something like the POV-Ray raytracer. This was developed by a small team, but giving out full source, so there is an official version plus MegaPOV (sometimes several). MegaPOV is the bleeding edge version that everyone tries to impliment new ideas in, which if they are decently documented and actually useful, will eventually end up in the official version. This system has worked quite well. The current version 3.6 is a bug fix beta for 3.5, which is the last major version before they do a complete redesign (and probably add quite a few additional features that where impractical in the current one). In terms if capabilities, it runs on virtually anything, has 90% of the features of high end programs like Maya, can simulate much of the stuff not directly supported through its script, etc. It has no inbuilt modelling program, due to the complications of making such cross-platform, but that is about the only thing that keeps it from being noticed by the types of people that do buy Maya, Cinema 4D or the like. Point is, a text based system, even if it provided the ability to extend itself and use things like graphics as well, is significantly less complicated than POV-Ray was even in version 1.0, when it was little more than a rewrite of DKBTrace. What you need is a core group that can build a really good base, then maintains control over the official version. As long as they allow feedback and pay attention to what features other people add in to the unofficial versions, these features can, if really useful, be integrated into the next official version. The result if done right can be a very stable and exceptional system. The problem imho with most currently is that some group developes one that does what they need, release it to the public and a few years later you have no official version (since the originators don't want to deal with what anyone else did to it) and 500 variations, none of which are as good as version 1.0 of some new codebase that comes along. This cannot by definition generate the kind of long term progress needed to keep a codebase on the top of the list of ones new people will be using ten years from now. And it definitely doesn't improve the system any of those 500 variations are based on. In the case of KaVir's and erdos's example, most likely you would end up with one server that combines #56's good ideas with #37's and an option to allow someone to change one setting to make it workl like #79 wanted. Plugin modules shouldn't imho be at that low a level anyway, though a single player module that included a 'client' that plugged directly into the driver for local control would make sense. You might therefor provide a 'internet' module that handles output over telnet or other methods and a single user one that just displays local. You could have one or both plugged in as needed. The other two though don't make sense as seperate entities. That is what you need a core group for, so that you don't get people designing stuff that makes no sense as seperate modules and screaming about how no one wants to try their new toy. Someone needs to decide what does make sense to modularize, what shouldn't be and how to adjust the code to keep the creation of such a module for some function doesn't flat out break the driver or library used on it.