Making a 2D RPG have questons
Blitz3D Forums/Blitz3D Programming/Making a 2D RPG have questons
| ||
| I am making a zelda/wild arms type RPG. I can fugure out the animation programming..but one thing really has me puzzled. How would I go about the engine. There will be many people that will be talking. How would I organize every characters spoken words. I know I can put it on a file but if I do this my main game loop will be very big and I am afraid that if I have a big loop it will decrease FPS of the game. How would you guys implement an RPG engine/loop? |
| ||
| Why would it be big if you put it in a file? Personally, I would put each character script in a file, index each conversation - parse the file to the index you want, and display the text on the screen. Should be quick enough, plus if I remember the PS1 games with the similar sort of thing, there were always delays between speaking (each line being typed - quite annoying). |
| ||
| OK...I see...what exactly is a script file? Also, what is a parse I have heard of it but never worked on one. |
| ||
| parsing means having your program filter through text. There are many different types of parsing as there are many different ways to filter text. Yeshu described what you need to do although it's not that slow as far as I've seen. AFAIK, they put pauses in the conversations on purpose so that you couldn't skip through them at the speed of light. A script is a bunch of directions, usually used in cutscenes. It doesn't have to be just speech but can be movement, animation, camera effects, explosions and pretty much whatever else you can think of. Think of it like a script in a movie. It gives the actors their lines but can also give them prompts for displaying different emotions and actions. Scripts in games work in a variety of different ways. Starcraft and Warcraft have some of the best script engines around. Halflife is known for it's scripting too but mostly because it had scripts running while the game was still "running" and in control of the player. if you want an example of what a script might look like, think of it like this. You have a "script.txt" file and it could look like this - Mv 20 25 28 an 20 5 sk 20 What is wrong with you? - What would that mean? well, the Mv could mean move. The 20 could mean object number 20 and the 25 and 28 could mean horizontal and vertical coordinates on a grid. The an could be a cue for an animation. the 20 could refer once again to object 20 and the 5 could be the animation. Sk could be a code for speak. The text on the next line could be what object 20 says. So when it is read, object 20 moves to grid coordinate 25, 28 and starts animation number 5, while speaking "What is wrong with you?" For your game, you can make the script engine as complicated or as simple as you like. Personally, I'd go for simple if you've never made one before. You can always add new commands to it later if you want. Like there's no pause command in the script above. There's no mention of any sort of timing either. You could have it so everytime someone speaks, a little box appears next to the text with a picture of who is speaking or you could have it so your program needs to read a command to show that little portrait box. As I'm sure you can see, there's a lot of room for expansion in scripting. So go have some fun with it. :) |
| ||
| If you have the whole conversations word for word in your text file. You do not really parse. Parse is really a computer word for "Translate" so for example (JUST TEXT not movment) Meet E_happy Inquire E_health Might mean greet the player in a happy mood, and then Inquire as to their health. So the Parser would look for a greeting that was happy, and then look for a question quote, then for the words for health. Its worth doing if you have the time, as often you can stick varailbes in the "Speech Direction", for example Congratulate (E_Happy * hostage_lived) else E_Sad. (Or again whatever). ALso parsing is when the player used to type in the commands, and it was the programs job to know that take and get where the same. |
| ||
| Oh sure, you can complicate matters by needing to seperate lines of text into their individual commands but why not just use a format for scripts that is both easy to write and easy for your program to read? As to limiting your scripts to just text and not raw numbers, I think you're limiting yourself by doing that. But I've you've brought up something I totally forgot about, boolean logic. By using ifs, ands, ors and elses in your scripts, you can program your entire game with just your scripts. It can take some time to make a parser for this but it can save you a helluva lot of time. |
   |