How to make your RPG not suck by FrozenEmu

Sections:
0) Introduction

How to begin... well, this tutorial is set up for all of you people who have decided you want to attempt to make your own RPG. Unlike other tutorials of it's type, I'm not going to try to teach you HOW to do it... there are plenty of programing tutorials out there that'd be a lot more help than I would be in that area. No, my friends.. what you are going to learn in the 10 hours it's going to take you to read this monster of a doccument is how to make a game that's different.. one that will actually stand out from the masses. Most of the things I'm going to explain are things that are helpful to keep in the back of your mind while you're doing the actual programing and graphics for your game, not nessisarily "do this, or you're wrong"-type things. Basicly, I'm just trying to point out a few things that you may not have considered while making your game, that will in the long run make it better. If you have any suggestions/requests for further sections, feel free to e-mail me, and I'll see what I can do.

This is by no means done.. I'll be updating it more and more as time goes on. If you see little notes to myself around the page, just try to ignore them.. hehe



1) So, you've decided to make an RPG, eh?
or: you fool...

ok then... you've decided to take an oft-tread path and try to produce your own RPG. By now, you've probably got a few ideas swimming in your head, but if I do my job here, you can rest assured that by the end of this, you'll have a lot more. So, where to begin... I'm sure if you're reading this, you've already got past the obligatory "what kind of game do I want to produce" and "what language should I use?" quesions that are in all the all-purpose game development FAQs out there, so we'll skip past that.

Alright, first thing you need to take into consideration may not be a completely pleasnt topic for some of you, but let's be honest here... A LOT of people have tried to do this, and A LOT of people have suddenly realized halfway though writing the code that they didn't know what they were doing. Programing an RPG isn't nearly as easy as many people initally think it is. It may seem like just a simple matter of a tile engine with battles, but when you consider all the things that have to be going on in the background, it gets a little complicated. If this is the first thing you've ever attempted to program, you should probably invest some time in learning the language you're working in first. Nobody can program like a pro on thier first day, and this isn't the kind of endevor that should be undertaken by anyone who doesn't have a bit of experience under thier belt. If you can program the basic tile engine (just have the ability to externally load a map and tile data, and set up a character to move around on the map) without having to look anywhere for help, then you should be in pretty good shape... if you need a tutorial for that much, you're just going to get hurt later on.

Concern #2 is of course art. I'm no expert on this one, but a decent artist is a must for any project. If you can do the art yourself, then by all means go ahead.. just don't overdo it (more on this later). If you're interested in how to handle the Art, Tsugumo has an excelent art tutorial that you can read... it should give you all the info you need. If you're working in association with someone, be sure to read up on the Joint Projects section down below.



2) Alright, I can make it.. how do I get started?
or: how to stop the problems before they sneak up behind you and stab you in the back with a kitchen knife.

A lot of people end up having a lot of problems during thier game production simply because they leave out this step. I'm sure we've all seen this type of situation before:
This game is going to revolutionize the world of game development! 50 hours of exciting gameplay, over 20 playable characters, a huge fully interactive game world, an excelent realtime strategic battle system, all taking place in an epic world!
Oh, really? What's the story going to be?
Oh, I haven't worked it out yet.. but it's going to be EPIC!
oh, I see... do you have any charcter descriptions?
A few.. I know the main character is going to be a fighter with some magic power, and the heroine that he's going to fall in love with is going to be a powerfull white wizard...
Our good friend Bob here has demonstrated the biggest problem that I've noticed with amature game designers today... Lack of Planning.

Before you even touch the code or a single sprite, you need to consider a few things... first, how is this game going to be played out? Is it going to have a serious tone? Is it going to be funny? Are the characters going to be like real people, or are they going to be over the top heroes? Who ARE the characters? Is the game going to be tile-based? pixel based?

I'm sure you're anxious to jump right in once you have a rough idea what you're going to do, but you need to decide on quite a few things before you even get started, particularly with the art.

First thing... I know a lot of people are going to disagree with me on this one, but hear me out.. before you start, you need to have a story. Now, this doesn't mean you have to have a script written out, but it DOES mean you should know what's going on in the game, and who the major players are. You wouldn't believe how many games I've seen with generic-looking characters that the developers obviously didn't even stop to consider a story for.


