Hello!
It's been a busy time for all of the staff... @Voo making some slick GUI, @QueenC creating some of the most beautiful graphics I've ever seen, and myself working on most of the boring backend systems, which is what I will be discussing today.
About time for an update wouldn't you say?
These past few weeks I've been finalizing the whole item system, which consists of the basic behaviors of items such as how they fit into various windows like inventory and banks, as well as the rules that govern how a user can loot, drop, re-arrange, split, and use items. While it took me nearly 3 weeks to program this, a user can experience all of the functions in about 30 seconds of gameplay. It's crazy how long it takes to do some of this!
But right now I'm working on something a little more fun: NPCs and Quests.
What I did to make this easier on myself was actually design my own language specifically for NPCs. This makes production of NPCs incredibly more efficient. Let's take a look....
Everytime an NPC says or does something, it all belongs inside a file. This file is broken down by each window that the player sees. I have defined this window as an open and closing bracket like so:
The system works on a progression of 'tags'. The program knows to look for #PreCheck_0 first and then will decide what to do from there. Inside the first precheck, we can ask the NPC to check for some things, most commonly whether a user has completed a quest or not.
So for example in the code above, checkQuest(33) tells the NPC to check the server for this user's status on quest #33. The following 3 lines determine what the NPC will do in each possible case. The line "ifNotStarted" tells the NPC to go to #Convo_0 if and only if the user has not started quest #33. And the other two possibilities of a quest are that the user has started but not finished, or has completely finished the quest.
Let's have a look at the database design for this:
The database design is very simple. It has fields for:
1. 'uniqueID' which does nothing more than organize it in the database
2. 'charID' which references the character's unique ID #
3. 'questID' which is the quest's ID
4. and finally the 'questStatus'
We can see that quest #33 has status 1. Status 0 means the quest has not been started, status 1 means the quest is in progress, and status 2 means the quest is complete.
If we look back to the NPC code, we can again see how the conversation can progress from the original check. Since this user has status 1 for quest #33, the NPC will know to follow the 'ifInProgress' line. Looking at the ifInProgress line we observe that the NPC will go to tag: #Convo with status: 100.
A very simple and generic NPC would say something like this in that case:
I forgot to mention that every time a player speaks to an NPC he/she will have two choices of what to say, which can lead in very, very different directions consequently allowing for dynamic NPCs and quest progressions. Say the wrong thing and an NPC wont even offer you a quest.
This is denoted by the Player_A_Say and the Player_B_Say.
So anyway, if the player were to click the first speech bubble, the NPC would then go to the #CompleteQuest tag in which case it would check to see that the user has completed the quest. If the user clicked the second speech bubble, which has the tag #End, then the NPC would close its conversation with the player.
Finally to put everything together, here is what the quest prerequisites and requisites look like:
Did you think that was cool? I thought it was pretty cool. We should ask Sheep what he thinks...
Hope everyone is doing well. We will continue to keep everyone updated with more cool progress reports
Best,
Ian
It's been a busy time for all of the staff... @Voo making some slick GUI, @QueenC creating some of the most beautiful graphics I've ever seen, and myself working on most of the boring backend systems, which is what I will be discussing today.
About time for an update wouldn't you say?
These past few weeks I've been finalizing the whole item system, which consists of the basic behaviors of items such as how they fit into various windows like inventory and banks, as well as the rules that govern how a user can loot, drop, re-arrange, split, and use items. While it took me nearly 3 weeks to program this, a user can experience all of the functions in about 30 seconds of gameplay. It's crazy how long it takes to do some of this!
But right now I'm working on something a little more fun: NPCs and Quests.
What I did to make this easier on myself was actually design my own language specifically for NPCs. This makes production of NPCs incredibly more efficient. Let's take a look....
Everytime an NPC says or does something, it all belongs inside a file. This file is broken down by each window that the player sees. I have defined this window as an open and closing bracket like so:
- Code:
#PreCheck_0 {
checkQuest(33)
ifNotStarted(#Convo,0)
ifInProgress(#Convo,100)
ifComplete(#PreCheck,1000)
}
The system works on a progression of 'tags'. The program knows to look for #PreCheck_0 first and then will decide what to do from there. Inside the first precheck, we can ask the NPC to check for some things, most commonly whether a user has completed a quest or not.
So for example in the code above, checkQuest(33) tells the NPC to check the server for this user's status on quest #33. The following 3 lines determine what the NPC will do in each possible case. The line "ifNotStarted" tells the NPC to go to #Convo_0 if and only if the user has not started quest #33. And the other two possibilities of a quest are that the user has started but not finished, or has completely finished the quest.
Let's have a look at the database design for this:
The database design is very simple. It has fields for:
1. 'uniqueID' which does nothing more than organize it in the database
2. 'charID' which references the character's unique ID #
3. 'questID' which is the quest's ID
4. and finally the 'questStatus'
We can see that quest #33 has status 1. Status 0 means the quest has not been started, status 1 means the quest is in progress, and status 2 means the quest is complete.
If we look back to the NPC code, we can again see how the conversation can progress from the original check. Since this user has status 1 for quest #33, the NPC will know to follow the 'ifInProgress' line. Looking at the ifInProgress line we observe that the NPC will go to tag: #Convo with status: 100.
A very simple and generic NPC would say something like this in that case:
- Code:
#Convo_100 {
NPC_Say(Have you completed your quest yet?)
Player_A_Say(Yes I did.)
Player_A_Send(#CompleteQuest,33)
Player_A_Say(No I did not.)
Player_A_Send(#End,0)
}
I forgot to mention that every time a player speaks to an NPC he/she will have two choices of what to say, which can lead in very, very different directions consequently allowing for dynamic NPCs and quest progressions. Say the wrong thing and an NPC wont even offer you a quest.
This is denoted by the Player_A_Say and the Player_B_Say.
So anyway, if the player were to click the first speech bubble, the NPC would then go to the #CompleteQuest tag in which case it would check to see that the user has completed the quest. If the user clicked the second speech bubble, which has the tag #End, then the NPC would close its conversation with the player.
Finally to put everything together, here is what the quest prerequisites and requisites look like:
Did you think that was cool? I thought it was pretty cool. We should ask Sheep what he thinks...
Ian: Hey Sheep, is this not the most interesting thing you have ever laid eyes upon?
Sheep: Unimpressed sheep is very unimpressed with you.
Hope everyone is doing well. We will continue to keep everyone updated with more cool progress reports
Best,
Ian