Here's another one

[Marked 197]

Also, though to add in the application of said tutorials, perhaps we could also create an "exercise" section (for each aspect) which gives the reader something to do with the knowledge they've gained, so like a script to create or an event or map or something...and then that would reinforce all the knowledge. There could also be several exercises categorized by how difficult or advanced of a concept. I think this is what made Leon's scripting class so useful and some of the better tutorials on the web, because the reader could then take the tutorial and apply it to something. We would just *hopefully* have a much broader array of tutorials, that covers more ground, and there could also be perhaps solutions to the exercises for anyone who gets stuck. And maybe even (if people are willing to of course) there could also be names of users who could act as a support group for specific categories that readers can contact for extra help or clarification? Or we could just get them to post their woes in the game support forums.

This idea sounds really interesting. But I don't quite get what you mean by exercise. Do you mean sort of like a test/question? We tell them what we want them to create.. oh, and we can give them readings by 'attaching' existing tutorials. I have to make this.... lol.

 

In terms of a support group, sure we could create a specific user group for the purpose of helping out with exercises. But what I've been planning from the beginning is commenting system. I try to integrate things as much as possible because we are using 2 different types of software for the site and forum, so I'm thinking of replicating the topic-view for the comments to make it look more sort of professional. The point of the application is to replace the tutorials forum and make the content more accessible, so I'd like them posted in as much as topics. I kind of replicated it in the scripts archives: http://www.rmxpunlimited.net/resources/scripts/item/party-changing-system?category_id=12

[kellessdee 48]

Yea essentially that's what I mean... like how Leon did with his class, except perhaps there could be a sample version for if people get stuck...Like they obviously don't have to do it, but will help reinforce the knowledge. So like a script they are asked to write or an event to make...I guess it would really only work with eventing/scripting, since with mapping, a lot of it is very subjective..I mean most people know a great map when they see one; but It would be kind of difficult to be like "make an awesome cave map" it won't really make a difference...but maybe if any great mappers wanted to provide examples, that could make more sense and perhaps be the reference...kinda like "here's an example of how a cave should be: notice it is very random and sporadically formed but not too irregular. it is filled with various rubble bla bla bla" or something... I dunno, the finished product would need refining and made more effective, but I definitely like your idea of integrating it with the forums, then people can post questions or issues and ANYone with the answer can reply. Makes much more sense that way.

[Marked 197]

Ah yeah, mapping would probably not be appropriate. The trick here is that we need to create a new type of page that is more than just "Do this", because that could simply be added at the bottom of the tutorial.

 

This type of thing needs various elements... For example:

1. details/explanation of the exercise (possible screenies/video - needs to be very precise)

2. tutorials/readings/references needed to complete the tutorial

3. hints (I'm thinking reveal more and more detailed hints in case they get stuck)

4. reveal the answer of how to actually achieve the exercise

5. a yes/no button on whether the person successfully completed the exercise, showing if its too hard or not

 

So thats how we could take a simple exercise beyond a 1-line challenge at the bottom of a tut. And what's also important are that excercises be kept as much as possible within the scope of the original tutorial, but balanced with what they're expected to know before the tutorial anyway.

[Razor 0]

I'm really trying to find a way to apply everything I'm reading in all of these tutorials. It's the same problem I originally posted.

 

The tutorials teach you how to make things like windows and variables and classes, but where do I put all of that code? The script editor already seems to be full of stuff even in a blank project.

 

Where do you use that kind of code if you're not making the game from scratch?

 

 

[kellessdee 48]

hmm i see what you mean. I dunno if this will help you specifically, but a quick laydown; when you start a fresh, blank project- what you see in the script editor is all the default scripts. generally, Game_something involves game mechanics, Sprite_something deals with sprites, Spriteset_something is for the set of sprites used in a screen (spriteset_map is for sprites displayed on game map, and spriteset_battle is for within a battle) Window_something is any windows used in game and Scene_something is for various scenes, which would be like either in map, menus or battles (or title screen would be a scene, etc)

 

Now there are a few ways one can work with scripts-modifying existing scripts (so going into the script and changing lines of code or adding extra code), overwriting scripts or aliasing scripts.

The way ruby is interpreted (like any interpreted language) is from top to bottom, and each specific script is read the same way (so if you look at the order scripts are arranged, they are originally interpreted in that order) and with ruby say you write "class Window_Base", then add another "class Window_Base" when Window_Base is first read, it will also find any other Window_Base classes, and if there are methods within in it with different methods than in the original class, they will be added to window base (as if it is all one class) or if there are 2 with the same name, the second one will always be used (the one that comes after, as like I said it is read from top to bottom) which is how overwriting methods work. Overwriting methods is a more predominant technique found when scripters write scripts for others to use, as it is much easier to tell someone to c&p script x above main (or below whatever classes/methods are being overwritten) then telling the user "oh find this portion, delete it, put this, etc. etc." And then aliasing is where a scripter overwrites a method, however they simply just want to add extra coding to that method, so they alias the original method first (thus essentially creating a carbon copy of that method) then overwrite it and within the method they can actually call the original method (thus invoking the original coding) then putting whatever they want into it.

 

Now the overwriting/aliasing methods is a little bit more advanced of a topic, so if you are just learning ruby it would probably be best to just modify existing scripts or creating your own classes. What you should be more worried about is inheritance (subclasses/superclasses). Basically if you want to write a class that behaves just like another class with extra functionality, you can make it a sub class of the original class. So for example you want to make a simple window that displays some info; it will probably do the same thing as Window_Base (the base window class in rmxp, which actually inherits from the hidden class Window; which simply creates a window out of the windowskin graphics) instead of rewriting all the code from Window_Base and inheriting from the Window class you can just create a sub class of Window_Base, which would "inherit" all the properties and methods existant in Window_Base. In ruby, the syntax for creating a sub class is "class Whatever_Class_Name < Super_Class_Name" for example class Window_Selectable < Window_Base

then in the "initialize" or constructor method (invoked by calling Class_Name.new) is the code that is called when creating an instance of the object or class. So when creating a sub class, to first call the parent's class constructor, put "super(parameters)" in the "def initialize". super is the keyword for calling the super class's method of the same name (thus creating an instance of the super class, except now you can add new functionality without overwriting the super class) If you create a subclass, it must be BELOW the super class in the editor, as the original class must be read by the interpreter before the sub class.

 

I would HIGHLY advise against "starting from scratch" in terms of the scripting of a game until you can fully understand how all the classes work. Sorry if those explanations are confusing as I am kinda half in the bag at the moment, but those are the essentials. So really, if you are writing your own classes they can go anywhere unless they are going to be a sub class of an existing class, than they MUST be below the super class. Or if your class creates any instances of an existing class, the script MUST be below the classes it uses.