Hello, who are you?
Hi there! I'm Bob, a warrior!
A warrior?
Yep, world's finest.
Oh, really? Where are you from?
No idea. there don't appear to be any towns around yet, so I'm just standing here in this field. For a while.
So, what are your plans for the future?
Well.. I think I'm going to go kill some things... probably meet up with a bunch of people, and eventually save the world.
Wow, that's a grand ambition... what exactly are you saving the world from?
Oh, there's always something...
Thanks bob, you've been most helpful...

If you've already started your game, try having this conversation with the character you've got staring back at you in your engine. If he can't answer these questions, you probably didn't plan enough before you got started. (Disclaimer: I am not responcible for any wierd looks from your spouce/family or mental hospital admissions that result from talking to sprites.)

Basicly, you need to consider these types of things because trying to make sprites and/or engines before you know what the game is going to require is like knitting a sweater for your doberman ... it sounds like a good idea at first, and it looks good before you get started, but it takes a long time, and it probably isn't going to fit when you consider what you're doing it for. So, before you start, sit down for a few minutes and come up with a basic central plot line, the "main" characters, and anything else you think you might need to know so you'll only have to do this stuff once.

Also, you'll want to consider some programing aspects before you start with your engine... be sure you remember that you're going to need A LOT of data in the future, so don't waste good memory with things you don't really need. (ie dont Dimmention an array for 1000 tiles if you're only going to need 100 per set... and don't allocate 2000 byes for a 16x16 tile... you won't need that much). Also, be sure you don't program yourself into a corner. If you're going to use something more than a couple of times, put it in a subroutine... and keep all of the variables and options in the arguments.. you never know when you could need it for something else. Try to keep everything in the engine simple and JUST for the engine... don't program in any game data yet, you'll do that when you get to scripting. The less you have "hard coded" the better.

Basicly, a few hours of planning will save you from a lot of headaches in the future (although no amount of planning is going to save you from all of 'em... I do reccomend getting a nice bottle of Asprin before you start programing any of the more difficult parts :-)



3) The Joint Project
or: how to con your friends into doing your dirty work..

Given how much work is involved in making an RPG, a lot of people find that it's impossible to create the grand scale RPG they're trying to produce without some help, so they set up thier webpage and post an open call for all programers/artist/musicians to come join thier group of ragtag game developers for the greatest project ever undertaken by the human race.

Personally, I wouldn't go that route at all. It brings together a large group of people who don't know each other from all over the country(or countries, as the case may be), all trying to work on the same project. Now, you have to remember that any game, particularly an RPG requires that everything fit PERFECTLY into the molds in order to work... if you have 10 different artists, all of them are going to have thier own unique prespective for what "good" art is, they'll all use thier own programs, and they'll all send you different graphics. Like I said in the introduction, I'm not pointing fingers anywhere in this, but if I was, I would have the link to a game that's in development (or was.. not sure). The graphics were excelent... character sprite pictures they had on thier page were top notch.. but when I downloaed the game, I found that every screen looked COMPLETELY different than the previous... there was no continuity at all, and it just ended up ruining the game. Say you have two artists.. you ask one of them to make a scene with a small brook, and the other to make town tiles. You get this: (done in 5 minutes in my tile editor :-)


Now, other than the fact that they both suck, these two sets have absolutely nothing in common. If you look at them, they just "feel" different. (see, tsu, I can talk like an artist)... Now, imagine trying to collaborate between 4 or 5 artists, and you'll understand why this doesn't work...

Before somebody goes insane on me, I'm not trying to say you should work on your game by yourself.. Sure, Squaresoft has hundreds of people working on a single game, but the important part is.. they're all in the same building. If the head of sprite design looks over and sees somebody animating one of the sprites wrong, he can stop them and correct the error before it's made. The artists can look at each other's work and make sure they're doing it right... The programers can walk into the art department and tell them that they need to start putting thier sprites offset 1 pixel from the top instead of 2.. that kind of thing.

Basicly, if you're going to do a project with other people over the 'net, be sure you know them quite well beforehand, and be sure that you have similar ideas about what makes a good game. This doesn't just apply to art.. be sure that one of you doesn't like D&D style RPGs with 50 stats and computer-controlled combat, while the other likes FF4-style turn based combat... you'll just end up arguing.

If you don't know anybody who can help you, you might need to face the fact that you're not going to be able to make the ultimate end-all game. Maybe you could start with a simple, short game, and finish it, then meet some other developers, and colaborate with them on the next game you make... the experience would be helpful anyway.



4) RPG storylines
or: what an english composition major does for a living.

