Communism fails because of corruption & greed. (same reason capitalism fails...... hmmmmm)

Seph had a Utopian view of the scripting 'community' being a small & tight-knit group of people working as a team to crank out scripts.
All using SDK/MACL to improve compatibility. If you do a lot of scripting for the community as opposed to proprietary scripting, it's great.

The reality is... there are a lot of autonomous scripters who are not professional programmers, so they don't see the beauty.

I've done projects with it, without it, and with pieces of it. Use it, don't use it, whatever it takes to get the job done.

Just because it's inactive, doesn't make it invaluable.

I don't think you mean to say "invaluable" which means "so important it is beyond value". Did you mean "Just because it's inactive, doesn't mean it's worthless?"

The two where a nice idea but failed. I use macl methods only, not the entire one, its a trully nice function recopilation, anyway.

Haha, I like how you just take a jab at everyone that disagrees with you.

I hate to step on your rainbow walkways and lollipop trees, but just because something is "for the community" doesn't mean it's actually a good thing. The fact of the matter is, this was done poorly.

Let's take a look at some of the things this SDK does:

Modifies Object class -- This is something someone does when they are just learning about inheritance and they think "Yeah! I can modify all the classes I need to at once!" I really hope I don't have to explain to you why this is bad, but I will just in case.

Pulls single lines out to functions -- You aren't supposed to pull out to a function every single line you think someone might want to modify. Especially when you end up with long function names that don't actually make sense.

I've got to wrap this up because I've got other things to do, but you don't know how often I get people who's projects don't work because the SDK is bad for compatibility. In theory, having something to make working with other nicer is great, but in practice what happens is you have a group of RTP scripts that work with each other and not SDK, you have a group of SDK-enabled scripts that work with each other and not RTP, and then you have a group of scripts, from both RTP and SDK, where nothing works with each other. I can tell you I don't choose to not use the SDK just to be difficult, I choose not to use the SDK because I've actually looked at it and it's crappy.

(Also I like how you throw around "professional programmer" like that means something.)

