Community Core Script

[Hudell]

Since there's no "JGSS scripts in development" section yet, I think this was the best place to create this thread. I wanted to create it before anybody started writing scripts, but I was ninja'ed by those 37 default scripts.

Anyway, what I want to suggest is the complete extermination of individual "core scripts". There was a big problem on Ace where each developer made their own "core" and used it on all of their scripts. Often making it completely incompatible with scripts from other scripters. And there's absolutely no need for this.

What I wanted is the creation of a community core script, to be used by all scripters who are active on this forum. This script would be hosted on github and discussed on this thread. It would be versioned, well documented and should be fully backward-compatible. Everybody can contribute to it, but the thread should discuss what would be added to the main script and what would not.

Individual scripts should be able to define what version of the community core it requires (and work with any version higher than that).

For now, this is just an idea and a wish I have. It's possible that it won't work, but I hope it does, so I'm already creating this thread to discuss how we should approach this.

 

[The Infamous Bon Bon]

I really like this idea.  I made a core script for my menu stuff and most of it was for defining Vocab and for drawing the stats that are drawn by default (X-Param, S-Param, etc.).  These are all basic things that in my opinion should have been in the default for Ace.

I hope that these will be unnecessary for MV as there seems to be a nice Terms Tab and they seem to have included more overall, but if not then I think a common Vocab should be included at the very least.

 

[nio kasgami]

Hum what I would likes would be a Cache garbage system for reduce Animation lags if they have c:

 

[Shaz]

It is a nice idea, but I can't see it happening.  Each scripter has their own way of doing things, and for those scripters who already have core engines, it will be much easier to just convert to JS than to convert all their scripts that require it to use a "common" core engine that may or may not do what theirs did.

And, as you say, there are already 37+ scripts that have already been written.

I would probably not take part in something like this because my time is already limited - having to look up common scripts and make sure mine work with it, or having to change my programming style to match someone else's, or having to simply try and understand someone else's style, all require time that I don't have.

Plus - github open to modifications by many programmers?  Too many cooks ...

 

[nio kasgami]

"Too Many cooks" oh noooo shaz what did you done...you will awake a horrible monster!

 

[Zeriab]

I would just follow Yanfly's core script.

 

[nio kasgami]

I would just follow Yanfly's core script.

Actually for myself I pretty much have a standalone coding style  soo....I will not follow any coding structure since I pretty much love to heavy comment my stuff lol 

 

[Zeriab]

Anyway, what I want to suggest is the complete extermination of individual "core scripts"

 

That is not gonna happen. There will be collection of commonly used function and bootstrapping/hooking scripts, i.e. core script, made by several scripters.

This doesn't mean that arranging a core script on Github where multiple programmers can add to the deposit is a bad idea. In fact, go ahead with the idea. Could end up being a nice tool

 

*hugs*

 

[Andar]

I agree with Shaz - it won't work because it ignores what core scripts really are.


Usually no scripter sets out and says "I want to write a core script" - some plan for it because they know from previous experience that they will end up needing it, but the core scripts themselves are not the intention.


Instead, some scripter find that they reuse self-written functions for a lot of their scripts, and they decide to place those reusable functions into their own scripts to have to add them only once - that's what later becomes the "core" script.


And what those functions are completely depends on the scripter and his/her scripting style.


Just look around:


Tsukihime programs in a modular style - there is no core script needed, but different base function system that have a lot of small add-ons and are never dependent on each other.


Yanfly's core is mostly bugfixes with only a few functions that he needs for other scripts.


Other core scripts provide a lot of basic mathematical functions to improve their specific engine, and those engines are often incompatible with other engines.


But what could be done (and would help a lot) as a community base is a script that contains needed bugfixes and general help functions. But such a base script could not be written without having access to the MV engine, because without such access you won't know if there are needs for bugfixes or what base functions are already provided.


So work can't start on it for the next three weeks...

 

[Sarlecc]

Well a nice thought if you have games only using a small percentage of that core script, then it rather defeats the purpose of having it in the first place. Whereas core scripts that script authors make generally are meant for use in their scripts vs other scripts.

 

[Tsukihime]

What criteria do we use to determine whether a piece of code should be included in the core?

There was a big problem on Ace where each developer made their own "core" and used it on all of their scripts. Often making it completely incompatible with scripts from other scripters.

How would you settle any conflicts where one scripter wants a particular thing to be implemented one way, while another scripter wants it to be implemented in a different way?For example, I like abstraction. I like to put a lot of unnecessary method calls in the off-chance that someone will probably want to use it and not overwrite it. If they have to overwrite it, we now introduce a point of incompatibility. If they can simply alias it and work around it...then we may be still good.

The chances of that happening in RPG Maker is pretty high, especially if you're dealing with a high-profile method like...I don't know, calculating damage:

# this is Ruby...but what the heckdef make_damage( ... ) res = make_base_damage( ... ) res = apply_modifiers( ... )enddef apply_modifiers(...) apply_elemental_modifiers( ... ) apply_critical_modifiers( ... )enddef apply_elemental_modifiers( ... ) # ...enddef apply_critical_modifiers( ... ) # ...endAnd so on and so on.When you could literally have just put it all in one method and be done with it.

 