OK! I've got my background story now! Gather round children and you shall hear my tale... every 1000 years, the legendary Dragon of Eternity emerges from it's grave to bring chaos and destruction to this world, and every 1000 years, without fail, a heroic Knights has emerged to confront him, and ultimately seal him away for another 1000 years... the last time this happened was with my great-great-great-great-great-great-great-grandfather 999 years, 11 months, and 28 days ago! I sure hope that the legendary knight manages to find the Sword Excalibur before the Dragon of Eternity returns to the world in 2 days, or we're all in big trouble! But in the meantime, I'm going to see the king for some trivial mission, which has no relevence to the plot.
NO! NO NO NO NO NO NO NO! Don't do that, please.. heh... sorry to go crazy on you there, but that is the most generic storyline that has ever tarnished an RPG, and yet I see it over and over again. Remember that plot I said you should plan out in the previous section? well, if it's ANYTHING like that one at all, stop and reconsider. One of the more important parts of any Role Playing Game is the story.. a good battle engine will only get you so far... if the story isn't a strong driving force in the game, people simply won't care about what's going on, and won't play through your game.

So how DO you write that story that's going to captivate your audience and make them overlook the shortcomings of your game and play it straight through to the end? This isn't an easy task. If you find yourself at a difficulty with prose, it might be a good idea to get a friend to help you out with this one, or you're going to end up on a variation of Bob's story above. Of course, the most imporant part of most stories of this type are the characters. (there ARE some exceptions where the world in the background is the driving force, and the characters you play are simply being pulled along, like in Final Fantasy Tactics, etc, but let's focus on the most common case). Characters should be more than thier class. If you find yourself designing characters like "Jane, the White Wizard" and "Bob, The world's finest warrior", you need to back up for a second and start to give them more of a personality. A friend of mine and I were talking about this at some point, and we realized that many times, you start to identify the characters not as "people", but as "That guy who can cast Lighting 4" or "The main guy"... without a reason or desire to learn thier names, histories, etc.

Some things that may be helpful in defining a character:
  1. What's the character's name? Age? Physical description?
  2. Where did the character grow up? Small town? big city? raised by wolves?
  3. How did the character learn thier profficency (be it swords, magic, etc).. very few people are born with the ability to use a katana
  4. What is the character's personality? Are they somber? serious? air-headed?. This is probably THE most imporant question.. be sure to keep this in mind while you're writing your story, or you're going to end up with characters who all basicly have the same personality as you :-) If you can, try to give characters different personalities, so that you'd be able to write out some random lines, and know who would be most likely to say them. You don't want your hero to be depressed and serious one minute, then an hour later (in-game time), he suddenly becomes a happy love-struck teenager.
  5. Finally, what kind of skills will the character have? Weapons? Magic? What kind of armor will they equip? What will they be wearing? This part should be derived from the above, not vice-versa. A delicate and shy princess would probably not prance around in a chainmail bikini with a huge battle axe (not that I'd have any complaints if one did.. particularly if she had short blue hair and... where was I now...?).

Ok... here comes the fun part... the back story... the back story is the story that through all of your character interaction, your quests to save people's dogs, and the main character's struggle to find the ultimate sword of destruction, is ALWAYS running. If you don't have this, you end up having people wandering around for no reason. There's a lot of traps that are easy to fall into here. It's always easy to start this off by giving your hero an advesary, and making the story "Go beat him". This comes in many forms... an example of this is bob's story up above. That's probably the most extreeme case of generic, but it doesn't take much to start creating a story with the same general formula. I can't really help you with creating a story (there's really not an algorithm for creating one... that'd make it too easy, and we certinly can't have that.. heh) except to leave you with a few pointers/suggestions:
  1. If your introductoy story contains one or more of the following, you need to SERIOUSLY reconsider. Sometimes, these are part of a good story, but 9 times out of 10, you inadvertinly fell into the trap:
  2. When you're writing up the inital story, you don't have to go through all 3000 lines of dialoge, write up what every NPC in the game is going to say and so on and so on... before you start your game, all you really need is a basic plot outline. Take all the MAJOR events in the game, and place them on a simple timeline (i.e. The main character has to kill the evil king before she can go to the catacombs and get the hot air balloon, then she'll be able to get to the northlands and ...). You want your plot to be somewhat flexible, since you're inevitably going to have a few ideas as you're going along that you're going to want to throw in, plus you'll want some side quests to develop your characters, and so on.
  3. A quick note on Linear vs. Non-Linear... Contrar to what people may tell you, Non-Linear isn't nessisarily better. Remember, non-linear makes it significantly more difficult to keep an interesting plot running. Think about the second world in FF6... you could go anywhere, do anything... but what was the plot? Basicly, it's "There's an evil overlord in a tower over there.. go get an airship and fight him". This is why I personally like the first half of the game better.. there's a steady storyline going the whole time, it keeps moving as you move along in the game, and it's interesting. Sure, Squaresoft managed to get some good sub-plots and character development going on in the second part, but they're SQUARESOFT... heh. Non-Linear plots are difficult to handle, particularly if you're fairly new to the game development world. So, if you have a good plot idea, don't worry about making it non-linear.. it could potentially ruin things.
  4. Something to keep in mind... remember, nobody who's not getting paid for thier RPG is going to be able to have 50 hours of gameplay and 20 playable characters (unless you're insane like Sirocco.. heh)... particularly if you're working alone. If you're doing a solo project, or one between you and a frend over the 'net, don't overdo it. Try to keep in mind some limitations on yourself, and you'll do well. A GOOD 5 hours plot is better than a loosely thrown together 20 hour one.

 6) Setting up Plotlines
