Standards of Script/Plugin 'Completeness'

[Kayzee 4,032]

Today I was checking out the completed script forums and...  Okay before I say anything else let me make one thing clear. This has very little to do with the function of any script it's self, nor am I accusing one of breaking some rule or saying that there should be any particular rules about this subject. This is not an attack on any script's author, an indictment of the community, or anything like that. This is a theory and development post, to talk about theory and development. Just wanna make that clear. Also, this only really applies to scripts being publicly released in any case. I say all that because, honestly, if some of the scripts there were my scripts they wouldn't meet my standards for 'completeness'.

 

Mostly due to lack of a comment block describing/documenting the script in some cases. Keep in mind though I am very picky about my own scripts and that might not be a good thing. It's one of the reasons I have very few posts in the completed script forum actually, because I don't really think of very many of my scripts as 'complete'. I know it's kind of a pain to document stuff and I don't blame people for not wanting to bother. Having a demo is nice, but I don't feel should be necessary to understand how a completed script works. There is also the question of how well tested a script is, but that's not so easy to see. And don't get me wrong, 'incomplete' scripts are not bad to share or anything, I share mine all the time. I just think there is kind of more of an unwritten 'use at your own risk' attached. I think this applies to MV plugins just as much as VX Ace scripts, and indeed any publicly released snippet of code really.

 

I am not sure it's all that important, but I feel there is a discussion there. So, what do all of you think?

Edited June 10, 2017 by KilloZapit

[Shiggy 630]

To be fair, i do consider it lack some quality standards as well (most of my scripts do, I lack the patience and motivation to polish my works as much as famous scripters) but there is only one place in the forums to post scripts.

I'm all for a forum section for unpolished scripts (but we may end up the only two people using it ^^ )

I usually have no demo and a small description. In this case, it would be quite long to explain so I made a demo instead.

[Kayzee 4,032]

Hehe, I just got done removing all references to your script so not single you out you know... You aren't the only one who does that I am sure. But yeah, not sure if a 'script snippets' forum/thread or something like the gallery would be a good idea or not, but it sounds neat! I mostly post my scripts in request threads if it's something someone is asking for, or other threads when relevant. I used to do it a lot in my blog a bit. One of the reasons I have the list in my signature, cause they are all over the place.

Edited June 10, 2017 by KilloZapit

[Traverse 144]

I'm pretty sure the "Complete" part of the "Complete Scripts" forum name is meant to refer just to the functionality of the scripts, whatever documentation they have available be damned. Mostly because the reason most people go there is to find scripts capable of providing certain (allegedly) functional features ripe for installation in their game just as soon as they slap it into the script editor/plugin folder. Once that dream crashes and burns, that's when they start going to the Support forum yelling for a lifeboat.

 

Bearing the purpose of the name in mind (that is, to direct laymen to that honeypot dreamland of sweet, sweet scripts) I think the standard is fine. Sure, it's possibly the lowest bar you can get, but I'd wager the majority of people trafficking that forum barely even read through the headers of what they download. Much less the documentation for each and every class and method that is altered.

 

Also, if and when shit hits the fan and you find out something is seriously wrong because of the script, I have my doubts that the documentation would actually help all that much. You might think so, but then you remember that the documentation was written by the scripter, based solely on his own understand of what he was doing. The same scripter who you now clearly see has royally f**ked up something in his own script.

 

