How to develop a Quest System? process? ways?

hi me and one of my friends are slowly developing a mmorpg type game starting with most of the basic controls, we have ai for enemies and allies and we have most gui's set up as layouts.

now i encountered a problem into trying to figure out how to make a quest system.
i'm using c#, so far i don't know much about classes(objects) and arrays.

the way it works now is that once you click on a npc we display the gui that gives us the quest.
now i'm trying to figure out how would i go about adding this quest onto my character journal/Quest tracker gui.
pretty much we got 2 windows one for the quest giver and the one tracking it.
and how to track the elements for the quest?? for example if for my quest i need to get or kill a certain amount of monsters how will the npc know?? any ideas?? or snippets? or blocks of code i could use??

by the way this is c# but if you only do javascript that's ok, i could figure out the conversions. thanks.

 

Are you currently running it over a database, ie mysql?

 

not at the moment, i'm developing everything locally before going into multiplayer. i pretty much need some theory of how to apply it and what might work for such system

 

I'm currently messing around with making a quest system. The way I was thinking of doing it since I'm not doing it multiplayer either. The idea I had was to create something like a QuestObject Data Type where it can hold different information of types of quests variables.. such as kill(GameObject go, int numOfTypestoKill), gather(GameObject go, int numOfObjectstoFind), find(GameObject go, string name), etc.. So it referenced to whatever gameobject if needed. From there you could make a QuestDialog for each NPC you wanted and give them individually there own QuestData. I was looking into making my own Editor to do this so it would be easier to Implement with multiple npc's.

Honestly I'm not sure how practicle it is but its just the way I thought about it.

 

in my case i'm trying to look at it in a simpler way so for example i currently can click on the npc and he will pop up with a quest window for me to accept the quest.
my question would be how to track it?
how to put the information for that quest into another gui?
i could maybe create a counter that counts for kills for enemies?
my problem would be learning to display the exact same quest? maybe arrays? then again i don't know how to use them very well as of yet.

 

I'm making an RPG by myself, and I've been doing some theory work on how the quest system is to work. And basically, the quest is just going to be a class, that gets attached to the player, and then it keeps track of goings on and updates accordingly.

 

first i would already give the player a list of all quests he can get during the game and just mark them as "unknown", "obtained", "completed" or whatever states you require. this is helpful if one quest can be triggered by several events for example talking to npc, reading a board or finding the quest item without the quest. or if the quests depend on each other (for mainquest b mainquest a must be completed). and this also prevents that a quest is given several times to the player. this also allow your items to know to which quests they belong. simply let the item have an index to the quest. and you can extend the list by adding further quests without disturbing former quests. you can search notunlocked quests to lead the player in a direction to get them. and so on.
in the end you need to store all fullfilled quests anyway so store them from the beginning and unlock them to the player as he gets them.
this is only practicable if you manual design the quest beforehand. if you create them procedurally this doesnt help. and if the players can and will do most of the quests in the game instead of a very small portion.

the things which shall be achived need to be in classes. for example you have a class for pickup an object, for reaching a destination, for killing a monster. a quest then is a collection (or 1) of these things (list of baseclass, indices in databasetables). i would then add special prefabs to the scene which trigger these aims and which know to which quest and aim they belong. for example a spherical trigger collider is to reach that position. if it gets triggered by a player it looks up its index in the players questlist and sets this aim to completed. a questitem is placed in the world and also knows to which quest it belongs. when it is collected the itemsystem sets the aim at this index to fullfilled. similar with killing monster/npc quests. when the things in the world know to which quests they belong it is fairly simple to add them, move them around, search for them (during development and gameplay). if you want to add a new type of aim simply add a questid and the logic to check for it when the player does something or triggers something.

i hope that explanation helps a bit. i have not implemented this yet but this system has been builded from my thoughts about that topic. its important to keep the things simple and extendible because you will change alot during testing and balancing.

 

Quest systems can be quite complex - it depends what you want to be able to quest.