or: a game can't live by back story alone.

Quick Note: If you've been living under a rock in a cave buried deep inside a mountian on mars and haven't played FF6(3 US) then you may not want to read this section, as it contains what some may consider spoilers. I was going to analyze FF8, since it has some excelent examples of what I'm going to be discussing here, but the potential for spoilers is too high... I choose to analize this game since I know most people have played and finished it.

OK, by now you have a good idea of what's going to happen in your game. First thing you need to do (and I can't stress this enough.. heh) Is WRITE It DOWN you're not going to be actually writing this for some time, and you don't want to forget it.

The part of the story making I'm going to be describing here doesn't need to be handled before you get started... you'll be doing it mentally as you go along, and you'll be doing plenty of it while you're scripting the game (see section 7 for information on scripting). Think about, for instance, Final Fantasy 6 (that's 3 for those of you on the US numbering system)... Here's the back story:
A young girl born with the gift of "magic", a mysterious force long thought to be completely dead in the world, is captured and brainwashed by "The Empire", and used for her abilities. As the story opens, she is being escorted into Narshe, a town where a strange creature has been found buried in ice. When they arrive at the scene, the girl is knocked from her magitech armor, and is recovered by a local man. Now, pursuied by the empire, the girl searches for the truth behind who she is, and how her "abilities" came to be...
Excelent premise for a game... gotta hand it to Squaresoft for that one. But, that story isn't going to work on it's own. If you just have a game with a girl wandering around the world trying to discover her past, it's going to get boring real quick. What really makes FF6 shine is the interaction between characters, the sub-plots, the other things that are going on besides that central story that keeps driving it forward.

Let's break apart a few of these dichotomies that exist in the game:

 And those are just a few examples. When Square was piecing together the game itself, they didn't just consider how to move the main plot along.. they wrote in other characters that didn't even have anything to do with the central plot. When you piece together the web of occurances, character histories, character and enemy personalities, and that central story, everything falls into place, and ends up making for a great game.

A great game is not nessisarily defined by a great premise... it's quite easy to take a fairly weak story and turn it into something spectacular with all of these little "extras" that you can throw in. So when you're making characters, don't just have "The heroic knight who is asked to join you by the king".. have a reason for him to join.. give him a history, give him a personallity, and set up some interactions between him and the other characters. When you're done, the game will end up 10x better.

Another thing about plotlines... Don't automatically assume your characters have to be saving the world. Sure, it's a popular plot scenerio (.. in fact, just about every game I can think of ends up with the characters saving the world), but it's possible to make a game without it. And even if you do go with some variation of "saving the world", your hero doesn't have to be the defintion of a "White Knight", saving the world without throught of personal gain. Why not make him a complete bastard who's just in it for the money? Maybe he's a pirate who gets forced into the plot by his ship being stolen? Maybe he's a cowardly thief who keeps complaining about how he has to save the world? There's a million possibilities with this kind of thing, and as I'm sure you've picked up from this thing by now, ORIGINAL IS GOOD! The less your game is like the steryotype, the better. Make a game that's unlike any that the person has played before, and they'll want to continue playing it.