[Shaz]

So work can't start on it for the next three weeks...

You could fill it with comments relating what SHOULD be included, and then add the code when MV is released.

The only "core" script I would have had need for in the past is reading database note tags.  

 

[Engr. Adiktuzmiko]

It depends on what kind of core you're talking about.


If it's like Yanfly's core which are mostly bug fixes, then yes it could be done to an extent.


There's also the other kind of core scripts, those that are specific to certain systems which are mostly collections of new codes that the scripter used several times so he made it into a "core" rather than having it in all his individual scripts. And that is something that you cannot/shouldn't remove.


If your goal is to avoid compatibility issues, you can't... Even if we make a rule in which only one script that modifies a certain feature can exist at a time, there's still the chance for incompatibilities as there can be several features using the same code.

 

[Zeriab]

Maintenance of the code such as refactoring and stuff will likely be required. If it's on Github we can have branches and with say some stable versions and more up-to-date but less stable versions.

If we just put all the code into the same repository without also cleaning it up then it will likely end up as a horrible mess.

As for what other scripters do. We cannot guarantee compatibility. Ultimately that is the game dev's responsibility.

*hugs*

 

[Galenmereth]

It's a horrible idea. Sure it would be nice to have a core of neat commonly used features easily available without the need to re-implement it in every script, but it will create complicated and unnecessary boilerplate bloat for the end users. It's just not worth it for anyone involved IMHO.

 

[Hudell]

Instead, some scripter find that they reuse self-written functions for a lot of their scripts, and they decide to place those reusable functions into their own scripts to have to add them only once - that's what later becomes the "core" script.

Well, that is exactly what I wanted to do with this script.

What criteria do we use to determine whether a piece of code should be included in the core?


How would you settle any conflicts where one scripter wants a particular thing to be implemented one way, while another scripter wants it to be implemented in a different way?

I created this thread with the intention of discussing those details
Well, the idea had mixed reactions, but most people who liked it are the ones who do not have access to MV yet, so maybe there's something there that I don't know?


I guess I'll have to wait for it to be released and then organize something on a smaller scale.

 

[Tsukihime]

I created this thread with the intention of discussing those details

Do you have any suggestions?


I have for example 3 core scripts, each dealing with a certain set of classes.


They only came about because I wrote a couple scripts and found that it would've been really nice if a certain set of methods were more abstract. Unless you were writing scripts that touched those methods, the core scripts are pretty much useless.


Instead of offering one big "core" script, I offer smaller scripts in an attempt to minimize compatibility issues: people don't need to download something they're not going to use.


With the plugin manager, this should be much easier because even if they download all of the core scripts, they can just check off which ones they don't need.


And I'm sure there would be some scripts that would be useful as a core script (eg: damage calculation)

 

[Hudell]

Do you have any suggestions?


I have for example 3 core scripts, each dealing with a certain set of classes.


They only came about because I wrote a couple scripts and found that it would've been really nice if a certain set of methods were more abstract. Unless you were writing scripts that touched those methods, the core scripts are pretty much useless.


Instead of offering one big "core" script, I offer smaller scripts in an attempt to minimize compatibility issues: people don't need to download something they're not going to use.


With the plugin manager, this should be much easier because even if they download all of the core scripts, they can just check off which ones they don't need.


And I'm sure there would be some scripts that would be useful as a core script (eg: damage calculation)

Yeah, I was just thinking about that: grouping functions with similar purposes on smaller core scripts.

 

[GethN7]

I have a related but slightly different idea. Provide a "modular compatibility core" that allows different "cores" to play nice with one another.

It would require a lot of cooperation and constant maintenance, but once could have their cake and eat it too this way.

 

[DarknessFalls]

Since there's no "JGSS scripts in development" section yet, I think this was the best place to create this thread. I wanted to create it before anybody started writing scripts, but I was ninja'ed by those 37 default scripts.

Anyway, what I want to suggest is the complete extermination of individual "core scripts". There was a big problem on Ace where each developer made their own "core" and used it on all of their scripts. Often making it completely incompatible with scripts from other scripters. And there's absolutely no need for this.

What I wanted is the creation of a community core script, to be used by all scripters who are active on this forum. This script would be hosted on github and discussed on this thread. It would be versioned, well documented and should be fully backward-compatible. Everybody can contribute to it, but the thread should discuss what would be added to the main script and what would not.

Individual scripts should be able to define what version of the community core it requires (and work with any version higher than that).

For now, this is just an idea and a wish I have. It's possible that it won't work, but I hope it does, so I'm already creating this thread to discuss how we should approach this.

This is a horrible idea because it limits peoples imaginations. You might tackle a problem differently then I, as I am - and others are - more experienced programmer in regards to Javascript.

This core script idea, unless it was like C's main library or C++'s main library or something like that, is a bad idea ...