Prerequisite conditions - what level, skill, class, NPCs, quests do you need done beforehand.
Fail conditions - if an NPC dies as in an escort mission.
Active - might be a limited time quest say giving you 5mins to complete it.
Progress - multi part quest and the dialogue progression.
Reward - could be an item, skill, xp

So you see that you need to be able to reference NPCs, other quests, items, skills/classes, etc.
A lot of quest systems are done in LUA scripts and based loosely on state machines - and are a lot of work, especially testing/debugging.

 

Very cool conversation. Thanks for the ideas.

 

that is very help full, me as some intermediate programmer i probably need to learn to use classes, arrays, list and collections.
any help full links about it?

it does make sense to have all the quest stored in the player and unlocking them as i go and use the functions such as OnTriggerEnter, and etc.

now in order to start simple where should i start from?? if i'm able to get some kind of system i will share it.

 

My idea would be that when you get a quest,
you create a component (a monoscript) and inside that is the quest,
with variables like what they have to kill, how many etc.
Then you have the player object, that on every time the player kills an enemy or whatever,
it sends a message to it's components containing the AI it just killed, then the quest component will increment the amount of kills for that object.
And when a script is completed, it will send a message UP to the player component and that function will handle the pop up / whatever that happens when you complete a quest.
Then you add the quest that you finished's component name to a list of completed quests by that player, so they cannot run it again.

 

that is a very good plan you got there MarkusDavey, now in my part i honestly just need to figure out how to pseudocode it so i have some kind of template since i'm more of a visual person and artist, learn the functions i might need to use and put it together.

at my pace it might take a little while.
so far like i said earlier i just have a npc in wich if you click on him, he shows you the quest and you can eighter accept or decline.
Now all i need to do is to make that connection to show up in my journal to be able to track.
this would be cool as a comunity project, since lots of people worked on a inventory script using arrays, columns and rows for visuals and etc.

so to start i'm going to have the quest already made inside the player for simplicity and once he find that npc that gives the quest i'm going to use a boolean to turn on the gui part for me to track.

honeslty it would leave me stuck trying to figure out how can i minimize and maximize a gui meaning for example have all the quest displayed inside a window wich will be called (Journal) in there maybe some text areas? or rects will display the script. but i wouldn't be able to know how to place them correctly positioned.

about being positioned i don't mean the regular declaring the variables and putting the floats or ints for placement but for example the ideal way i would like to try to set up the display would be:

once i aquired the Quest and i open my journal i will see some rects containing the quest info and tracking, so by default no matter the order of unlocking scripts they should stack up from top to bottom meaning the display if you could imagine playing wow having lots of quest, and once i click on one of them it will open or scale bigger inside the journal window so i could see the information about my quest.

any ideas?
after it i could figure out on my own things such as variables to make it unknown, complete and etc like exiguous said. "Thanks for that idea".

and once it's completed then maybe try to refactor the code and make it so when you drag the script on the player, you can just simply write your quest down and get maybe a script called quest connecter for the npc's. but (this last part is just a random out of the box dream as of now) besides it would be cool to share and let others be able to use and develop their own quests.

 

i think developing a generous method is much more complicated than making one fitting your special needs. so i would concentrate on that instead of a multi-purpose system for all people. especially when you have not a strong programming background (no offense!).

and i think in 1 point i had not been clear. for the sake of consistency all npcs, items and triggers should contain a questid (and script) which is always checked when they are killed/collected/triggered. but normal stuff has a quest id of -1 for example and all numbers above refer to a quest in the list.

concerning your displaying issues:
that is only cosmetic and should not be your main problem. in general its always better to divide data and logic from its visual representation. first make the logic run and if it is ugly you can make it beautiful afterwards. you simply should have a scene or a gui which simply displays the data from the questlist (with filters, sorting, links to map etc).

hint:
when you dont know classes is generally bad. you work all the time with them in unity. every scriptfile is a class.

