Home
Help
Search
Calendar
Login
Register
Please
login
or
register
.
1 Hour
1 Day
1 Week
1 Month
Forever
Login with username, password and session length
News:
Click here to join us on IRC (#charas on irc.freenode.net)!
Charas-Project
»
Game Creation
»
Requests
»
RPG Maker Programming
»
DB's guide to coding
« previous
next »
Print
Pages: [
1
]
Author
Topic: DB's guide to coding (Read 2251 times)
DragonBlaze
A Wild DB Appeared!
Royal
Posts: 3,329
DB's guide to coding
«
on:
August 25, 2006, 03:32:37 AM »
DB's guide to Coding
Err well, I wrote this last night when I was really tired and bored. I don't know if anyone will be able to understand it, and I am sceptical if it'll actually be of use to anyone. But yeah, heres my guide to scripting and coding in rm2k3 and rm2k. Its aimed at coding systems like a cbs or cms and stuff like that, but it should apply to pretty much anything.
This guide to scripting isn't really going to cover any specific scripts at all. Rather, it'll cover "how-to" script something. Once you understand how the scripting system in rm2k3 works, and how to think of a code, you'll be able to code just about ANYTHING. This tutorial will be devided into 5 sections, breaking down a code, variables, algorithms, forks, and tips and tricks.
Breaking down a code: For any larger code, you have to plan it. You cannot simply start coding, and have everything fall together, it really doesn't work that way. Even with really simple codes, you have to think of what the code is going to do, and how to script it.
In order to tackle a large code, you have to break it down into smaller sections that are managable. Take a CBS (custom battle system) for example. If one were to just say to themselves, "I am going to code a CBS", they'd be lost. Unless you're gonna work on a large code in sections, you're not going to be able to code anything advanced. So before attempting any larger code, think to yourself (or put it down on paper) of what your goal is (lets use a CBS for example). After you have your goal, think of the differant sections/functions would be involved in making your goal. So right now, I want you to think of all the differant parts there would be in a CBS, one example would be displaying the health of the character(s). Think to yourself what other parts are in a battle system, don't worry on 'how' to code them or anything at this point. After you thought through it a while, read on.
.....
.....
Some of the parts of a CBS include, Getting the stats from the heros, displaying stats, displaying heros, displaying enemies, displaying menues, attacking, enemy AI, and theres more. These functions too can be broken down into differant parts, lets take attacking for example. There are two parts involved in attacking, finding the battle damage, and then displaying the battle damage.
So now, instead of trying to code an entire CBS, right now you can worry about something much more manageable, and thats finding the battle damage. This involveds an algorithm, and will be explained later. Once you have the damage, you can move on to the next part, and thats displaying the damage.
Lets take another part and break it down. Displaying the HP. In order to display something that is based off of a value (hp in this case) we have to find the value. So the first part would be finding the HP, the second part would be actually displaying the hp. As we go along, you'll learn that displaying the HP will be broken down into two more parts, splitting the hp into single digit numbers and then using those numbers to display each digit with forks and pictures.
Summery: In a large code that has multiple parts to it, it is best to break the code down into smaller managable sections.
Variables: *Most* larger codes consists mainly of variables and forks. Once you discover the relationship of variables and how to put them to use with forks, you'll understand scripting a lot more.
First off, pretty much everything is done by variables, and pretty much everything has a variable value. Variables are values that can change. HP is an example of a variable. It is best to think of things not as "things" but as variables. As variables, things can be manipulated, worked with, and tested, as "things", not much can be done.
With rpg maker, in order to turn "things" into variables, you have to set the variables equal to the value of the "thing". Lets say the "thing" is HP. We would use the variable options command to set a variable equal to HP. It is a VERY good idea to look through the variable options command and see what things can be turned into variables.
This may be a little complex, but bare with me. Possition. If you want to trigger something based on one events possition to another, how would you do it? Remember what I just said about "things" and "variables". If you think of the possition of these events as variables, this won't be much of a problem. As variables, you can test the possitions. Variables are numbers, thus the greater the differance of the variables for each event, the farther they are away. The smaller the differance, the closer they are. If the variables for the two events have the same value, then they have the same possition.
You can also think of switches as variables. In actual scritping, switches are just variables, if the variable value is 0, it is like the switch is off, and if the value is 1, its like the switch is on. Switches are ONLY good for if you have two outcomes, if you have more than two, you want to use a variable. If you want to determain if a hero is dead or not, use a switch. If you want to see how much life the hero has left, use a variable. In more practical scripting, if you have an event with 5 pages, it is best to use a single variable for all the pages instead of 4 or 5 switches.
Algorithms: Algorithms are the hardest part of any code (in my opinion). An algorithm is a code that basically determains the value of something based on the information you give it. To do this, most algorithms use algebra to find the value of an unknown variable. It sounds complex, but basically its just math that gives you a value. A lot of times algorithms don't have to be used, but it makes it much easier on you if you do use them. Lets say you have a guage that shows how much hp you have left. You *could* program the gauge to change if hp was 1 or 13 or whatever. But then you would have to redo if for every level the character has a differant amount of HP. A better way to do this would be to use an algorithm to determain the percent of hp the hero has, and then display the guage based on the percent rather than the actual amount of hp.
So lets start with that algorithm. We want a code that gives us the percent of life left. The first thing we have to do is inventory what we got. Find out what we have to work with. If you think of what percent is, its the amount left of the whole. If there are 8 pieces of pizza in all, and 4 are gone, 50% of the pizza is left. So what we have to work with is the heros complete life, and the heros current life, that is enough. Right now, I want you to think of how to find the percent, if you've taken algebra, you've seen this before, if not, you probably won't get this.
...
...
If you thought of cross multiplying, you were right. For those of you who don't know, cross multiplying is the term for the metheod we'll use to solve this. Lets say the hero has 2 life left our of 10. And we're trying to find the percentage of that. Heres what the coding would look like.
[percentage] = hero current life (2)
[percentage] times 100 (percentage)
[percentage] / hero complete life (10)
we have 2, times 100 = 200, divided by 10 = 20.
Thus, we'll get 20% as the amount of life left.
Whenever you want to find a value that you can't get by using the variable options command (percentage for example) you need an algorithm to find the value. You need to think of what it needs to accomplish, and what you have to work with.
Battle Damage is another example of an algorithm. I'm going to let you worry about this one. Think of what we have, what factors do you want to determain your battle damage.
The two you probably chose would be hero power and enemy defence. You can also figure in level if you want, or whatever factors you want. Now think of how you are going to take those values and turn them into damage.
First, you'll probably want to set a variable (battle damage) equal to the heros attack. If you would devide it by the enemies defence, you would probably end up with a value of 0. So now maybe you want to multiply battle damage by attack again before deviding it. See what happens. Build an algorithm that works for you.
Some algorithms are just too hard to think of on your own. Usually, you'll be able to find tutorials for these on the internet though. A good example would be a digit spliting algorithm. If you want to display hp, damage, or another 4 digit number, you would need 10,000 forks without an algorithm. If you used an algorithm to split that 4 digit number into 4 single digit numbers, you would only need 40 forks, and it would be much more managable. In order to do this though, you need ot know how to use the modulus function. And unless you took computer programming, you probably have no idea what MOD actually does. Basically, what it does is finds the remander value after dividing. Anyway, such codes may just be beyond you. Then you can look around and find some answers. Heres the digit splitting algorithm, as it is used very often in custom menu and battle systems.
[1000 digit] set equal to [number]
[100 digit] set equal to [number]
[10 digit] set equal to [number]
[1 digit] set equal to [number]
[100 digit] MOD 1000
[10 digit] MOD 100
[1 digit] MOD 10
[1000 digit] - [100 digit]
[100 digit] - [10 digit]
[10 digit] - [1 digit]
[1000 digit] / 1000
[100 digit] / 100
[10 digit] / 10
if the number is 1234
1000 digit will be equal to 1
100 digit will be equal to 2
10 digit will be equal to 3
and 1 digit will be equal to 4
Summery: When you break down a code section, and you need it to find a value for you, think of what you have to work with, and do a little math to find an algorithm that'll give you the right values.
Forks: Forks (also known as conditional branches) are a major part in almost every big system. The main reason for that is because rm2k3 doesn't have arrays (don't worry about what that is). Variables and forks work hand to hand with eachother to do most of the work in a large system. After you find a value with an algorithm, you need to put it to use, and chances are, that'll be through forks.
Let me explain what a fork does. It preforms an action if a condition is met or not. Usually this means if a variable is a desired value or not.
When breaking down a large code, most sections will probably consists of an algorithm to find a variable, or forks to put that variable to use. Lets go with displaying HP. The two parts of that would be finding the hp percentage, and displaying the gauge. Finding the hp percentage is an algorithm (explained above), and displaying the hp guage is a bunch of forks. An example
If [HP percentage] = 0
-show empty gauge bar
If [HP percentage] = 10
-show gauge at 10%
...
if [HP percentage] = 100
-show full gauge.
Chances are, if you need to display something, it'll be with a bunch of forks. You have a variable, each differant varariable value stands for a differant stat value, like hp, and since each differant stat value will need a differant picture (if gauge is full it needs a picture of a full gauge, and if guage is empty, it needs a picture of an empty guage), you'll need a differant fork to display a differant picture for each differant variable value.
Forks are also used for a lot of other things. If you want to check to see which skills your hero knows, you'll need to make a new fork to test if the hero knows each skill.
Tips and tricks: In coding, you basically want to find a value, and do something with that value. In almost every code, thats how it works. If you break it down and see what you need to find and know what you need to do with it, and you know how to find it and how to put it to use, you can pretty much code ANYTHING.
When displaying pictures for guages, stats, or menus, it is best to display them at the loctation of variables rather than numbers. If you do this, you can change the location of the pictures by changing the value of two variables, if you use numbers, you have to go through every picture and change it, then if you realize that you want to move it back, you have to go through everything again.
When you plan out something and break it down. Think of what needs to be done first. Its kinda up to you, but if you're making a cbs, it wouldn't make sence to start with the enemy AI. I like to start with showing all the stats, maybe you want to start with the menu.
Always be sure that one script of yours doesn't affect another unless you want it to. If you have two scripts working at the same time in a system, they can cause problems.
Write down codes you don't know how to do on paper. I find planning stuff on paper works really well. I wanted to make a scrolling menu, but I had no idea how to do it. So during chemistry class, I started writing down what needed to be done, it worked.
Leave comments in your codes. Sometimes on longer codes, you may forget what you did or why you did it, if you leave comments in your codes, you'll know what it does and why it does it.
Practice, practice, practice. Try hard things. I had no idea how to make a cbs, but one day, I wanted to, I experimented, and through my experiments, I got a lot better at coding.
Remember, if you 'call' a script, the script that you call it from won't turn off untill the script that it calls turns off. That can cause a lot of problems or work to your advantage.
When scripting, make sure you keep the big picture in mind.
When using a lot of pictures, write down which picture numbers are used for what.
Just have fun.
The end.
Logged
Hell Yeah! Just recovered all my old rm2k/3 games from my 10 year old, broken laptop hard drive that had been formatted and had a new OS installed on it. Oh, and I did all of this from my phone. WIN
Prpl_Mage
Administrator
Sage
Posts: 7,644
The Administrator Mage
(No subject)
«
Reply #1 on:
August 25, 2006, 04:22:20 AM »
Wow...
This actually explained some things I was about to ask.
Well I guess that I have to learn how to use those algorithms correctly.
Logged
Cool RPGM Project!
Sprite till you die
Oh my god, this was ...10 years ago...
EXO Muffin
Acolyte
Posts: 466
(No subject)
«
Reply #2 on:
August 25, 2006, 04:42:23 AM »
I always wondered how to split a number into multiple variables. Thanks.
Logged
Ladies and gentlemen,
this
is Chewbacca. Chewbacca is a Wookiee from the planet Kashyyyk. But Chewbacca
lives
on the planet Endor. Now think about it;
that does not make sense!
aboutasoandthis
Exemplar
Posts: 1,915
Talking sucks.
Not here to stay. School!
«
Reply #3 on:
August 25, 2006, 10:50:02 AM »
This falls somewhere between
a very nice and useful tut
, and
it's completely useless
. I think it's because you released it after I figured out how to code my CBS styled DBS and my CMS.
Good Job Anyway!
Logged
My pokemon bring all the nerds to the yard, and they're like you wanna trade cards? Darn right, I wanna trade cards, I could trade this, but not my charizard.
WarxePB
Action Sue
Royal
Posts: 3,601
What killed the dinosaurs?
(No subject)
«
Reply #4 on:
August 25, 2006, 02:08:50 PM »
Hmm, I'm gonna move this to RM Programming, but that doesn't diminish this tut's awesomeness in any way. Modulus would make things so much easier!
So yeah, moved to RM Programming, and sticky'D.
Logged
Blog:
The Gigaverse
Twitter:
Initial Chaos
DragonBlaze
A Wild DB Appeared!
Royal
Posts: 3,329
(No subject)
«
Reply #5 on:
August 25, 2006, 02:23:47 PM »
Wow, I am shocked that someone actually found this semi-useful :p
Logged
Hell Yeah! Just recovered all my old rm2k/3 games from my 10 year old, broken laptop hard drive that had been formatted and had a new OS installed on it. Oh, and I did all of this from my phone. WIN
Linkizcool
Doesn't exist for official purposes.
Exemplar
Posts: 1,290
I am Canadian.
(No subject)
«
Reply #6 on:
August 26, 2006, 03:24:22 PM »
It was pwnage useful, except I already wrote and planned my coding on paper
Logged
Arcanagirl
Game Designer!
Zealot
Posts: 514
I love games, creating things my way...RPGmaker lover!
(No subject)
«
Reply #7 on:
September 02, 2006, 06:13:59 PM »
This is very helpful tut Dragonblaze, many game designers will need to know this for their CBS or CMS or ABS, etc. It wasnt useful to me cause you already taught me to digit split lol. But this code can even work for things like splitting attack and def in a status menu.
I use this code for everything in my game that has to show pictures. In my status menus, on the maps where Lp/Sp, and soon Wait bar.
Great job Dragonblaze, and I understood it completely, so if I can understand what you wrote, anyone can, sense I am the densest person on charas
Logged
~Lands of Lunori~
Trailer
EXO Muffin
Acolyte
Posts: 466
(No subject)
«
Reply #8 on:
September 02, 2006, 08:51:28 PM »
No, I am! Also, this isn't stickied?
Logged
Ladies and gentlemen,
this
is Chewbacca. Chewbacca is a Wookiee from the planet Kashyyyk. But Chewbacca
lives
on the planet Endor. Now think about it;
that does not make sense!
DragonBlaze
A Wild DB Appeared!
Royal
Posts: 3,329
(No subject)
«
Reply #9 on:
September 02, 2006, 08:57:27 PM »
We don't sticky tutorials anymore (thanks to me
) Instead, we have one stickied topic called "recomended tutorials" in both rm programin and the tutorials forums. So this thread was 'stickied' meaning it was added to the list of recommended tutorials.
Before we had the recommended tutorials, we had a lot of stickied topics that took up a lot of space so that you had to scroll down a ways to get to new topics. This way is much more clean and efficiant.
Logged
Hell Yeah! Just recovered all my old rm2k/3 games from my 10 year old, broken laptop hard drive that had been formatted and had a new OS installed on it. Oh, and I did all of this from my phone. WIN
WarxePB
Action Sue
Royal
Posts: 3,601
What killed the dinosaurs?
(No subject)
«
Reply #10 on:
September 07, 2006, 11:28:53 AM »
^ Bingo. So now I'm just saying "stickied" when adding to the recommended tutorials, because it's essentially the same thing.
EDIT: Whoops, that was a bit of a kick. Well, we'll say... I'm gonna finish up a couple of tutorials tonight, so DB and Jenna's awesome tuts won't be alone.
Logged
Blog:
The Gigaverse
Twitter:
Initial Chaos
Print
Pages: [
1
]
« previous
next »
Charas-Project
»
Game Creation
»
Requests
»
RPG Maker Programming
»
DB's guide to coding