If it was simply because the scripter had no idea what he was doing in the first place, his documentation is not going to help (in fact, it will probably just screw with your mind and your own understanding if you're trying to solve the problem). And if he's using a chunk of code lifted either from someone else or the engine itself, then said documentation is probably just going to read "Foo Method - Copied from Class Scene_Bar" or something anyway. If it was because of an simple oversight like a typo or a missing end statement or something of the like, the documentation might be correct but will provide absolutely no help in resolving the problem regardless.

 

And finally, remember, if you're actually reading the documentation and can make any sort of sense of it, you're likely able to code and read the code directly and thus figure out what the problems are for yourself. Personally, considering the userbase of most of these scripts, I'm not sure a high standard of documentation completeness would result in anything more than extra work for scripters. A good number of whom, in all honestly, probably couldn't tell you exactly what their copy-pasta'd spaghetti code did with particular accuracy anyway (no offense to the people who do actually have a good understanding of their own code).

Edited June 10, 2017 by Traverse

[Kayzee 4,032]

Well, not all scripts really need documentation, nor do all users need to read it, but personally I like to take a kind of minimal effort at making sure my scripts are as usable as possible before I call it complete. Partly it's often less about the documentation it's self as it is about having a sanity check to make sure you really understand your own code and what features are needed or should be removed, and documenting helps to do that. It sometimes allows for easier maintainability and updating code over time.

 

You could call it a standard of 'professionalism' but I often hate using that word, because it's really an appeal to elitism more then anything else, and that's really not my point. I guess I could go with 'trust'. Messy and undocumented code is always going to seem less trustworthy in my eyes because it just doesn't seem like as much care is put into it. And not all scripts have to be a masterpiece or anything, just that I think effort put into formatting and documentation and stuff makes it seem like more effort was put into checking it over, even if that is a false illusion. No one's scripting is always perfect on the first release anyway, but a little extra makes it seem like you care, ya know? Also, I am not even talking about explaining every line or method, just basic explaining basic functionality in the script header. Real 'professional' programing types are often a lot more picky then even me when it comes to this stuff, but then again they usually play with enormous codebases maintained by large teams.

Edited June 10, 2017 by KilloZapit

[Perang Cemen 188]

I'm just wondering...

did Documentation about Compatibility is included in standard of script?

 

because almost all of my script always cause other script error, and when they ask me to fix it I'm really really lazy to do it, just wonder how many people made script in the world and they ask me to fix it one by one...

So in the end I removing all references of my script, if Compatibility isn't included in standard of script then my script is standard script even have lot's bug.

Edited June 11, 2017 by Perang Cemen

[Kayzee 4,032]

It's still worth thinking about compatibility in a more general sense at least. It often helps to look into things like the best place to put your script in the script list (for VX Ace), how the names you use could conflict with other scripts, when to use aliasing and subclassing instead of overwriting methods, how your code changes the expected behavior of things that other scripts may rely on, how much of what you are doing with a script is really important to a script's function, whether when dealing with a long monolithic script it would be better served split up into smaller scripts, and if you need to how to detect and make special logic for particularly popular or well understood scripts.

 

But going out and rigorously testing and documenting how well they get along with every other script (or at least a huge list of the most popular ones)? No, I think that's a step too far to expect. If it requires another script to work you should say so, but if you keep getting complaints about such and such other person's script not working with yours, well it might be nice to say but isn't not really your duty to make sure every script works together or anything. ABS scripts are the worst in this regard because they are often very large, barely compatible with anything, often crappy and buggy, and yet everyone seems to try and use them anyway for some silly reason. I don't have time to dive into crappy ABS scripts for the sake of making every script compatible with them people!

 

That's not even getting into the chaos that can happen when people who don't know any scripting at all jam 30 complex scripts together in one project. This is really why most bigger game projects that use scripts should always have a coder with at least a little experience, because sometimes the smallest thing like putting two scripts in the wrong order can break a project. I have no idea how well MV plugins fix some of these issues. I could imagine a formal plugin system with stuff like listing explicit prerequisites to figure out load order and defining their own namespaces and other stuff would really help. Heck I might be able to code such a system for VX Ace if I wanted, but not sure anyone would use it.

Edited June 11, 2017 by KilloZapit

[PhoenixSoul 1,404]

I would use such a system.

 

I'm a novice at RGSS, honestly, but I was able to figure out how to redraw the lines inside one window so that the currently equipped items in the Status Window would not overlap into the biography text below. It works even better if one resizes the game window to 640 x 480 (which it should be from the get-go because the oddball resolution doesn't make sense to me at all).

 

