I’m currently programming quests. I’ve set it up so that each quest holds the rewards + any information of requirements to finish the quest. The question is how to go about identifying when the quest is finished.
I currently am programming it as a separate set of code that I want to us to take in the information of the quest determine it’s state and then complete it as needed for each player separately (as there will be multiple players).
My question is should I keep heading in this direction and if so is there an easy way to pull requirement data from the quest without having to pull each variable through property’s to the player separately? If this is the only way that is fine it just seems like there would be an easier way.
any additional thoughts would be greatly appreciated if this is another general way to handle quests grammatically that I have not been able to find any information on.
As much as possible, make your quests data-driven. Don’t hard-code any references to specific player data in your quests. Instead, provide a general-purpose interface that your quest data can reference to check player data. This will make life much easier down the line.
The multiplayer angle is a more complicated subject. Is it local multiplayer on the same machine, or some kind of networked multiplayer? If it’s networked, do all players share the same quest (like a Gauntlet or L4D objective) or can they have their own individual quests (like WoW)? Is the quest maintained on the server or each client?
Ya if this is your first or maybe even second game, I would not do mulitplayer yet. Like for real.
As for your question, I agree with @TonyLi . I use XML for this stuff. It lets me easily edit my data in a human readable form and nothing is hardcoded. So your quest state checker is just going to read the file, grab the relevant quest (Unique IDs are great for this) and then read the state from the object generated from that deserialization. If you’re going to have loads of quests, try organizing the quest xml files in respective directories. Say you’re in Zone 1, you should have a zone1 directory that contains quests organized in a way that makes sense for you. Either by type, or more detailed location, or if this is an rpg maybe by NPC? Something that will allow you to go straight to the file from code in an anonymous fashion, and generate a quest state object with that info. Something like that. However it works for you – the point is to stay organized and keep things modular and small. You should be able to add and remove quests to the game without breaking anything.
I feel like I might have blabbed a little too much there so I hope that makes sense.
Thank you both for your reply’s. The multi-player side would end up being where there would be a certain number of each quest. The way I can explain best is imagine having cards that are quests. If there were 3 of some of some of them then there are 3 of that quest but others could have one. There will be identifiers to help with that though which will be no problem to keep track of.
Just to be sure I’m understanding though having all the data help in a text format or some none-hard coded format is basically what is being stated? Meaning I would have to reprogram this to create a text file of a sort instead of a script that holds the data.
Is there a particular reason that it is done this way? I’m finding making it a script does allow for me to make properties to easily grab the information needed from the quest whatever it may be without creating some sort of way to read the information from another type of file.
I’ll add in another plug for the data driven approach. Hard coded approaches get very messy. It’s easy to break things by adding or removing a quest. It’s more difficult to read what’s happening. It introduces some nasty dependency. And in a team it means your quest writers have to learn code.
My quest system uses a messaging system to get data. When an event happens, such as an object being destroyed, this is passed to the quest manager. The quest manager checks against all active quests to see if anyone is interested, and updates accordingly.
It’s not the most efficient system, but it works well enough for the moment. Also works for things like achievements and stats.
I think @Kiwasi got this fairly well covered but just to make sure it’s well pointed out – hardcoding data is both inefficient to create (because you have to watch out for proper syntax, makes things take longer to compile, etc), inefficient to edit (Dependencies will run rampant and something as simple as changing the name of a quest can lead to so much breakage you’ll want to rage quit and never look back) and is basically considered a lazy approach.
The actual code to read and write to files is just a couple lines. You can write entire lists (and I’ve been meaning to try serializing a dictionary but I haven’t got around to it yet with C#) of classes so managing your data once it’s loaded into code is really simple. Those properties you’re talking about can still exist. You’ll be deserializing your data into a class and it can contain methods and properties. If you access data via properties you can check that data was actually loaded, maybe have it try to reload the file if it’s missing something, and if it still fails generate default data in its place. You know whatever… Again, make it work for you. And then if you need to edit quests you just open the XML file and only have to worry about naming the block of text. It’s a lot cleaner, easier, imho. For super small stuff hardcoding is like… whatever. But anything beyond a weekend project needs proper data management.