6) Game System Design
or: not every RPG has to be like FF4.

Alright.. it's finally time I put this sword I've been lugging around since the begining of time to some good use! GERANIMO!!
Here we see the classic battle screen. As you can see, our friend Bob, The Warrior™ has the option of (A)ttackig, Casting a (M)agic spell, using his special (S)kill, or using an (I)tem.


There are two things wrong with the above picture, design-wise. No, the lousy graphics isn't one of them. See if you can guess.

If you guessed "Generic System" and "(A)ttack", you'd be right. Let's hit the "Generic" part first...

Generic? no, no, my friend, you're wrong! For you see, instead of the usual spells of "Fire" and "Ice" and whatnot, MY spells are all based on poison! Therefore, the system is original!
No, Bob, it's not. Look at this side-by side comparison.

(FF4 VS Generic Battle Engine Image)

Note the similarities? I've said it before and I'll say it again (in boldface this time!) Not every game has to be Final Fantasy 4! There's nothing really wrong with the system, but if you want to set your game apart, it might be a good idea to try something new, or at least a little different. Here are some characteristics of the FF4 engine that you can try to modify:
  1. Menu: Attack, Magic, Skill, Item, Run, Block
  2. Each character is given a specific set of commands. (i.e. Paladin Cecil has "Attack", "White Magic", "Cover", and "Item"... Kain has "Attack", "Jump" and "Item", and so on)... maybe you could assign skills yourself, make customized characters? Learn new command abilities by completing quests?
  3. Characters learn increasingly powerfull magic at level up... all kinds of possibilities with this one.
  4. Character sprites on the right, monsters on the left. Maybe randomly throw sprites around the screen at the start of the battle, and do different amounts of damange based on distance? Have characters move around the screen as you fight?
  5. Numerical Spell Numbering (i.e. "Fire 2", "Ice 3", etc)

  6. I am truely the worlds finest warior! I can slash my sword at thin air, and a few seconds later, the enemy is hurt! HAHA!
    Ah, thank you bob.... another good example.
  7. "Active" battle system based on character speed.... maybe use speed to determine how far you can move before attacking? Make the system truely active, allowing to quickly select and use characters as you see fit?
  8. Stats: Strength, Agility, Intelligence, Wisdom, Defense, all increase at level up.... stats are easy to rearange, change, add too, or remove from.. you don't nessisarily have to base everything on stats.. maybe give stats through items (i.e. your defense is entirely determined by your armor, etc)?
  9. Weapons and armor are purchaced through stores at progressively better power.... maybe allow for upgrading weapons? Or make a lot of different weapons that aren't really any better than others, but have different stats (i.e. a katana can be used faster than a broadsword, but the broadsword does more damage)
  10. Each character can equip one/a few specific type(s) of weapon (i.e. Kain can equip swords, axes, and spears, FuSoYa can only equip staffs)
  11. You Die/Faint/Retreat when you run out of "Hit Points"... Maybe have damage to specific parts of body.. attacking arms lowers attack power, attacking legs lowers speed, attacking head causes death, etc... maybe have "hit points" in armor you're wearing, and once the armor breaks, next hit kills...
  12. Magic is cast by consuming a set # of "Magic Points"... maybe have magic consume itself.. (i.e. you can only cast Spell X Y times before you have to go to Z to get more... maybe have magic use spell components that you have to purchace, etc
b-b-b-but... that's the very stuff that MAKES an RPG!!
No, that's the stuff that makes FF4. Think about some other RPGs out there... FF8 doesn't have MP.. you draw magic from monsters. In Secret of Mana, you don't buy new weapons, you find orbs to upgrade your current ones. In WildARMS, you learn magic by finding crests and going to special shops to have magic placed on them. You can see where I'm going with this.

Now.... no system is going to be different on ALL of those counts, but if you find your engine has most or all of those elements, try picking one and trying to revise it. Change the way you learn magic.. change the way magic is consumed... whatever it takes, just remember you don't have to make it exactly the same as Final Fantasy 4.