What I'd like to do is have those equipped items be shown in two columns but...

 

That's beyond my ability at the moment...

 

Also, using Arial as a font shows blocks if someone used the Return key in the Database editor, but why is that?

[Kayzee 4,032]

Making such a system isn't really going to solve any underlying problems though. It would be at best another set of rules and syntax to learn.

 

I know the font thing is a known issue, I think there is a fix somewhere. I am not sure but I assume it might have to do with how new lines are two characters instead of one on Windows systems. Though that shouldn't end up being a problem since RPG Maker VX Ace is a Windows program, I think the programmers just forgot the carriage return character existed and it only shows up when using another font because the fonts they tested leaves it blank. Fairly easy to strip out the extra character before displaying the text if true.

 

Also, by the way, the Windows way is actually correct by ASCII standards. A 'carriage return' to return to the start of a line and a 'line feed' to advance to the next line. I love Unix and it's descendants, but man. that whole dropping of the carriage return thing and using only a line feed in text causes no end of heart ache for everyone, even if it's true that use of one without the other had all but vanished even that early so it saves a tiny bit of space to drop one. Apple computers used to do it too, only they dropped the line feed instead (including Macs up until Apple took over the Unix variant NeXTSTEP and started basing new versions of MacOS on that). Guess that was a bit of a tangent, but it's a fun bit of history.

Edited June 12, 2017 by KilloZapit

[PhoenixSoul 1,404]

Next on my agenda is a side-scrolling system...

 

I have no clue as to how to go about this one though...

 

Anyway, yeah. If the syntax system seems mundane, it likely is.

[Cookie Ninja 374]

When I script, I rarely run into name-space problems since I write all the functionality outside the base-lib in a self enclosed module or class. Then (if needed) try to surgically attach my code as seamlessly as possible to whatever part of the base-lib they will be interacting with. As for commenting, I see it as a way to taking down notes if I ever need to tinker with it again. I don't think a script can ever be considered complete. Writing a script is like writing a page in a book. Even if you move on to the next one, in the back of your head the previous pages linger, thinking about what changes, additions and improvements could be made. It just happens to be very rare that I ever go back and apply the ideas I came up with. Every day has new horizons to explore! xD

 

Anywhooo, I never consider my work to be complete, always room for improvement. It begs the question, at what stage to you finally share it with the world?

[Kayzee 4,032]

Hmm? I will have to see one of your scripts sometime to see what you are talking about, it seems interesting. I have to admit that in general I have not found namespace problems to be that big of a concern. I don't remember ever having problems with two scripts naming something the same. After all, if two scripts name a class or method the same thing they usually also share the same functionality and it's unnecessary to install both at once. But it is always something I feel is lurking behind the scenes and could make really baffling bugs.

 

As for a script never being complete? Yeah, that's kinda why I put the little air quotes around 'completeness'. There is eventually a point where active development of the script is no longer necessary, where most of the reported bugs that can be reasonably fixed have been and the script has most or all of the general features that people want or expect, and maybe at that point you can reasonably call a script truly done with baring finding some deeply hidden bug or having a request for a feature you didn't think of. But it's rare a script ever gets to that point really. Of my scripts there are a few I think of as more or less finished, but I am sure I could come up with some fix or feature if I really looked at them.

 

Perhaps instead of 'complete' I should say 'ready to be officially publicly released and used in other's game projects'. That's really what I am talking about here, if a script is really mature enough that other people can make use of it, even if (maybe especially if) they are not scripters themselves. It doesn't need to be perfect to meet that standard, just functional enough to be useful and polished enough not to cause a billion problems. I mean, not all scripts might be intended to be 'released' in this manner, and that's okay. But to me, most of my idea of what should go in the complete scripts/plugins forums is filtered through this lens. But maybe that's just me, and that's fair enough.

Edited June 13, 2017 by KilloZapit