[This Newsletter post is now quite out of date, however it is included for archival purposes. It may contain information that is no longer accurate and some dead links]
Introduction
This is the first OMMORPG newsletter. The OMMORPG is an open source community project for DBPro that you can help with now. This is the site for the project hosted by Kenjar. He also was kind enough to give us a forum to go along with it which is located HERE. So go and help with the project now! :D
[ Note: We have since found new webhosting (and this blog site for the newsletter) and have a new address for the forums at http://www.ommorpg.vectramedia.net ]
We also have a lot to cover in this newsletter with all the things we did and what we have.
OMMORPG Progress
by Slayer93
by Slayer93
We have made a lot of progress since we started. We are almost done with a demo where you can do quest walk around and fight enemies and loot them. We have many screenshots right here and even more on our forum.
And some screenshots:
And some screenshots:
If you want to try out what we have now there is an easy way to get it. Look at this post for more infomation:
Code Center
One feature of our code I would like to talk about is our skills system. In developing the skills system, we have introduced some coding concepts to DarkBasic. The first coding hurdle we jumped was a static number of function arguments. Normally, functions can only have a set number of arguments. If you set the function up for three arguments, then three is all it will accept. Try to pass more or less arguments to the function and the IDE compiler will stop to let you know. Using a word parser (developed by Slayer), we can bypass this by entering a single string containing the arguments list, which can be any length. The compiler sees only one argument passed to the function, and then the parser extracts the actual arguments from within the string.
Our next coding concept explains why we needed a dynamic number of arguments passed to a function. We wanted a flexible skills system so we could add new skills as needed. This presented several obstacles. The first was a scripting system so new skills could be added without having to add code. The problem was developing a scripting system that was flexible enough to handle melee skills, missile skills, craft and artisan skills, magic skills, and the list goes on. A system this robust is nearly impossible to code in DBPro. So, we compromised.
The compromise was to acknowledge there is no way to reasonably script every possible skill into DBPro. Skill Categories was the solution. Each skill can be fit into a skill category – even if that category has only a single skill. Each skill category can then handle the script appropriately. For example, our melee skill category times a combat strike, checks for melee range, and when the time is right, calculates the attack results: Did the PC hit or miss?
For flexibility, we added on a damage skill category. The attack skill category can trigger a damage skill, which determines how much damage to apply to the combat target. Of course, the compromise is that skill categories need to be hard-coded, but the skills that fall under that skill category are scripted.
Beside the ability to trigger other skills, skill categories can reference active skills. A great example of this is PC Characteristics. Characteristics are handled by their own skill category. No, they are not just a global variable attached to a player, but they are always-active skills. When a melee attack skill is activated, it can check to see if a given characteristic (or more) is active and what the value of that characteristic is.
It may still seem like we should be handling characteristics as global variables instead of active skills. Consider the flexibility skills have over variables. We can go in and rewrite the available characteristics and skills in a matter of minutes (maybe an hour), which would otherwise take hours or days to replace. Also, we can dynamically change characteristics and skills in game (should we have any need to). What kind of game could be made if the player could define their own characteristics and skills? What if the player can create new skills in game (controlled of course)?
Allow the player to create their own attack style? Allow the player to create their own spells? Have an NPC to award the player with a random new skill (or even characteristic)?
Another added feature of the skills system is that it does all its own work. The code controlling the player does not trigger skills. Instead, the skills system (on its own during a skills management function call) checks for the various triggers for different skills. In most cases, this is a button or a key press, but it could be simply checking to see if a particular flag (variable) has been set. Some skills are always active, so there is no trigger. Other skills can only be activated by other skills. An example of this is a melee damage skill is only activated by a melee attack skill.
Skills not only seek their own inputs, but they also handle their own outputs. In some gaming systems, skills use up fatigue. Skills in this system can be coded to lower the player’s fatigue by an amount defined in the skills script. Magic skills will produce and manage their own effects (particles or whatever). While the category handling magic skills has to be hard-coded into the game, each magic skill can then be scripted with plenty of variable settings to let the magic category know how to produce the magic effects.
In the end, flexibility is the answer. The skills system currently up and running (test it for yourself) is doing the job it was intended to do. I, for one, just can’t wait until we get to use it to its full potential.
Skill System
by RiiDii
by RiiDii
One feature of our code I would like to talk about is our skills system. In developing the skills system, we have introduced some coding concepts to DarkBasic. The first coding hurdle we jumped was a static number of function arguments. Normally, functions can only have a set number of arguments. If you set the function up for three arguments, then three is all it will accept. Try to pass more or less arguments to the function and the IDE compiler will stop to let you know. Using a word parser (developed by Slayer), we can bypass this by entering a single string containing the arguments list, which can be any length. The compiler sees only one argument passed to the function, and then the parser extracts the actual arguments from within the string.
Our next coding concept explains why we needed a dynamic number of arguments passed to a function. We wanted a flexible skills system so we could add new skills as needed. This presented several obstacles. The first was a scripting system so new skills could be added without having to add code. The problem was developing a scripting system that was flexible enough to handle melee skills, missile skills, craft and artisan skills, magic skills, and the list goes on. A system this robust is nearly impossible to code in DBPro. So, we compromised.
The compromise was to acknowledge there is no way to reasonably script every possible skill into DBPro. Skill Categories was the solution. Each skill can be fit into a skill category – even if that category has only a single skill. Each skill category can then handle the script appropriately. For example, our melee skill category times a combat strike, checks for melee range, and when the time is right, calculates the attack results: Did the PC hit or miss?
For flexibility, we added on a damage skill category. The attack skill category can trigger a damage skill, which determines how much damage to apply to the combat target. Of course, the compromise is that skill categories need to be hard-coded, but the skills that fall under that skill category are scripted.
Beside the ability to trigger other skills, skill categories can reference active skills. A great example of this is PC Characteristics. Characteristics are handled by their own skill category. No, they are not just a global variable attached to a player, but they are always-active skills. When a melee attack skill is activated, it can check to see if a given characteristic (or more) is active and what the value of that characteristic is.
It may still seem like we should be handling characteristics as global variables instead of active skills. Consider the flexibility skills have over variables. We can go in and rewrite the available characteristics and skills in a matter of minutes (maybe an hour), which would otherwise take hours or days to replace. Also, we can dynamically change characteristics and skills in game (should we have any need to). What kind of game could be made if the player could define their own characteristics and skills? What if the player can create new skills in game (controlled of course)?
Allow the player to create their own attack style? Allow the player to create their own spells? Have an NPC to award the player with a random new skill (or even characteristic)?
Another added feature of the skills system is that it does all its own work. The code controlling the player does not trigger skills. Instead, the skills system (on its own during a skills management function call) checks for the various triggers for different skills. In most cases, this is a button or a key press, but it could be simply checking to see if a particular flag (variable) has been set. Some skills are always active, so there is no trigger. Other skills can only be activated by other skills. An example of this is a melee damage skill is only activated by a melee attack skill.
Skills not only seek their own inputs, but they also handle their own outputs. In some gaming systems, skills use up fatigue. Skills in this system can be coded to lower the player’s fatigue by an amount defined in the skills script. Magic skills will produce and manage their own effects (particles or whatever). While the category handling magic skills has to be hard-coded into the game, each magic skill can then be scripted with plenty of variable settings to let the magic category know how to produce the magic effects.
In the end, flexibility is the answer. The skills system currently up and running (test it for yourself) is doing the job it was intended to do. I, for one, just can’t wait until we get to use it to its full potential.
Buttons!
by Slayer93
Ok to start with I will show the complete finished code thats easy to implement. This code was made by RiiDii. There button functions. This will allow you to create buttons fast and easy. It also has its own parser to write scripts outside of your game. We also have a button viewer Slayer93 made to view how your buttons look and work in DBPro. You can download the code from below.
To use the buttons you must first Intialize the buttons using Intialize_buttons. You can use Parse_file to read the buttons from a file or Make_button to create a button right in dbpro. They're also alot of other usefull things such as hiding and showing buttons. Here is a pic of RiiDii's button code and my Button Viewer in action. Featuring Nevereverends HUD images.
by Slayer93
Ok to start with I will show the complete finished code thats easy to implement. This code was made by RiiDii. There button functions. This will allow you to create buttons fast and easy. It also has its own parser to write scripts outside of your game. We also have a button viewer Slayer93 made to view how your buttons look and work in DBPro. You can download the code from below.
To use the buttons you must first Intialize the buttons using Intialize_buttons. You can use Parse_file to read the buttons from a file or Make_button to create a button right in dbpro. They're also alot of other usefull things such as hiding and showing buttons. Here is a pic of RiiDii's button code and my Button Viewer in action. Featuring Nevereverends HUD images.
Button Viewer - [Download]
Button Code - [Download]
Script System
by Slayer93
I have been working on a script system that can be used by anyone who owns DBpro. The script system allows you too create commands and right scripts in files to parse to help you layout your game and run your game.
Creating a command is simple all you have to do is go to a function called parse_string() which parses a string. In there you are going to put a case/endcase statement between the select/endselect statement if you dont know what those are look in the help file or an existing project with mutliple commands already (provided in a download at the bottom). For the data of the case statement put the command you will like to make. Once you have done that you will be able to get the parameters that have been taken out of the string in an array called psentences(). You can use those parameters to do what you want. Here is an example:
case "text"
text val(psentences(0)),val(psentences(1)),psentences(2)
endcase
In a script file it will look like this text 0,0,Hello this is a test
Final notes on creating commands- in the case data it can only be one word. The psentences array is a string so you have to use the val() command to make it a value and sometimes the int() command.
I have also created a flag system. The flag system will allow you to run certain parts of your script at certain times. To make a flag in the script since I already made the command for you. You have to use a command called newflag (in the commands list with download). Then it will store commands for later use. To activate a flag when you want you have to use activateflag (also in commands list). You can only set the activation times the engine has or if you make your own using flagcheck. To create the flag in the engine you have to use a function thats called check_flag_data() and put check_flag_data(right$(flagcheck$,len(flagcheck$)-1)) in so you can use flagcheck. You can see an example of this within the project for download.
There is also a variable system in place to create your own varibles. Varibles will have to be created using the var command (in commands list). You will be able to use a varible in any parameter since it changes a varible name into a varible value before it looks up commands.
Just keeps getting better and better right. I also have a lot of different functions you can use besides the parse_string and parse_file. You can store string words/parameters or just get the one you want with the list of function names in the project download.
store_words()
store_parameters()
get_word(string$,word)
get_parameter(string$,word)
A final note to use this make sure you Intiate the parser using Intiate_Parser Try it out with this project and the commands list. See if you can make your own commands.
Button Code - [Download]
Script System
by Slayer93
I have been working on a script system that can be used by anyone who owns DBpro. The script system allows you too create commands and right scripts in files to parse to help you layout your game and run your game.
Creating a command is simple all you have to do is go to a function called parse_string() which parses a string. In there you are going to put a case/endcase statement between the select/endselect statement if you dont know what those are look in the help file or an existing project with mutliple commands already (provided in a download at the bottom). For the data of the case statement put the command you will like to make. Once you have done that you will be able to get the parameters that have been taken out of the string in an array called psentences(). You can use those parameters to do what you want. Here is an example:
case "text"
text val(psentences(0)),val(psentences(1)),psentences(2)
endcase
In a script file it will look like this text 0,0,Hello this is a test
Final notes on creating commands- in the case data it can only be one word. The psentences array is a string so you have to use the val() command to make it a value and sometimes the int() command.
I have also created a flag system. The flag system will allow you to run certain parts of your script at certain times. To make a flag in the script since I already made the command for you. You have to use a command called newflag (in the commands list with download). Then it will store commands for later use. To activate a flag when you want you have to use activateflag (also in commands list). You can only set the activation times the engine has or if you make your own using flagcheck. To create the flag in the engine you have to use a function thats called check_flag_data() and put check_flag_data(right$(flagcheck$,len(flagcheck$)-1)) in so you can use flagcheck. You can see an example of this within the project for download.
There is also a variable system in place to create your own varibles. Varibles will have to be created using the var command (in commands list). You will be able to use a varible in any parameter since it changes a varible name into a varible value before it looks up commands.
Just keeps getting better and better right. I also have a lot of different functions you can use besides the parse_string and parse_file. You can store string words/parameters or just get the one you want with the list of function names in the project download.
store_words()
store_parameters()
get_word(string$,word)
get_parameter(string$,word)
A final note to use this make sure you Intiate the parser using Intiate_Parser Try it out with this project and the commands list. See if you can make your own commands.
Media Corner
One Model, Infinite Characters
by Nevereverend
I've been part of several discussions on the forums where a new model and UV map has been posted, and several people have commented that they would like to make a new texture for the model. Unfortunately, once one person seems serious about doing it, the other people who had been interested just don't bother. I think this is quite unfortunate, since we get only one retexture for the model where we could easily have gotten three, four, or more.
You see, each person who submits a retexture of a model is effective creating a brand new object for the game. A house, may be the same model, but it appears different if it is made to resemble wood as opposed to brick. Which of course, looks very different from stone. Three differend materials textures applied to a model creates three different objects which can be used in the game.
And all of this is especially true of character models. Even something a simple as changing the skin color in a character model makes for a very different appearance. Consider these two characters, both made with a "male human" model provided by Kenjar some time ago. Just changing the skin tone from peach to brown has resulted in a new appearance.
One Model, Infinite Characters
by Nevereverend
I've been part of several discussions on the forums where a new model and UV map has been posted, and several people have commented that they would like to make a new texture for the model. Unfortunately, once one person seems serious about doing it, the other people who had been interested just don't bother. I think this is quite unfortunate, since we get only one retexture for the model where we could easily have gotten three, four, or more.
You see, each person who submits a retexture of a model is effective creating a brand new object for the game. A house, may be the same model, but it appears different if it is made to resemble wood as opposed to brick. Which of course, looks very different from stone. Three differend materials textures applied to a model creates three different objects which can be used in the game.
And all of this is especially true of character models. Even something a simple as changing the skin color in a character model makes for a very different appearance. Consider these two characters, both made with a "male human" model provided by Kenjar some time ago. Just changing the skin tone from peach to brown has resulted in a new appearance.
Other characters can be made by changing the clothing, armor, and facial features to make many humans -- easily enough to populate a whole village. Consider these characters, also made from the same model as before.
And this model can even be used to make something far more menacing. With a little time spent in photoshop, the human was made into a zombie.
The variety of simple changes you can make to a model's appearance are nearly infinite. Similar modifications have been made among other models, as well. Poke around the forums for a while, and see how many giant lizards have been made using the Rox Lizard model.
I encourage everyone who has considered retexturing a model to do it, no matter how many other people say they are going to do it, too. Our community can only benefit by having five choices for the look of a character instead of only one.
Ready For Battle
Music by Tallun
3D models and 2D artwork isn't the only kind of art. Tallun made some music for the project which sounds great! This is used in the intro sequence of the game and you can download it from below. Listen to it and give feedback at our forum!
Here are some great skyspheres made by SteveJ. He has created a lot in little time and they look awsome so I had to included it in the Newsletter. They're huge so I will link them and you can see each one without taking up the whole page.
Moutains
Night
SunRising
Sunset
Sunset2
Sun Rising 2
Desert
Snow
Seas
Here is what they look like in the game:
Outro
If you contributed something but didn't see it in the newsletter don't worry, there are a lot of things to write about and little space to do it. We'll get to your contribution soon enough! Don't forget to visit our forums, thats where our information comes from.
Our forums are Here.
Our forums are Here.
No comments:
Post a Comment