to start:
make a class for a quest with attributes like state (unknown, completetd), giver, reward, timeout, description.
add a list of questclass to your player (can be also filled from a database, xml file or a script).
make an abstract baseclass or interface for your aims and and a list of that to the questclass.
implement the aimclass for every type of aim you want (goto, kill, collect).

then fill the questlist in the player with data (instantiate your classes). also fill the world with the relevant questitems/monsters etc (having a questid refering to an entry in the questlist and an aimid for referencing the aim). when it gets triggered/killed/collected check for the questid and if > -1 set the aim of the quest completed. check if there are further uncompleted aims (display a hint or an arrow with direction) if not the quest is completed.

thats how i would do it.
also its very crucial to think about what your questsystem should be able to do in the beginning and design it with that in mind. especially all the aims should be thought about before you code. also think about if the player must return to the questgiver to get his reward, if it is an explicit aim to return or it is implicit for every quest.

 

thanks for the advise, i know every script in c# is a class, by a class i mean a object in which you need a constructor, a destructor, the getter and setters and etc. i don't know if you know what i mean. or you just pretended to know what i mean in the last post?

 

Your GUI problem is easier than you'd think. All you have to do is brush up on your GUI skills and learn GUI groups and windows, and fiddle about with those for a while.

I can't really find any good GUI tutorials, nor do I know exactly how far along you are with Unity and GUIs etc, So I'll leave it to you to look at the Unity Script Reference and familiarize yourself.

 

my problem about gui is not coding it since it's getting easier by just looking at the reference manual and scripting reference, the problem i have is to pass the info to another gui, renferencing somehow or trying several getcomponents.

i have some idea in mind like maybe put everything on the player, and do the gui for each quest inside the jounral window and such, my problem would be making it so when you know about the quest and saying that a boolean will activate it, i would need to first be able to maximize and minimize the information of the quest of the journal window some how.

other ways i though about it by maybe using arrays? or lists?

 

A centralised GUI manager would probably be a good idea, and then even strap the quest classes to the GUI manager. So then you can declare a public QuestExample1 Instance; so in the gui manager, you can refer to it as QuestExample1.Instance.SomeFunction().

But depending on if you will have all quests strapped to the GUI manager at all times is up to you. But it's a suggestion. I'm at work at the moment so I can't really test what I'm saying at the moment.

 

People worry about the GUI too much, it shouldn't be an integral part of the underlying design. It's just a method for the User to I/O with all the stuff going on under the hood.

I've seen a project with OnGUI functions in every single script, all hardcoded into the game mechanics. An utter nightmare of spaghetti!
It should be more like -
Click NPC -> Event... Click Accept Quest -> Event... The GUI should really only show you the results of your actions.

You should be able to replace the GUI with ease. Later you might want to change which GUI framework you use, for more features. Think about how you can completely modify/change the skins of some MMOs.

 

Basically what I said Being that he should have a centralised GUI manager that runs all GUI aspects (or as many as possible) that is called by and calls events.

It isn't hard, just a lot of work

 

Aye! I know.
I was just a bit dumbfounded why GUI was being mentioned in relation to a quest system! lol

 

I guess a Quest system relies on the GUI somewhat more heavily than most other features, and that the deliverance method was what he was after (considering he's been advised on numerous other ways to make the system its self) So, it didn't rush into GUI, he was just concerned. BUT! Something good came out of this on my part. It reminded me to sort out my GUI system lol.

 

My only main question in which I'm confused about gui is how to make a window inside a window, be able to open the different quests inside a window and how to positionem in order? Normally on a gui function I have to hayride the size and position of the screen.

So about the quest design I'm guessing using a collection list since the array its rezisable,
Then again im still a noob in things such as classes.

I will attempt to make a simple nested if statements type quotes and show code to see what I can do to evolve this.

By the way I want speaking about the quest gui art. I don't mind looking simple I meant how to sort them as I get them and display the information from one gui to another one. For this I will attempt to try using a class and hopefully I do good