[JimKurth]

Hey there.

Well, I've tried finding a lot of programming resources for scripting and read as much as I could and they still don't get to the point or help you out much unless you want to work your way around the mountain to get where you want to be. This is my opinion and lesson on how a scripting technique should go for RPG developers:

Have multiple structures (header block, location block, variable/value/command blocks). Here's what I mean (in QB-pseudo terms):
TYPE Header
Id as STR * 3 '// SCRIPT file extension reference. (e.g. SCR)
Chapter as INT '// Id to identify where in-game script lies
END TYPE

DIM...
LocBlk as STR * 3 '// CHR$(251) + 2 bytes to id the location
VarBlk as STR * 3 '// CHR$(252) + 2 bytes to id the variable
ValBlk as INT '// This is the value to put with variable (0-32767)
CmdBlk as STR * 3 'Chr$(253) + 2 bytes to id the function

The CHR$(251/252/253/..) are used to identify that the next 2 bytes are a location, variable, and command. The next 2 bytes can be any value from 0-250 (251 values total) and can be used like an array format for more possibilities:
byte2 = 0-250
byte3 = 0-250
LocBlk = CHR$(251) + CHR$(1) + CHR$(252) will be different than CHR$(251) + CHR$(252) + CHR$(1).

That means if I wanted to find location 4F in chapter 2, I open up script file that will read Chapter 2 in the header, and I look for CHR$(251) + "4F" then I'm there where I want to be.

VarBlk and CmdBlk are used as a reference to variables used when programming (HP, MP, Location_X, Location_Y, NPC_Frame, Move_NPC(), Load_Town(), etc.):

Just have a routine that breaks down code to sections...
Byte2 of CmdBlk could be whether it's a graphic function or a data-change function.
Byte3 could be the type of function that's apart of graphics if Byte2 referred to a graphic function to use. Then you have 250 possible commands per function type (array use again)

ValBlk would always come after the VarBlk and there's no need to decode it. It's a 2-byte integer value.

All you need to do is look for these Id bytes (chr$(251-255)) and then you'll know what the next 2 bytes are.
Just use a DO loop to keep going back and don't look at the file in terms of (1 location, 1 variable, 1 value, 1 command). Write code to accept anything. 1 location (I use) is similar to the { } grouping in C programming (1 location has multiple variable value changes, and commands). I use a flag to identify where to stop and return to process (so not everything happens at once) like an escape key (CHR$(255) for example).


---
When you put all code to do this, you can read in a script that would look like:

·4F√0A80√3C21ⁿFB

Could be read in as:
LocBlk: 4F
VarBlk: 0A (Could be MP)
ValBlk: 80 (128 in decimal)
VarBlk: 3C (Could be HP)
VarBlk: 21 (33 in decimal)

CmdBlk: FB (could be Add_Stat() or Change_Stat();)

Don't tell me you can't program a script like this. Of course I know that and below you'll see another post by me on tips to write a script encoder so that you can make your script in any language you choose.

If you find this useful, great. If not, read other articles.

-James Kurth

[JimKurth]

Here's where your programming knowledge and design will kick in because I won't write it for you, but will guide you on how I'm writing mine:

First off, my source code to my RPG has 3 character acronyms for certain commonly used words (Spr = Sprite, Npc = Prop, Obj = Object, Chg = Change, Pro = Property, Tmp = Temporary, Var = Variable, Clr = Color, Scr = Screen, Dsp = Display, etc....). When I'm writing my script language, I use the same function names that I program with because I'm used to typing those names to do those functions. So, my script rough draft would look like this (written in ANSI text format from Notepad or Edit.com):

Var1 = 0
Var2 = 1
SetPagPro
Var1 = 23
Var2 = 6
BldDlgBox
TmpVar1 = 121
DspMsg 26 "yKAIRE:y\WHAT DO YOU MEAN?"

So, I read in the data 1 string at a time. "Var1" okay, is there a "="? YES! So let's grab that value and store it in Var1, which will be coded as: "√01"+CHR$(0)+CHR$(0). Write it to the file at current_location. NEXT reading... "Var2". Good. Same thing, but with a value of 1. So:
"√01 √02" + CHR$(0) + CHR$(1)

"SetPagPro". Okay, so we know that we want this to be "ⁿ01" or whatever. So let's write it at next byte position in script final form.

Current contents of script file:
"√01" + CHR$(0) + CHR$(0) + "√01" + CHR$(0) +CHR$(1) + "ⁿ01"


You get the idea.... just have a separate routine to check the function id's, variable id's, etc. It makes it easier to recheck in the event of problems. And also, *print out* your function id's and variable id's on paper. That way you can easily check them out. Don't forget to add that to your design document so employees or others can work on it effectively.

Here are some more tips from me when writing this encoder:
*No need to develop a nice looking GUI for this. You're using it, so maybe like after 10/50/100 commands are written, you could print a character on the screen to avoid confusion if it's working and will assist in troubleshooting any problems.
*Don't make files too big in size. That's why there's a chapter label in the header. Think about it like a tabbed notebook. You can jump from 1 part to another quickly with tabs and go to where you need to instead of search the entire notebook for 1 specific sheet of paper.
*You could use a byte indicator before text strings (for the length of the string to grab), or use a variable and a value to reference another file containing text strings (what I do).
*Don't use functions that are hard to grasp: (if you have a DrawCharacter and a DisplayNPC function, it would be confusing whether to write Draw or Display before your function names). Try and use same acronyms for the same thing (I use Bld for Build/load/construct. And I use Drw as in, 'DrwPxl()' or 'DrwObj();' and not 'DrwPxl' and 'DrawPixel();'.)
*Don't just copy these, experiment to feel what is good for you and write your own script encoding/decoding functions. It also helps to write what you seen yourself and study it then find ways to improve and build upon it, which then makes you develop your own routines.
*There's a time when you have to take your hands off the keyboard and save it as it is and use what you have as your final piece. Are you building an RPG or a great tool for others who are creating games?

--
Did I get these from a book? No. Did I get them from other resources? Sort of. I read articles on scripts and I studied it myself with pen & paper and found errors and found ways to easily accomplish this. To my standards, it's efficient and I am satisfied with my results.

Well, I hope this helps. If not, thanks for reading. If it does, GREAT! Hope you're on your way (I could've used this knowledge years ago)

-James Kurth