OK, now for problem #2... "(A)ttack, (M)agic, etc". This is a system for controlling battle that I've seen more times than I care to. This may just be a personal thing, but it just seems amature-ish to me. Ideally, your game should be able to be operated with the keyboard or a gamepad... and there's certinly not an "M" key on your controller (unless you're using a Jaguar one, but let's not go there.. heh). Basicly, you should only need to ever use 2 keys during battle: "Select" and "Cancel". These could be something like "A" and "S" on your keyboard, or Button A and B on the gamepad... or even better, allow the people to customize them... but anyway, that comes later.. let's focus on controll for right now. Basicly, to keep your game feeling like a game, and not a typing lesson, you have to keep people's eyes off thier keyboard. If they have to search around for keys and numbers all the time, it will eventually get annoying.

Placing in key controll isn't difficult by any means.. all you have to do is determine the keybaord scan codes for them, and set up a simple routine for placing a little arrow/finger/sword/whatever to point at the current choice. This doesn't just apply to battle either.. you should also apply the same to your menu system, shopping, and you should never have to type "Y" or "N" to respond to a question from an NPC. This shouldn't be a problem for you, you've programed a tile engine by yourself, right? Good. Go program it. I'll wait here.



7) "Code" vs. "Engine".
or: Yes, Virginia, there IS a difference..

Quoth the Merriam-Webster Collegiate Dictonary:
en*gine [1] (noun) : something used to effect a purpose : AGENT, INSTRUMENT ; a mechanical tool
code [1] (noun): a set of instructions for a computer
See the difference? "Code" isn't going to work for writing an RPG. You're going to need a flexible, updateable, self-contained, fully operational machine to get this thing beyond the "TILE ENGINE DEMO #1!!" stage. Your engine should work a lot like the one in your car... you don't go inside your engine and force it to rotate the piston.. you don't tell the spark plugs when to ignite the fuel.. it knows how to do that by itself.. all you have to worry about is telling it to turn on, telling the steering column to rotate the front axel to make you turn, and so on. Your RPG should be able to do all the complicated stuff "behind the scenes", so to speak, while all you do is give it commands like "DrawScreen" and "LoadMap(filename)". This will be beaten to death in the "Scripting Engine" section, but for now, I'm going to indirectly tell you of a few mistakes I've made in the past, in hopes that you won't repeat them.

Ah, the joys of structured programing. Most of you are familiar with this to a certian degree... I'm sure we all remember the first time we opened up a program in QB, saw just a few lines and thought "Where's the program?!". Then we learned about subroutines... the ability to put chunks of code in seperate routies, and call them whenever we needed.. countless hours trying to figure out a problem before realizing you forgot to COMMON SHARE a variable...Anyway, enough nostalgia. I'm sure we've all moved past the stage where we had to make all the variables in our programs public and set them over and over again.

So... how does this apply to the "Code vs. Engine" thing I mentioned (with a clever 30's pop culture referance, no less)? Well.... here goes nothing.... (some of this may not make sense.. it may make you say "woudln't it be eaiser just to...", but trust me on this one.. you'll understand when you read the section on scripting engines.)

Rule #1: Your Hero is NOT special

Are you talkin' to ME? Look here, bucko, I've got a huge sword, shining armor, flashy blonde hair, perfect perly whites, and chicks hangin' all over me, and you say I'm not SPECIAL?
No, Bob, that's not what I meant. What that means is: Whatever you do, DO NOT create a special drawing method for your hero, particularly not "draw at (middle of screen)". Eventually, you're going to want to be able to move the screen around without your hero floating there in the middle. And no, setting a variable to say if you draw him or not won't work. The eaisest way to do this is to set up the hero just like an NPC.. only thing is, when you hit a key, you move him, as well as.. the camera! The camera is going to be essential later on, so it's good to program it now. Basicly, you need to have your screen set up such that you can move it around wherever you want without moving ANYTHING else (and yes, this includes your hero).

Rule #2: Make everything universal
This is more of a style thin, but I find it helpful. Set up your engine so you can call a routine for anything you want. For instance, if you have a routine that tells you if a sprite is at a specific location, DON'T have it only check the square in front of the character. Set up the routine so you can pass any point you want into it, and it'll return the value for that point. NEVER assume that you'll only need a routine for one specific purpose. Also, you WILL need to be able to do this later on in the scripting engine.

Rule #3: Functions are our friends
USE THEM. If there's any complicated mathmatical operation you need to do more than once, it's probably worth it to make it a function. If you ever find yourself setting a global ("COMMON SHARED") variable inside a subroutine and checking it afterwards, then convert it to a function and just call it directly. This is REALLY helpfull when setting up things like collision detection and, of course, scripting (noticing a theme yet? heh)

Rule #4: If you forget the rest of this section, at least remember this.
NOTHING happens automatically. If you want the engine to do something, tell it to. This means Don't put a command to move your hero inside the MoveCamera subroutine.. don't tell it to draw the screen anywhere except where you're aboslutely sure there will never be a circimstance under which you might want to have it wait. (i.e. don't put it in the MoveSprite routine... you'll eventually want to be able to call it more than once in succession). If too many things happen automatically, you're going to end up with a chunk of code that operates a game, not an engine.



8) Scripting Engines.
or: The closest you're ever going to come to writing your own programing language.

