Wow. Thanks a ton for all that insight guys. I have have convinced myself that this project will take along time, but I'm hoping that with enough motivation from friends and some awesome help from you guys I will be able to get close to realizing my dream.
I guess the theme to this thread has been "KISS" ("Keep It Simple Stupid"). I know that "gooballs" are my worst enemy. I started a development notebook today and I plan on keeping all of my ideas, plans, and designs in that ONE notebook, not spread out over 5 that I randomly lose and stumble upon later.
I started a scripting system today. It is fairly simple but its not done yet, so I thought I would run it by you guys to see what you think. I know there are some gaps, but hang in there. Here goes.
My scripting system will consist of several blocks of scripting that are run at the apppropriate time. I.E. the <On_Activate> block is run upon the activation of the quest. Simple enough. In these blocks you will be able to display text, give players items or money, warp them, unlock portals (used to move players between "regions", which are just loaded from an XML file), and anything else that I find necessary later (as I PLAN, not CODE :D). There are 4 blocks right now, as follows:
<On_Activate> - Runs when the quest is activated and the appropriate NPC is activated (talked to).
<On_Return> - Runs when the player has returned to the NPC AFTER getting the quest but BEFORE completing it.
<On_Completed> - Obviously this block is run when the player has all the requirements for the quest and has returned to the NPC.
<Requirements> - Run right after the <On_Activate> block is run, this block will describe the requirements for the quest (I.E. Bring back 5 dragons's fangs to prove you have defeated 5 dragons)
This system has lots of flaws but I hope to iron them out soon.
Of course I thought of this before reading rrc2soft's idea, which I like much better. It seems much more dynamic. Dynamic, in most cases, is good. Unless it turns into a gooball, then it's just nasty. :P
Anyways, thanks alot for all your advice and I'm looking forward to your replies.
Ion
Glad we have helped so far :-D
Since you bring up scripting, and I am very proud of the scripting engine I wrote for Flare, I'll just take a few seconds to let you know how I implemented a scripting.
So, the scripting language used for flare is called 'Magic C' it is a mix of PHP and C.
Each script is a text file, which contains one or more 'Entry Points' these are like functions that are called when a script is run.
etc.
When you want to run a script you simply do,
game.RunScript("scriptfile.script","EntryPointName");
A MagicC script might look somthing like this...
The three main things to know about my scripting language is that is that...
- $ indicates a variable is global and can be referenced between multiple scripts (all other variables die after the entry point returns
- variables are implicit, you dont need to predefine them
- variables are dynamicly typed, and can be either numbers or strings, the variables change type automaticly through implicit casts or assignments.
Magic C supports the major flow control functions:
if,else,switch,case,break,continue,while,return
and it supports compound conditions with boolean operators:
==,&&,||,!=,>=,<=,>,<
and it also supports arithmatic operators(no compounds =/)
+,-,*,/,%
The Flare implementation of Magic C, runs it with the ability to use 'latent functions', in a virtual multi-proccess enviorment, basicly this means that there can be 500 scripts running at once, most of which waiting in limbo for a latent function (function that happens in more than one frame, like walking) to be freed up by an event.
Obviously the hardest part about the scripting language was actualy implementing it.
Magic C scripts are interpreted and complied down to an instruction object model, and are cached (important for speed in scripts that are used over and over), this data is saved in a Script object. When the engine is required to run a script, it spawns a ScriptProccess object, attaches the script to it, sets the execution 'cursor' to the specified entrypoint, and then begins to execute. The script executor examines the compiled instructions and runs them through thier respective proccesor states to make the code do what it was meant to do.
All function calls like...
woot=KillEvilGuy("whatever");
get pased to the custom script handler of the game object, the game programmer subclasses this function to make extensions to the script's function set.
The script function handler gives you the ability to read all of the passed arguments, query if they are present, and query thier type, It also gives you the ability to push back a return value which is set inside of the variable 'woot' in this case. Also all passed arguments are assumed to be passed by refrence, this means that if i passed the variable '$str' instead of "whatever", it would allow the function handler to not only read, but change the value of $str, making it possible for functions to have multiple outputs, not just the single return variable.
Some functions are intrinsic, for instance...
Trace("text"); throws a messagebox
Wait(nms); makes this script yeild to the game and wait until n milliseconds have elapsed.
Beep(); a message beep
RunScript("scriptfile","entrypoint"); spawn another proccess with a new script (the calling script waits for the other script to continue, or yeild).
Once a script is done executing, it's proccess object is destroyed.
Hopefully this will give you some ideas as to what kind of functionality is helpful in an RPG. Magic C is _very_ general in that it could be used in almost any kind of game, you might opt for a more specialized aproach, in which it would be easier to build the system.
If you need any more information let me know :-D
P.S. Below is a script from Morning's Wrath,
A fine example of basic NPC interaction using Magic C
Since you bring up scripting, and I am very proud of the scripting engine I wrote for Flare, I'll just take a few seconds to let you know how I implemented a scripting.
So, the scripting language used for flare is called 'Magic C' it is a mix of PHP and C.
Each script is a text file, which contains one or more 'Entry Points' these are like functions that are called when a script is run.
Main(){}OnMouseClick(){}etc.
When you want to run a script you simply do,
game.RunScript("scriptfile.script","EntryPointName");
A MagicC script might look somthing like this...
Main(){$globalvar="Magic C, woo!";c=100;i=0;str="";while(i<c){str=str+"wow!\n";i=i+1;}Trace(str);}The three main things to know about my scripting language is that is that...
- $ indicates a variable is global and can be referenced between multiple scripts (all other variables die after the entry point returns
- variables are implicit, you dont need to predefine them
- variables are dynamicly typed, and can be either numbers or strings, the variables change type automaticly through implicit casts or assignments.
Magic C supports the major flow control functions:
if,else,switch,case,break,continue,while,return
and it supports compound conditions with boolean operators:
==,&&,||,!=,>=,<=,>,<
and it also supports arithmatic operators(no compounds =/)
+,-,*,/,%
The Flare implementation of Magic C, runs it with the ability to use 'latent functions', in a virtual multi-proccess enviorment, basicly this means that there can be 500 scripts running at once, most of which waiting in limbo for a latent function (function that happens in more than one frame, like walking) to be freed up by an event.
Obviously the hardest part about the scripting language was actualy implementing it.
Magic C scripts are interpreted and complied down to an instruction object model, and are cached (important for speed in scripts that are used over and over), this data is saved in a Script object. When the engine is required to run a script, it spawns a ScriptProccess object, attaches the script to it, sets the execution 'cursor' to the specified entrypoint, and then begins to execute. The script executor examines the compiled instructions and runs them through thier respective proccesor states to make the code do what it was meant to do.
All function calls like...
woot=KillEvilGuy("whatever");
get pased to the custom script handler of the game object, the game programmer subclasses this function to make extensions to the script's function set.
The script function handler gives you the ability to read all of the passed arguments, query if they are present, and query thier type, It also gives you the ability to push back a return value which is set inside of the variable 'woot' in this case. Also all passed arguments are assumed to be passed by refrence, this means that if i passed the variable '$str' instead of "whatever", it would allow the function handler to not only read, but change the value of $str, making it possible for functions to have multiple outputs, not just the single return variable.
Some functions are intrinsic, for instance...
Trace("text"); throws a messagebox
Wait(nms); makes this script yeild to the game and wait until n milliseconds have elapsed.
Beep(); a message beep
RunScript("scriptfile","entrypoint"); spawn another proccess with a new script (the calling script waits for the other script to continue, or yeild).
Once a script is done executing, it's proccess object is destroyed.
Hopefully this will give you some ideas as to what kind of functionality is helpful in an RPG. Magic C is _very_ general in that it could be used in almost any kind of game, you might opt for a more specialized aproach, in which it would be easier to build the system.
If you need any more information let me know :-D
P.S. Below is a script from Morning's Wrath,
A fine example of basic NPC interaction using Magic C
OnLoad(){ $gnumtalk1=0;}OnMouseClick(){ switch($gnumtalk1) { case 0: SpriteLookAtSprite($lpmorning,$lpgsoldier1); Talk("Hail, Princess Morning.","",true); $gnumtalk1=$gnumtalk+1; break; case 1: SpriteLookAtSprite($lpmorning,$lpgsoldier1); Talk("My family has served Castle Iridine for many generations.","",true); $gnumtalk1=$gnumtalk+1; break; case 2: SpriteLookAtSprite($lpmorning,$lpgsoldier1); Talk("We trace our service as far back as the Ashidian war.","",true); break; } }
Wow, some great advice is in here. Just out of curiousity, how long do your "failed RPG attempts" stay in development for? I'm on my first RPG, first ever game right now (see sig) but I'm just doing it for fun. I can't say whether its a crystal or a goo ball right now (can it be both?), but the project is 3 months old and stronger than ever before. I've got about 4 years of programming experience in multiple languages and creating a wide range of applications, but I quickly came to realize that game programming is in a category of its own.
To anyone that has completed or almost completed a successful RPG, do you have any tips regarding the actual design process itself? I think my game has been mediocre with its design so far, but that was mostly my fault due to a lack of experience with programming games. Thanks for any advice you can give. :)
To anyone that has completed or almost completed a successful RPG, do you have any tips regarding the actual design process itself? I think my game has been mediocre with its design so far, but that was mostly my fault due to a lack of experience with programming games. Thanks for any advice you can give. :)
Author
Thanks for the speedy response!
I really like Magic C and grats on creating it, it seems like a very solid and well thought out system.
While I would love to use it, I think that porting it over into VB .Net may prove to be difficult. I would also like the satisfaction (and experience) of writing my own system. I will definitely keep Magic C in mind as I plan out my system. My biggest obstacle, as you said, will be implementing it. Any thoughts or pointers on that topic would be greatly appreciated.
I feel selfish asking all these questions but with all these excellent responses, how could you not?
Looking forward to anything else you feel inclined to bless me with.
Ion
EDIT: Roots, my attempts only stayed in development for about a month. Not all of them where RPG's, but its the same for all my games. I dream too big and don't plan enough. I have to learn to live with that fact that i'm not going to make a commercial quality game after my first go. I have plenty of time in my life to get things right and make a game i'm proud of. You seem to have been blessed with an a talented team, and from my experience those are pretty rare to come across. I learn alot after each attempt (I guess their not failures after all, are they?) and I feel strong enough about this game that I am retrying it, in hopes that I can make it a little farther this time. Anyways, enough rambling. I think i answered your questions a few chaptes ago so i'm off now!
I really like Magic C and grats on creating it, it seems like a very solid and well thought out system.
While I would love to use it, I think that porting it over into VB .Net may prove to be difficult. I would also like the satisfaction (and experience) of writing my own system. I will definitely keep Magic C in mind as I plan out my system. My biggest obstacle, as you said, will be implementing it. Any thoughts or pointers on that topic would be greatly appreciated.
I feel selfish asking all these questions but with all these excellent responses, how could you not?
Looking forward to anything else you feel inclined to bless me with.
Ion
EDIT: Roots, my attempts only stayed in development for about a month. Not all of them where RPG's, but its the same for all my games. I dream too big and don't plan enough. I have to learn to live with that fact that i'm not going to make a commercial quality game after my first go. I have plenty of time in my life to get things right and make a game i'm proud of. You seem to have been blessed with an a talented team, and from my experience those are pretty rare to come across. I learn alot after each attempt (I guess their not failures after all, are they?) and I feel strong enough about this game that I am retrying it, in hopes that I can make it a little farther this time. Anyways, enough rambling. I think i answered your questions a few chaptes ago so i'm off now!
For tutorials on script-engine making, you can take a look at PxdScript, made by peroxide. You can also check the tutorials here in gamedev.
Keep in mind this tradeoff: learning Vs finishing your game. If you try to learn while making your game, then be prepared to push the deadlines a "few" times.
Quote:Original post by IonDefender
(...)I would also like the satisfaction (and experience) of writing my own system.
Keep in mind this tradeoff: learning Vs finishing your game. If you try to learn while making your game, then be prepared to push the deadlines a "few" times.
I am victim of the dream too big plan too little disease as well. Also victim of the play too much code too little disease. Heh.
Anyway, I finally decided to focus my goal on producing a workable RPG with the complexity of Ultima I. I'm actually "cloning" it in a general sort of way, so I can have side by side comparisons of the actual real working (and still fun!) game versus my own look alike. I'm incorporating a few minor differences of course, but nothing drastic until I get everything functioning like the original.
After a few weeks I've almost finished character creation. Full time job, wife, two kids with one on the way doesn't help in the finding time to code department. Consequently I get a couple of hours a day, or every other day, if that.
But the concept of Keep It Simple Stupid will go a long way for us hobby programmers, I believe. I think it cannot be overemphasized that there is a great need to constrain yourself to a limited subset of your "Dream Game" so you'll actually be able to finish. And getting something simple working is so much more important, I think, than planning on getting something complex.
Take care, and awesome thread!
Anyway, I finally decided to focus my goal on producing a workable RPG with the complexity of Ultima I. I'm actually "cloning" it in a general sort of way, so I can have side by side comparisons of the actual real working (and still fun!) game versus my own look alike. I'm incorporating a few minor differences of course, but nothing drastic until I get everything functioning like the original.
After a few weeks I've almost finished character creation. Full time job, wife, two kids with one on the way doesn't help in the finding time to code department. Consequently I get a couple of hours a day, or every other day, if that.
But the concept of Keep It Simple Stupid will go a long way for us hobby programmers, I believe. I think it cannot be overemphasized that there is a great need to constrain yourself to a limited subset of your "Dream Game" so you'll actually be able to finish. And getting something simple working is so much more important, I think, than planning on getting something complex.
Take care, and awesome thread!
Speaking as someone who has completed my own engine, I would advise you to use an an engine that has already been written. Check out Spiderweb Software's games. They have their own map editors. If you can write a good game using his engine that people are prepared to buy, then you're on your way. I'm sure he would work something out with you if you made an awesome game.
Its one thing to write a good engine. However it is another thing entirely to make fun and addictive games that people will fork out money for.
I'm still learning the latter. :)
Its one thing to write a good engine. However it is another thing entirely to make fun and addictive games that people will fork out money for.
I'm still learning the latter. :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
