So I’m trying to make an interaction system, where you talk to an npc accept the quest and it displays it on your screen while running the quest awaiting you to complete it. How would I go about doing this in an organized fashion?
I have to fire the client to display the quest, and I also have to make the quest run through the server with a value or something kind of like this;
if questProgress > 5 then
print("Killed 5 thieves")
end
Idk how to do this, or explain it very well. Does anyone know how they would go about doing this?
Roughly what you want to do for something like quests is to create a system where the actual content is separated from the code, so it would be a good idea to make your actual system quite generalized. For example, the system itself might just look through a folder of quests in ServerStorage and then based on some configuration values will handle the quest from there. The quests themselves will be easy to make and modify, although this comes at the cost of your system probably being a bit more difficult to build in the beginning.
I would suggest that if you haven’t done this before, make a plan of exactly what you want to happen in the quest system (for example, a flow chart) and then once that is laid out start grouping specific components of this flow chart into groups of scripts, modules, etc. This will just help you get an idea of what to actually make. Don’t worry too much about making it fit with the idea of a ‘generalized system’ like I talked about in the previous paragraph (you want to just get what you want to happen for clearly set down), but if you can put things related to that into your flowchart then that might be helpful.
Okay, so now to actual coding. There are heaps of different styles and such to try, but ultimately it’s up to you. Just do what you think would work. Remember that you should make sure everything important to quests is handled on the server, as for a quest system the main job the client will have is displaying the information. The main quest system should respond to things that happen on the server, not on the client. RemoteEvents, RemoteFunctions, BindableEvents, and BindableFunctions are your friends. You might consider using ModuleScripts, perhaps you could use them to store the quest configurations?
An example structure might look like this:
ServerScriptService
Quests (Script) → the main code, responds to stuff that happens in other systems (e.g. combat system enemy killed)
ReplicatedStorage
QuestUpdated (RemoteEvent) → communicate quest information from server to client
Quests (Folder) → contains quest data (in ReplicatedStorage to allow clients to use it to display information)
KillThieves (ModuleScript) → contains quest data (e.g. num enemies to kill, quest name, quest rewards)
StarterGui
Quests (ScreenGui)
Quests (LocalScript) → responds to messages from the server to display information about quests to the user
The interaction part adds another layer where the client must give the server some input (e.g. talking to an NPC) before the actual quests will be run.
Anyway, the best way to learn to make things like these is to do them yourself. So go out there and don’t be worried about getting it ‘right’ (whatever that is). There are a lots of different ways to do things, and they all have their strengths and weaknesses.
If you’re familiar with datastore, as long you are able to save tables, you will have no issue in saving “in-progress” and “finished” quests
table.insert(source[plr.userId].Quest, {name = item, current = 0, goal = 10})
for my case, simpliest is : i create a table with infos inside Quest, which is also a table.
and you can update the table (current’s value, for example) directly without issue.
However, i am most likely outdated due to the release of new table methods
I don’t feel like you should worry if you store with minimal information, Bloxburg is able to save entire House composed of 3 floors, very specific roof structure, massive amount of furniture, placement, wall, painting & texture+scale settings.
if you’re that worried, just do n=item, a=0, b=10
you can eventually extend quest infos via a module,
for example, if you have quest name YA, then you can proceed in checking if player owns such title, if yes, load description & more via module
