I have this quest system for my game as can be seen here:
but it only works for one player because it is in a regular script. Could someone please help me make it so everyone had it once and not only one player could do it in one particular server?
3 Likes
why not store a folder inside each player and do the magic there? Also I wouldn’t loop check if the statement is true. Just check on item added or removed.
First of all, this system would require a redesign if you want to have it work for ALL players. Essentially, you are only storing a counter for whoever executes this script.
To make this work, you will probably want to begin with a module script. Also, you will need to have a method at storing the data of every player. Or, in this case, a counter of how many items they have collected.
The scale depends on how far you want to go with this quest system. Do you want multiple quests? Do you want it to save?
I will just outline a basic system (which I would do, not saying it would be the best) -
Have a global table
This table will store a list of players, that is updated as new ones leave and join. The ‘update’ depends on whether you want it to be saved or not. If you do please look at the methods underlying roblox’s datastores.
I ain’t a sadist, so here is an actual coded implemetation (vague because I am lazy) -
This will coincide with you giving a clicked event to each item, as that seems to be a game mechanic. When they click, the server script will send a request to increment the quest data. The module script then handles whether it is enough or not.
If you want to client to be able to see their progress, have this data passed down with json. You can do this in a number of ways. Such as having a remote function return the table data, or literally just having it encode the table and pastting it onto a string value. Depends on what ya wanna do.
Some tips, though -
Don’t have perpertual loops IN ANY SERVER CODE!
Treat the server like it is your damn child. Never give it more work than it needs to do. Design your systems in that fashion!
I hope I gave you some ideas on how to tackle this issue. What I am saying is that this isn’t the way perhaps, but it is what I would do (on a level, these systems can get darn annoying the more you want to do). Don’t do that if you think you can do better. By all means, it is your game.
For example, metatables exist. I don’t like using them, but they exist 
2 Likes
That code that you put would I implement it with the code I already have? If yes where?
Sorry, I was being a little vague with my implementation. I was just giving a general approach, so as for an actual practical application in your usecase…
I would say the easiest method would be to, inside the module I specified, have a function that creates the ‘items’ and gives them each a clickdetector with a mouseclick connection. Basically what you did there.
In that case, have the code, when clicked, call another function (the one called increment quest moreso) in the module that iterates the table data of the player. Of course this probably doesn’t have to be in a module, it is just that modules are great for future proofing systems.
On that note you should also change the player_join and leave to the actual events, otherwise they would do nothing 
.
Try that approach, if you are really stuck I can try to make an example for you.
1 Like
I’m sorry but I’m not very good at scripting, I’ve tried but have not been able to figure it out yet, could you help with it please?
Alrighty, no problem;
example.rbxl (20.8 KB) Awalla
I made this in a hurry but hopefully it is doing what you want. Of course its only an example, so it is basic in functionality.
If you have any questions on how it works please ask, but for a rundown -
There is a module called ‘Quests’ that is in ServerStorage. Ie, only serverscripts can access it!
This module can be used to allocate click detectors to a model of parts. I haven’t put any stringent checks so if there is anything other than parts you may need to code some checks.
I have commented each function so please see the documentation.
It works for 1 player but then it doesn’t work for any second player because once 1 player collects it the second player sees nothing on their screen.
Hm, I tested it with a two player server and both players can collect the parts.
By not working, are you saying that both players can’t do the quest?
Please note that I made it very bare bones; ie it only connects to a model you specify and gives them click detectors. Whoever clicks on them is not of precedent.
I tried to make the module easy to understand (No OOP stuff), so if you can get a general basis on what it is actually doing you should be able to -
- Add a function that creates (or clones from a repository) a model
- Maybe have a parameter that only allows a certain player to begin the quest…
Nonetheless I will make a better streamlined system, using OOP. You can make as many quests as you want now.
But this is now less friendly to people starting out 
example.rbxl (24.5 KB)
There is heavy documentation and a guide on how metatables work (the core of OOP)
Whenever you play the game it does work for 2 players but it for some reason stacks the 2 blocks (1 for each player) on top of each other.
Yeah, thats because you need to change the Position parameter. I just set it to some vector3, but if you want to you can make it random.
Or as it has been put into a player added, simply wait for the character and put it onto their position. Your choice basically. The module merely clones a model and places it somewhere, with the quest ability. You need to implement it as you see fit.
But is it possible so that one players quest pieces appear only for that player so for example if there are 2 players each player can only see their own set of quest pieces?
Oh, that my friend will require some work (or not now that I think about it)
Essentially what you would need to do is have the parts rendered for the player. These parts are then locally made to have a clickdetector. (What I mean is that the client will create the parts in a localscript)
However, this isn’t as simple as it may seem.
One, security.
When creating the local parts, each part will, when clicked, fire a remote event to the server.
The server must know whether these parts are in fact plausible. There are certain limitations to this, as the client has absolute control over the parts. For example they could just, if exploiting, fire the remote event anyway and even if the server knew it had quest items, it wouldn’t know that the user hasn’t actually clicked them.
This is quite the issue, eh?
No matter what you do the client will always have control on what they send to the server. Therefore, we will need to see whether it is possible from them to click the part!
Now, there can be many ways to do this, and one that popped into my head was:
- See whether the player is within the a set range of where the part was supposed to be placed.
- This will work because no matter what the player does, if they are not in that position the server wanted the part, they will not be able to increment their quest value.
- Therefore whatever they do locally, they must replicate server side to a range within the parts position.
- The range will be the click detectors range.
There is a downside, of course. That is that if they really want to, they can just constantly fire the server, and when they get within range they will automatically increment. However, this would be harder when the client has to specify what part they are trying to destroy. So it wouldn’t be indiscriminate.
This system will probably do well enough. Of course you can try to get more fancy, but I haven’t put enough thought to procure a totally no compromises method.
Now, as for actual implementation, I will have to redesign the system a bit and add remote events for server client communication.
I don’t really want to do everything for you, so do you have any previous experience with server-client communication?
If not you should learn it well; it is a prerequisite for being able to develop safe, efficient, and robust games. Once you know it well you will just know how to properly implement client-server communication.
But just for a note, you should never trust to client. No matter what, have ALL important checks done by the server. Nothing, and I mean nothing, should be put onto the client when it has gameplay affects. Like buying things, using a move.
All the client should do is do things only the client can see. This can be rendering moves, GUIS, chatting with npcs. Whatever only effects the client can be done client side. For example I make sure to render all my magic from the client side, otherwise the server would die on me. I do not let the client handle checks if it can buy certain skills, can level up. etc etc.
1 Like
I’m really horrible at scripting, I’m more of a builder so I have no idea what to do about it.
Alright,
I will implement the thing I said above. I won’t say this is the most efficient thing possible, and I will say that this has become rather complicated. I do not really expect you to understand it.
Nonetheless it is now local.
Essentially, the server tells the client to create the parts and add clickdetectors to them. Then when clicked the client sends a request to the server with the part name. The server now checks whether the client is within a 32 stud range of where the parts should be. The client can do whatever they want, because the server stores a collection of positions of the parts.
This makes it quite hard to exploit. But it’s possible, probably.
Here is the file. You should try to understand these concepts if you want to create an actual game. After all this is only a basic system. I say basic but lol.
example.rbxl (26.7 KB)
2 Likes
Thank you so much, I really appreaciate your help.
1 Like
I tried to insert it into my game but it doesn’t seem to let me click it anymore.
Oh damn.
Please make sure you copy it exactly. All should be in the same place as it was before, don’t rename anything. If there is an error please send it.
I checked it to make sure and nothing was renamed but it still shows up that you can click it but when you click it it does nothing.
I checked it and realised a quite serious derp - the remote function handling. I did a dumb system where it just found the remote (one that is sent to the server on click) by indexing its plr name. This wouldn’t work if you made more than one quest for the plr, as it would only invoke one of the two remotes created.
It now creates a remote and parses its index to the client so that it invokes the correct one.
Hopefully it will now work as intened ;-;
example.rbxl (27.0 KB)