|
|
Post by tharindu on Apr 28, 2017 6:21:37 GMT
I'm going to have to divorce my wife to marry you tharindu! But I might wait until you release the add on...  LMAO. The addon is definitely coming once I remove the dependencies between this and Invector's item manager to the possible extent. I am not sure if this code is really optimized and all that's my only concern. I am new to Unity and I haven't had much touch with .net for the past couple of years. But I am fairly certain it's not going to be very resource intensive so fingers crossed on that. Apart from implementing quest types I am yet to introduce the actual rewards system. But it won't take long I am sure. |
|
|
|
Post by shadex on Apr 28, 2017 16:48:54 GMT
shadex To top things off, you don't have to necessarily begin a quest to have finished an objective. This I noticed so much particularly in Witcher 3 The Wild Hunt. You can go kill that old hag living in the swamp to discover the npc in the next town actually has a quest to kill the hag and bring them its head. So if you still have the head in your inventory, boom! your quest will be instantly completed  Similarly if you already killed that bandit leader you accidentally came across and find someone has a quest for that, the moment you accept it, it'll be completed and you'll receive the reward. Witcher 3 was my inspiration for trying to create a very immersive experience and in its heart lies a great quest system, vendor system and level up mechanics. I will try my best to deliver something close, being the newbie I am to unity I loved the quest system of witcher 3. It's no doubt one of the great RPG's ever made. Do you remember the werewolf side story in Witcher 3? Where you have to choose to kill the sister or the werewolf? To me that was the single most gut wrenching thought provoking quest in any RPG. The system itself was a branching quest system, where each step of the quest gives you a chance to provide multiple subtle choices. So when you start, you can ask around for more clues or go right into the woods to find the wolfs. If you ask around, you get rewarded with some backstory to the quest, and a better picture of what your going up against. This is done through the quest system interacting with the dialog system, as it changes what the characters say vs when you haven't started the quest. Again right after you find the wolfs you can choose to find more information, or continue on with the quest. If you gather more information, it again changes dialog for specific characters (margret). This pattern continues of allowing you choice in each part of the quest. It also had a built in quest helper (witcher sense) which was brilliant, and still immersive. All the way to the very end of the quest where you now have to decide if your killing the werewolf or letting the werewolf kill the chick first then killing him. Each choice at the end give differn't rewards. The brilliance of that system to me, was that if you where rushing through the quest, it was a "kill the werewolf". You could actually finish the quest in 10 minutes. If you followed the investigation route, it was a 2 hour story with character devolpement, plot twists, which ultimately framed your decision. I always wondered how many people just killed the werewolf that ran through quest that if they took the investigation route, would of felt strongly about letting the werewolf kill the sister after learning the story. Thing is the quest system flips a few extra booleons to switch the characters dialog, and combines multple kill quests, fetch quests, and discover quests under the guise as one quest. That is what made it so great IMHO. You can get a ton of millage out of flipping a animator bool, enabling/disabling game objects, flipping a dialog bool and and multiple win/lose conditions. I still think the best thing about the Witcher 3 was how it allowed the "fast running skipping text" diablo style of RPGing, and also the slow, at your pace, highly detailed questing. Everyone i know who played the game fast ran the quests they didn't think they would like, and spent hours on the ones that caught their intrest, which is the best use of a game medium i can think of. You end up only remembering the amazing quests, cause you fast ran through the boring ones. |
|
|
|
Post by tharindu on May 1, 2017 15:27:03 GMT
New feature added : Quest Completion Target feature - If a quest is not autocomplete and a quest completion target is set, you will finish your quest at this entity. So, I got this idea while implementing the fetch quests. I have a delivery target right ? What if I took this delivery thing out of the fetch quests and instead make it a target for any quest. For a gather quest I'll obviously have to deliver to the quest giver or a specific person, such as a vendor or even something like a shrine. What if I enable this on all quest types ? This kinda allows you to begin a quest with a quest provider, but end the quest by may be visiting another person or a location or activating an item or something of that sort. Possibilities are endless |
|
|
|
Post by tharindu on May 19, 2017 9:54:29 GMT
Hey guys, Sorry for not having given an update in quite a long time. The reason is I have been caught up doing a few things on my own game and also been quite busy doing things with my real job, consulting for an SAP company. It has been a tough set of weeks with deadlines and cutovers looming and weekend work too. As for a general update on things, I have been dabbing at creating a different kind of system with shadex here and there. A couple of days back I heard that the VIDE dialog system I was going to integrate into the Quest System has gone from been free to 15$ which is quite unfortunate. Since I heard the news and the quest system has come to a certain level of quality where you can actually add a few quests and play, I am going to take it upon myself to create my own node-based dialog system. If my learning serves me well, it's going to be one heck of a ride. Let's see how it goes. |
|
|
|
Post by tharindu on May 21, 2017 14:42:04 GMT
A question in general uberwiggett jrackley shadex @invector . For discovery quests, I thought a bit long and hard and I am thinking of going with large static trigger colliders in its own layer, and in the collision matrix I set the player layer to only work with this collider's layer. after the discovery quest is complete. This collider will be deleted. Is this acceptable ? I am particularly touchy about having a lot of colliders and not controlling the collision matrix properly because of performance. |
|
|
|
Post by jrackley on May 21, 2017 17:52:44 GMT
A question in general uberwiggett jrackley shadex @invector . For discovery quests, I thought a bit long and hard and I am thinking of going with large static trigger colliders in its own layer, and in the collision matrix I set the player layer to only work with this collider's layer. after the discovery quest is complete. This collider will be deleted. Is this acceptable ? I am particularly touchy about having a lot of colliders and not controlling the collision matrix properly because of performance. I may not be the best person to answer this however it sounds like what I would do in that situation, I really do not think it would impact performance too much(could be wrong?), I guess to help some you could have them all disabled until the quest is chosen and then let the quest activate the colliders as well, that way they are not there if no one ever tries the quest? Maybe the others can give some better advice as we are learning a lot still when it comes to performance and optimizing. Oh yeah and I highly recommend this free asset www.assetstore.unity3d.com/en/content/35100you can cull objects by layer and it works GREAT! |
|
|
|
Post by tharindu on May 21, 2017 19:17:19 GMT
Hey man thanks, I went with box colliders purely because of the visual ease with which I could cover an object as large as a city. But to be truthful sphere colliders are much faster in terms of performance. I would decide between one of the two.
The collider being activated is a choice I want to leave up to the quest designer. Because there can be instances where I say discover this city as a major quest of some quest provider, but in an open world environment there's already the chance that you'll have this discovered, so as soon I accept the discover quest, I can finish it.
As for the free asset, it's bloody awesome. Thanks for that! :D
|
|
|
|
Post by uberwiggett on May 21, 2017 23:02:03 GMT
Hmm interesting. A collider would be simple enough and not overly taxing unless you have a bucket load of them (like, thousands). But what you mention about deleting etc, will make it hard if you get the quest after visiting.
Two approaches, the location conpletion collider of quests are spawned when quest is given, and just having your story match so even if you've already been there you have a reason to go back.
Or, prepare a list of locations discoverable, and either have unseen quests that auto complete when you enter the area, or at least trigger a bool for each locale so when you get the quest it looks to see if true/false and autocompletes if you already triggered it.
I like the second approach better as it allows you to have both the option to give xp as you discover or direct player to a location for a quest. Should be able to just have an object list in the inspector with drag and drop transforms for the locations and name them.
|
|
|
|
Post by tharindu on May 22, 2017 1:45:59 GMT
Hmm interesting. A collider would be simple enough and not overly taxing unless you have a bucket load of them (like, thousands). But what you mention about deleting etc, will make it hard if you get the quest after visiting. Two approaches, the location conpletion collider of quests are spawned when quest is given, and just having your story match so even if you've already been there you have a reason to go back. Or, prepare a list of locations discoverable, and either have unseen quests that auto complete when you enter the area, or at least trigger a bool for each locale so when you get the quest it looks to see if true/false and autocompletes if you already triggered it. I like the second approach better as it allows you to have both the option to give xp as you discover or direct player to a location for a quest. Should be able to just have an object list in the inspector with drag and drop transforms for the locations and name them. The thing is it wouldn't be possible to not have thousands of collider in a scene with a huge environment. At least from what I've gathered in unity this is the order of performance impact from colliders from lowest to highest 1. Sphere 2. Box 3. Mesh Mesh colliders being the most taxing. It's always good to go with convex if you have a crap ton of mesh colliders in your scene. Either that or if at all possible, replace the mesh collider with one of the other two primitive colliders if assuming the shape makes sense. For instance a barrel can be covered by s box collider and not a convex mesh collider. Another good practice is to maintain a steady collision matrix. My idea is to create box or sphere colliders for any discoverable location or item of any size, but make them static colliders. I am not going to be supporting the discovery of dynamically moving targets like trains etc for obvious performance reasons. I always have the player on his own layer. I will leave the static trigger colliders in its own "discovery layer". The collision matrix for the discover layer happens only with the player layer. Therefore a huge saving on physics already. Regarding the part about deleting the quest collider after the quest location is discovered. It won't be a problem. Because all of my quests are geared towards being completed whether the quest has been given to the player or not. On discovery I will update the quest via quest system scripts and events attached to the collider. It's pretty much what you said here "have unseen quests that auto complete when you enter the area, or at least trigger a bool for each locale so when you get the quest it looks to see if true/false and autocompletes if you already triggered it." Instead of a bool I have a state enum "QuestState.NotAcceptedButComplete". I don't intend to cover maintaining a list of the quest locations and all because I feel that responsibility should fall under a map addon where icons with legends can be maintained on a map. What I can do is simply expose an event where the update can happen What do you think? |
|
|
|
Post by uberwiggett on May 22, 2017 2:04:13 GMT
Sounds reasonable, some people may want it to tie into their map system so being able to just reference it might be better for them. I was just thinking on what ever quest database object you have you can link the collider objects into an array so it's as simple as drag and drop the collider object into the list on the quest database and have it automatically assign the discover quest details. Which doesn't work too well if you want some specific story to finding a location, but is fine for the old wander into a newly discovered location get 50exp I'm still using cmans quest addon and it's working fairly well, but your expansion on the quest options and lines has me drooling! Looking forward to getting a hold of this. |
|
|
|
Post by uberwiggett on May 22, 2017 2:10:58 GMT
Oops forgot to address the first part about colliders So super huge scenes are fine, even if you have a hundred places to explore over vast terrain, you don't need to run colliders that are beyond the bounds of the players immediate interaction zone. Especially static ones that are only going to be activated by the player themselves. You could come up with a way to only activate the colliders within a specific zone, either by chunking sections of your map using one big collider and having all the little ones become active when the player is within the zone, or figuring out a proximity activation. There is also multithreading and batching. I don't have my head around those two yet but using the uBuilder system that does batch mode for its buildings it is insane how much I can throw together (walls doors pillar floors etc) and not suffer more than 3fps. That uses the proximity to player system, where it basically turns off the required physics components for the building when it's outside of the players radius. |
|
|
|
Post by tharindu on May 22, 2017 2:33:27 GMT
Sounds reasonable, some people may want it to tie into their map system so being able to just reference it might be better for them. I was just thinking on what ever quest database object you have you can link the collider objects into an array so it's as simple as drag and drop the collider object into the list on the quest database and have it automatically assign the discover quest details. Which doesn't work too well if you want some specific story to finding a location, but is fine for the old wander into a newly discovered location get 50exp I'm still using cmans quest addon and it's working fairly well, but your expansion on the quest options and lines has me drooling! Looking forward to getting a hold of this. Actually the idea I had was to not let you guys reference the collider from the quest at all :D but do it the other way around. I would have a bool for the quest that lets you decide if you want the location to be discovered only when the quest is in progress or otherwise. You can set this when you open the quest on the quest database. I am assuming this helps you deal with a lot of options regarding discovery conditions. Second step is to add my vQuestTarget script to the collider and select the quest that needs to be updated,so the update will be handled automatically. This lets you deal with the collider whichever way you want and is very simple the idea is to support dynamic nature of discovery quests. This opens up escort quests too. When the target is present in the area and if the quest is active (in progress) we can let the vQuestTarget script do the rest for you. |
|
|
|
Post by tharindu on May 22, 2017 3:03:11 GMT
Oops forgot to address the first part about colliders So super huge scenes are fine, even if you have a hundred places to explore over vast terrain, you don't need to run colliders that are beyond the bounds of the players immediate interaction zone. Especially static ones that are only going to be activated by the player themselves. You could come up with a way to only activate the colliders within a specific zone, either by chunking sections of your map using one big collider and having all the little ones become active when the player is within the zone, or figuring out a proximity activation. There is also multithreading and batching. I don't have my head around those two yet but using the uBuilder system that does batch mode for its buildings it is insane how much I can throw together (walls doors pillar floors etc) and not suffer more than 3fps. That uses the proximity to player system, where it basically turns off the required physics components for the building when it's outside of the players radius. Oh yeah the proximity system is very effective. One other place I've seen this at use is a ghost of a tale, where the developer has made bushes interactable, almost like some sort of touch-bending, but uses dynamic bone to make the leaves ruffle and all. So he has placed trigger colliders (box) around the bushes. When the player is outside the zone, the bushes will be replaced by a different model that has no dynamic bones. When the player enters the zone, the models are replaced with a different model that contains the ones with dynamic bones. I am not an advanced Unity guy so not so great with multi-threading and batching to be honest. I should be learning these sooner or later I am waiting for Gaia 2.0 at the moment which is going to have stellar multithreading. So once I have the source code, I will go through and try to learn a few things from it. |
|
|
|
Post by shadex on May 22, 2017 3:33:32 GMT
A question in general uberwiggett jrackley shadex @invector . For discovery quests, I thought a bit long and hard and I am thinking of going with large static trigger colliders in its own layer, and in the collision matrix I set the player layer to only work with this collider's layer. after the discovery quest is complete. This collider will be deleted. Is this acceptable ? I am particularly touchy about having a lot of colliders and not controlling the collision matrix properly because of performance. Sorry, had a busy weekend, let me try to catch up to this thread, cause i think it is really interesting, so forgive me if i respond to individual posts instead of one big one. So I personally stay away from layers at all costs. So you know when you download an asset and it says something like "load the complete project", while most of the time it's importing layers. This means it's potential conflict with other assets, like having the same class. I'm not entirely sure how everything is written, but if it was me, i would have a script that would activate and spawn a collider whenever a quest was started. When you reached that collider and preformed the action (talk, kill, take, etc) it would trigger the quest as complete. This way it would be easy to dynamicly attach one of those scripts to an enemy (kill quests) or assign it to a specific person (Fred the townsfolk). Now as for the layer based collision... I know it saves on the coding, but isn't it rather limiting? First thing that comes into mind is that your going to want Enemies to interact with the collider's, just differntly from the player (escort quests). I would probly use tags, and allow the quest to accept tags, because there are more tags then layers lol. Also i wouldn't worry about colliders. You need what? 3 on average per quest? 1 to start the quest, 1 goal, and maybie 1 failure condition. If the quest has multiple steps, just activate the colliders as you go. How many quests do you plan on being active at one time? 10 or 20? that is 30-60 coliders on at worst, a single, non steaming map. But those are my just thoughts. i could be missing the point |
|
|
|
Post by shadex on May 22, 2017 3:47:32 GMT
Oops forgot to address the first part about colliders So super huge scenes are fine, even if you have a hundred places to explore over vast terrain, you don't need to run colliders that are beyond the bounds of the players immediate interaction zone. Especially static ones that are only going to be activated by the player themselves. You could come up with a way to only activate the colliders within a specific zone, either by chunking sections of your map using one big collider and having all the little ones become active when the player is within the zone, or figuring out a proximity activation. There is also multithreading and batching. I don't have my head around those two yet but using the uBuilder system that does batch mode for its buildings it is insane how much I can throw together (walls doors pillar floors etc) and not suffer more than 3fps. That uses the proximity to player system, where it basically turns off the required physics components for the building when it's outside of the players radius. Oh yeah the proximity system is very effective. One other place I've seen this at use is a ghost of a tale, where the developer has made bushes interactable, almost like some sort of touch-bending, but uses dynamic bone to make the leaves ruffle and all. So he has placed trigger colliders (box) around the bushes. When the player is outside the zone, the bushes will be replaced by a different model that has no dynamic bones. When the player enters the zone, the models are replaced with a different model that contains the ones with dynamic bones. I am not an advanced Unity guy so not so great with multi-threading and batching to be honest. I should be learning these sooner or later I am waiting for Gaia 2.0 at the moment which is going to have stellar multithreading. So once I have the source code, I will go through and try to learn a few things from it. There are 2 types of batching. Dynamic and Static Batching. Basicly if a group of objects share the same material, and a few other conditions (Static Batched objects can't move during run time), then they only have to call a single material. Static batching you simply hit a checkmark above "layer" in the game object called "static" and only call on objects you don't ever plan on moving during runtime (mountains, houses) vs dynamic which unity automaticly does. Those should be for things like treasure chests, anything with a rigidbody, houses that explode, etc. I don't know enough about multi-threading to be of any help. |
|