Hello, Bob.. how's the world coming?

Well, as you can see, there's a town now... still nothing to do, though.
Why? Aren't there some chicks you could talk to?
Yeah... I can TALK to them, but ... watch this.. Hey there, babe.
Welcome to Hometown!
Is your tailor also a glass blower? 'Cuz I can see myself in your pants.
Welcome to Hometown!
Playin' it cool, eh? I can dig it... so how about you and me go get a drink?
Welcome to Hometown!
...
Welcome to Hometown!
See what I mean?
Maybe she just doesn't like you...
Nah, that can't be it... how could she NOT fall in love with the world's finest warrior!? I just wish SOMETHING would happen in this world.
Ah, but it can...

Alright, you have your engine programmed.. you can walk around, you can go in and out of buildings, you can't walk through walls.. you're all set to release your first demo, right?! Wrong. What's the point of a demo if there's nothing to do? Surely the world has enough of these "Walkaround" demos.. why not go ahead and set up a story?

Wait a second, don't go yet... Big mistake many of you are about to make... you should never.. let me say that again.. NEVER have a single line of your script or any automatic movement inside your code. NEVER. It'll just end up eating up valuable memory, and make your EXE bloody huge. Don't want that.

This is where the concept of the Scripting engine comes in. Basicly, a scripting engine is a set of commands inside your program that can be called from external "script" files. These scripts basicly tell the engine what to do, and the engine falls in line and does what it's told.This is basicly how it works:

First, some terminology. There's 2 basic parts to the scripting language.. The Script, and the Interpreter. The script is an external file that contains all of the commands that you need to tell your engine to preform. The Interpreter is the part of the engine that reads in the commands from the script, and then tells the engine how to preform them. The "engine", as you recall is the main code for your game, that contains the actual code to move characters, draw the screen, etc.

First thing you need to do before you start coding the Interpreter is to figure out what commands you're going to need, and write out a text file with the descriptions, functions, prototypes, and examples of how they work. I know you're writing this yourself, but trust me, with the volume of commands you're going to need, you will want something you can look back at later. The commands themelves will look something like this: (copied over from the last one I wrote :-)
MOVESPR,10,1,10
FADEIN
LOADMAP,map12
These three will, respectively, Move Sprite #10 10 spaces in direction 1, Fades the screen in, and Loads the Map titled "map12". If you were writing out that text fle for these, you'd have something like this:
MOVESPR, Sprite Number, Direction, Number of Tiles
- Moves a sprite that is currently on the screen
- (i.e.: MOVESPR,1,1,3 - moves sprite #1 3 tiles up)
There are going to be A LOT of those. More than you think. Don't worry, though, these are easy to program if you structured your engine well. Some things you're definately going to need: Seems like a lot? Don't worry, it's not too bad.

Now, for the interpreter. This is where the actual coding comes in. Basicly, all this has to do is open up the file, and read it in one line at a time. It checks the first value on that line, and then selects which one of the commands it's going to use. The script for that particular command reads in the rest of the values to temporary variables, and then calls the appropriate subroutine in your program to run it. For instance, using the MOVESPR command above, you may have this:
readvalue(scriptcommand);
if (scriptcommand == "MOVESPR") {
readvalue(chrnum);
readvalue(direc);
readvalue(numspaces);
movechr(chrnum,direc,numspaces);
}
Where "readvalue" would read the next value from the file, and "movechr" is the routine for moving a character around. If your engine is working, you probably have this routine already. For you QB people, it'd look something like this:
INPUT #1,scriptcommand$
IF scriptcommand$ = "MOVESPR" THEN
INPUT #1,chrnum
INPUT #1,direc
INPUT #1,numspaces
movechr chrnum,direc,numspaces
END IF
Easy as that. Once you have the scripting engine finished, you can compile your source code, and you'll never have to touch it again. From then on, it's all scripting.
Return to Top