_          )         &          ^    ( ^%       +     +  *   + ^ $      )    %
     +       *      %          %$(              (            %          (      *
            )                          ಠ_ಠ         ^             %          (
  )                   #             $                               )       )   #
   ^       $           &                    %         $       (            # @*
   #        )                    *                 %                   )        $

Come on now, don't be so negative. Having been around when the SDK was first developed, I can say that every single piece of the SDK is intended to fix an observable problem among custom scripts at the time.

The main edit was the separating of different functionality to different methods, which you criticized second. This was intended to solve the major compatibility problems and create some kind of rosy future where two different scripters could modify the same system and expect their scripts to work together. It may require some active checking for compatibility, but as the default scripts are constructed sometimes there are god functions like Scene_*#main that might need to be modified, and the only available method to modify without copying the existing function was with alias tricks and they wouldn't work. It would seem that in some cases, the default scripts for RMVX took this lead and separated the functions to make it easier to edit without those problems.

You could argue that Seph's choice of where to divide functions was poor, but his intentions were good and he was just trying to avoid changing the actual functionality. The real problem here is that best practices for modular design by contract were not followed in the default scripts. What that means is that for every method, there should be a simple and succinct way of describing what it does, and it should make sense that it goes in this class and not an extension or the class being modified. Most of the methods in the default scripts are god functions, where the only succinct explanation could be "makes the whole thing work" rather than something like "takes input for command window and delegates to the proper procedure from the given processes" (for that example, the actual RTP example would "take input for command window and change the scene accordingly, with the changes hard-coded so this method is only ever used once and in this class only").

The second major "problem" was really just trying to create a convenience to reduce redundant code. The auto-updating and auto-disposing features, which utilized modifications to the Object class to turn them on or off per object, were meant to eliminate lines of code that just said "@command_window.update" etc. One can understand why this is desired, but having drawn this concept out to its full well-coded logical conclusion (creating an Auto mix-in that can run a recursive process on member variables that inherit from the Auto module) and seen not only the greatly reduced performance but also the ambiguity and difficulty in managing such an automated system, I believe this idea was ultimately wrong-headed. It is right and proper for the programmer to have to tell the program exactly what to do and when, rather than relying on an automated system to control the program structure, and in this case especially there is very little gain in convenience for much more loss in simplicity and flexibility. However, you have to understand that this wasn't just one guy deciding it would be a good idea; this was designed to fit a desire that other programmers had and to help such programmers focus on the real meat instead of extra boilerplate code.


I may be out of touch with the scripter's forum, being that I only really care about low-level scripts because I prefer to implement the higher level stuff myself, but in my opinion the SDK is already dead due to lack of updates and limited adoption. When the SDK was active, making SDK-enabled scripts was the flavor of the week. I think it fell out of favor because people didn't like having to download an extra script, and it created unanticipated compatibility problems between the different walled gardens. But for all I know, the SDK may still be going strong. In my opinion, however, there is no easy solution short of creating a new, better designed modular game engine from the ground up to eliminate the compatibility headaches created for a non-scripter when trying to integrate wildly different scripts from hordes of amateur developers into a single project.


EDIT: Wow, that turned out to be a huge wall of text! But, maybe it's interesting enough to read. I'd like to think so.

Best laid plans of mice and men etc. etc.

The idea of making it easier to make inter compatible scripts is great. It was just executed very poorly. I bet if you asked any of the people who worked on this they would say the same.

The fact that they had good intentions doesn't change the fact that the SDk, itself, is a piece of crap. The problem is that the SDK ended up being just a rewrite of the RTP scripts, only worse.

EDIT: Oh I should say that I am not really mad at the original developers for making it, they were just naive I guess. I am mad at people trying to defend it today, especially ones who claim it's just misunderstood because there's not enough professionals around :P

_          )         &          ^    ( ^%       +     +  *   + ^ $      )    %
     +       *      %          %$(              (            %          (      *
            )                          ಠ_ಠ         ^             %          (
  )                   #             $                               )       )   #
   ^       $           &                    %         $       (            # @*
   #        )                    *                 %                   )        $

The problem with SDK isn't the code efficiency itself.
But it's popularoty.

RMXP codes was really not well structured, with unnecessary long methods. Wich force people to re-write whole methods for some small changes.

SDK was supposed to increase compatibily, but in fact it reduce it. Why? Simply because it's really a minority of the world's scripters that use it.
It's basically used only by a few .org users and really a few out of .org. On other communities it's not used. Did someone ever saw an Japanese script with SDK? I guess not. On my country (Brazil) also, almost no scripter make SDK compatible scripts.

The SDK concept is great (no wonder why RGSS2 had a lot of SDK on it), but it's not pratical, since people generally have to choose between SDK only scripts, or non-SDK scripts. And since the variety of non-sdk scripts is really far greater, people most likely drop it.

But i totally disagree with people that talks like "people that don't use SDK aren't professional enough". Making SDK only scripts these days are a total waste, since will cause more compatibiluty issues than solve them.

It makes the scripter life easier, but make the end-user life harder since they will have a lot of compatibily issues between the sdk and non-sdk scripts.

RGSS 2 makes some of the same mistakes that the SDK made, but not all of them. (I still can't get over modifying Object). The reason this SDK is bad, though, has nothing to do with how popular it got. It is a great thing that it didn't become popular, because there would have been more people thinking what they did was a good idea. The execution of this SDK is flawed from top to bottom. I earlier called it a rewrite of the RTP scripts, but that is wrong, it wasn't even a rewrite. It was merely a poor refactoring with some terrible coding thrown in.

_          )         &          ^    ( ^%       +     +  *   + ^ $      )    %
     +       *      %          %$(              (            %          (      *
            )                          ಠ_ಠ         ^             %          (
  )                   #             $                               )       )   #
   ^       $           &                    %         $       (            # @*
   #        )                    *                 %                   )        $

Well it's your opinion, although i can't agree with it.
Things like Scene_Base, and slicing methods like the mains, updates and others would make scripting compatible scripts far easier.

Query:
Who is in charge of the SDK (maintenance, production, development, etc.) or if the SDK is still in development.

I have a module that 'could' be classified as a possible addition to the SDK. Based on one of the SDK methods, I created a few methods in the SDK style that can work without the rest of the SDK (standalone).

Yeah, I am not a fan of the SDK, but... All's fair ya know.

The SDK is not maintained, nor is it in development. Most of the original scripters are long gone, and it has fallen out of popularity. I'm actually surprised it's still stickied here. I personally use it, but i'm not releasing scripts anymore, instead I'm trying to work on my own project and use the SDK as a base. I find it a challenge to convert non-SDK scripts to be compatible with the SDK so I can use them, or script them from scratch. I'm learning more about ruby and rgss this way.

Anyway, Off Topic, but: nice to see you around again DerVVulfman.

It's stickied for posterity. (For those that use it)
It's essentially an orphan at this point.

I typically just borrow bits & pieces from SDK/MACL, rather than implement them as a whole.

That being said, it you want to add a module, I'll happily update the source / download.

Be Well

Wow, I totally missed this....

I really wasn't trying to 'take a jab', only to point out the difference in perspective.
We were all amateurs/students at one point.

Look at it this way... if you truly want to learn something about politics, would you argue(discuss) it with your barber or your mayor?

Suffice it to say, the SDK is for the most part.... dead.
"And she's not only merely dead, she's really most sincerely dead."

Be Well

I agree that the SDK was brilliant in its design, but poorly executed.

The philosophy of the SDK was basically Separation of Concerns, which is a thou-must for anyone who codes for a living. Any 'professional programmer' will tell you that breaking big functions into smaller functions is good for code re-usability.

However, the way it was coded (I agree that you shouldn't make edits to base classes) and its lack of popularity were not as was intended.