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:
- Quests (Script) -> the main code, responds to stuff that happens in other systems (e.g. combat system enemy killed)
- 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)
- 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.