02-24-2002, 04:53 PM
Well, that's the gist of it, anyways.
Right now, I have coded up this map building software that makes it easy to build a map for a game I'm currently working on. However, I've run into a bit of a problem...
I have absolutely *no*idea how to code up scripts.. eg When a player walks over a specific tile, he is sent to another tile.
Now, I wouldn't mind actually building all this into the program, but I would be happy as pie (worst analogy ever) if I could load the maps and scripts from *.dat files into the program at runtime, thus facilitating ease of upgrade.
Err... any help would be appreciated... =)
Thankee kindly. =)
02-24-2002, 05:17 PM
From VB Gaming Central
Make the engine as general as possible. If you hard code anything naughty into it you deserve to be thrown in the Sarlacc pit. Allow for as many details as possible to be file driven. Every world, level, or character should be loaded from a file created by your in-house tools. Try not to describe AI in code either, create a scripting language and allow everything to be interpreted at runtime.
You can either devise your own scripting method, which is probably the best method. But if you're after something more complex, then you might opt to utilise VBScript. If this is the case then the link provided by orufet in this thread (http://www.visualbasicforum.com/showthread.php?s=&threadid=19512&highlight=msscriptcontrol) was very useful to me.
Now, you could have a collection of strings with a number as the key. When a player walks onto the tile, look to see if there is an item in the collection which key number matches the tile number of the current tile. If so, execute the script stored in the string in the collection.
Something like that. :)
02-24-2002, 10:14 PM
The way I am doing it (and it seems to work quite quickly) is to have integers assigned to every object in the game for each possible action. Then, whenever the player causes one of the characters to perform an action, the game checks to see if the number is valid (not -1), and if it is it retrieves info about the required task from an array. The integer is the position of the task in that array.
The tasks have a byte value for the type of task/condition to be performed, and an array of four integers that relate to other things dependant on the type of task.
If it is a type 1 task, then it will display some text in the status window. Task(x).data(0) is the position in a file of text strings where the appropriate text will be found.
Another example is a chain event, which causes more tasks to occur. The data numbers here refer to other tasks.
Something a bit trickier is a check for items in the inventory. data(0) is the number corrosponding to the item in question, data(1) is the required quantity for that item, data(2) is the task number performed upon success of the check, and data(3) is the task number for failure.
Depending on how complicated future tasks/conditions get I may add an extra data() integer.
The idea of my project is to provide massive flexibility and power to the user of the editor with very little effort or difficulty. All the information (apart from the basic engine) will be stored in files, modifiable from the editor. Nothing I have come across leads me to belive that this will be infeasible in anyway.
02-25-2002, 11:23 AM
Just adding my 2 cents. I totally agree that generallity it not the suggestion, not the rule, not the law, not even the theory. Making a scripting engine is a truth. Anything less than absolute respect for it will lead you down a programming path that will be nearly (if not totally impossible). In fact this is the one great moto of OOP, make it expandlable by keeping it simple. Add your specific and ungeneralized function on top of what you already have. Life will be much simpler. In my own scripting language I allow the script to create and destroy variables. I'm not saying that you need to create a new interpreter, but the best scripting language can be found somewhere in between.
02-25-2002, 12:25 PM
Denmeister, could you post a simple example of how your scripting works?
I'm trying to figure out how to script the AI for the monsters in my RPG, and I'm not quite sure how to go about it. (See my 'Working on a Basic RPG--Take a look' thread on this forum)
02-25-2002, 01:22 PM
I don't know if it will help any, but for AI, you could make it so that the monsters always follow you, unless their health is something like under 1/3 of his max, then the monster moves away, and monsters regenerate by 1 HP every time they move. If you're looking for an idea with AI, that could be a way to go. If not, sorry to waste your time.
02-25-2002, 01:47 PM
Mainly what you want here is a VERY rudimentry interpreter.
Here the rules fall away because you can make this language as simple or as complex as you'd like. I chose a open-ended set of keywords. Once you have you system set up, you can now begin your scripting your mini-program.
There is one thing you need to keep in mind. This is a question that keep the best programmers on their toes. And it has no right or wrong answer. Where does the scripting end and the hard-coding begin. The answer really depends on the application. A very intricate game with movable objects and multiple camera positions can have an entire game written in a very substantial scripting language. However, a simpler game can have several smaller subsets of the original root language. This has advantages because the code is reusable and is easily modified, but you don't have the power of a highly developed scripting language. I, being forever indecisive, chose a mix. I created a mid-to-high-level language. And created several subset for more specific purposes.
One more note, remember, at this point you're basically running two seperate programs, make sure you provide a simple communication mechanism. The communication will be mostly predictable in an AI-fitted language. Data-In / Data-Out. Make sure your communication mechanism is reliable. ByRef's are good here.
In your scripting language you'll need a way to declare variables, to evaluate expressions, and to itterate loops (this is the hardest). A decent scripting language shouldn't take you more than a day or two to make. And it's a good idea to make a simple program to run your script and to verify it's integrity. That's not a big deal, but it's DEFINATLY worth the extra day. Trust me on this one. I once spent 2 weeks looking for a bug that was a single letter misplaced in my script. Felt like an idiot!
Once that (seemingly small but actually) huge task is accomplished, you can now control monsters, control cameras, or any other arithmatically soluciable problem on-the-fly if you choose. You can now send updates and upgrade AI by sending a 1kb file instead of a huge EXE.
One drawback to scripting, however. Scripting requires computational over-head. As we're making games here, the problem of needing just a little more processing power rears it's ugly head too often. So keep your script interpreter as small as possible. Make it lean and mean as you can. The performance drop by the interpreter will drop to lmost negligable levels. The speed difference between hard-code (compiled code) and soft-code (scripted code) can be quite extreem. Using it for AI is an appropriate use of scripts. But don't over-do it. Remember, there's a reason we have compilers.
Good luck to you. :)