quest enemy at random location
| Submitted by foerstj on Sat, 2020-10-17 15:14 | ||
I want to make a quest in a DS1 map where the player has to kill a boss enemy. However, the boss can be in three different places, which are in three different regions A, B and C, and more than frustum size apart. And I don't want a situation where the player walks through place A two times, first time there is no boss and the second time it's there; it should be consistent. What would be the best way to implement something like this? Once the decision is made, I can use check_bool or check_quest_bits (what's the difference anyway?) on entry to the places to make the boss object appear/disappear, I guess. But how do make the first random decision? forums: |
||
|
» |
||
I haven't made maps in a long time, but this may be possible with triggers. I would try an initial trigger that selects one of the 3 triggers placed in the different regions that spawn each boss. There may be a better approach and I haven't mapped in years, so I may be wrong.
Thanks, Dulac. Unfortunately there is no "random" condition or action available for the triggers (or am I just not seeing it?).
Since I want to release a new milestone of my map soon and want to include this quest, I decided to settle for *very pseudo* randomness. Which works like this - when you enter one of the regions A/B/C (each region can be entered from two opposite directions) it assigns the boss to one of them. For example, entering region A from the front, it checks a boss_assigned quest bit. If it is not set, it sets the boss_assigned quest bit, and also sets e.g. the boss_in_B quest bit. Needless to say the choices at the six entry points should be mixed up to appear random; however if the player walks the same path every playthrough the boss will appear at the same spot every time of course. From now on the triggers don't do anything more, since boss_assigned is already set. Then when the player comes "close enough" to the boss position in region B, there is a trigger that checks boss_in_B and if so enables the boss object.
Coming "close enough" means a sphere of about 50, which is hopefully far enough so the player doesn't see the spawn, but close enough to ensure the boss object is also in the frustum.
A second question concerns the boss - how to enable / disable it. There are basically two ways to do this: either have a boss object standing there and delete it to disable it, or have a generator standing there and activate it to enable the boss. Deleting an object can be done with we_req_delete - we_req_die is not enough because I had a weird effect where the boss would still appear standing there and moving his arms, just on mouse-hover it read "dead" and it didn't interact with the player character, kind of like a Schrödinger's boss lol.
In my case we_req_delete also didn't do the job perfectly, and that is because I have chosen that boss to be Lord Hovart, and him being a skeleton he wears random gear and when he dies he drops it. So the player would walk there and find a Hovart's blood armor lying in the grass.
So the best option seems to be a generator that spawns a Hovart. The downside with that is that a generator only spawns an object of the given template, however I want that a quest is fulfilled when the player finally finds & kills Hovart, so I need to add a we_killed trigger to the Hovart. Solution: Write my own template for Hovart that includes the trigger.
Phew. Not implemented yet but this is how it should work.
Don't praise the concept before the test
A minor issue I found was check/set_quest_bits wasn't working - even tho I had working setups on the same map, weird. check/set_bool was working just fine tho.
So I implemented the whole scheme with that and found a bug during playtest: the spawned object is not kept in memory! Gaah.
Walked into region A to trigger assigning Hovart to C. Walked into C quickly to check he's there, and he was there all right - the bool was checked, the generator was activated.
Then I went the long route back through A, through B and then C (from the other side), and when I finally came back to where Hovart was supposed to be standing - he wasn't standing there anymore. So the object was not kept in memory, and once it left the frustum it left the world for good. (Unless he'd been eaten by the snappers in the meantime, lol.) And a generator only fires once - seems the game engine had remembered that at least...
SO I gave up on the whole thing for now. But thanks anyways Dulac.
Maybe we could get rid of the initial trigger and rely on an external variable. The external variable could store a random number between 1-3, then the condition to generate one of the three bosses could be based on if the variable is meet (if (externalVariable == 1, etc.). Sorry it's been very long since I've used triggers. This is more so a generic solution. I don't recall the limitations of triggers. I would be very interested to see a solution implemented. Let me know if something works.
Edit: Yeah, I was a bit worried about the frustum radius. However, it sounds like a good test of concept though.
Edit: Maybe triggering it to delete the other manually placed monsters is a better solution than generating it in the world to avoid the object being cleared from memory. I wonder if the delete is also cleared from memory though when leaving the frustum.
Edit: I think you can also delete his armor.
I'm going to have to re-read on triggers since it's been over a decade. Is the SU sufficient enough?