Author Topic: Exploring areas  (Read 470 times)

Legacy_meaglyn

  • Hero Member
  • *****
  • Posts: 1451
  • Karma: +0/-0
Exploring areas
« on: March 11, 2014, 01:24:30 pm »


               

HI all,


 


I'm looking at PW support for exploring areas. The basics are pretty straightforward. On enter check if the PC has explored the area (or has the map or whatever) and if so ExploreAreaForPlayer etc.   I'm curious if anyone has made a system to tell when a player has explored enough of an area to justify giving her the map or otherwise marking the area as explored.      e.g.   at 80% uncovered "you've added a map to your map book" or something like that. It's that part about telling when that I'm not sure about.  


 


I'm toying with the idea of putting an area specified number of waypoints in the area and marking a bit  whenever the PC gets close enough to one. Then checking for a certain number of different ones to have been marked to declare the area explored.


 


I figure I'm far from the first person to hit the problem of deciding when to declare and area explored. So I'm curious what other people have done about that.


 


 


Thoughts?


 


 


Thanks,


 


meaglyn



               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Exploring areas
« Reply #1 on: March 11, 2014, 01:51:28 pm »


               

I never found a manageable solution to determining how much of an area a PC had discovered.


 


A couple of things that were done in Vives 1:


  • Count the number of times a PC has entered an area. And once a threshold is met, reveal the map for them.

  • Provide challenge ratings for areas, and once a PC exceeded the challenge rating by more than 5, reveal the area for them.

  • Always allow a flag on the area which disallows an automatic reveal, and always require 3 visits minimum to an area.

This more or less works on a PW, because once a PC has been through an area a number of times, the PC feels like they should know the map anyway.


It is however not what you are looking for.


 


Your suggested method of placing invisible objects throughout the area is a possibility. You could generate an invisible object in the center of a each tile, on the first area enter, and place an AOE on each of the objects. Sometimes things land on tree foliage when this happens, but it would more or less work and not require a ton of data entry.


 


Alternatively you could place map nodes throughout the area identifying all of the important things. On first area enter you sweep through and apply AOEs to each so that you can track when each is discovered for the player, and when all are discovered you flag the area as forever after revealed for that PC.


 


Anyway, those are a couple ideas.



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Exploring areas
« Reply #2 on: March 11, 2014, 01:53:21 pm »


               

Good idea how to do that, but probably not need a waypoint at all as you need trigger around it, so you can stick just with trigger.


 


Imo, best would be to number those triggers, to allow store persistently not only that the area was full explored, but also how many of it was explored.


 


To storing this, since its player-dependant you can use a item in inventory to avoid database.



               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Exploring areas
« Reply #3 on: March 11, 2014, 02:04:31 pm »


               


Good idea how to do that, but probably not need a waypoint at all as you need trigger around it, so you can stick just with trigger.


 


Imo, best would be to number those triggers, to allow store persistently not only that the area was full explored, but also how many of it was explored.


 


To storing this, since its player-dependant you can use a item in inventory to avoid database.




You don't need triggers. Just use an Area Of Effect on each object although I do not know if a waypoint can receive an AOE as I never tried that, but you could just apply it to the location so either way it should work.


               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Exploring areas
« Reply #4 on: March 11, 2014, 02:16:46 pm »


               


You don't need triggers. Just use an Area Of Effect on each object although I do not know if a waypoint can receive an AOE as I never tried that, but you could just apply it to the location so either way it should work.




Well not sure either now, but you can apply AOE on location.


 


Problem is that spawning AOEs must be done dynamically so you must do it in OnModuleLoad event or somewhere else and the AOEs are really very problematic objects and if trigger is a possibility its definitely preffered. That way or another, what you have to do is to get something from palette (waypoint/trigger) and place it into area, in case of the trigger it costs a 3 mouse clicks more than waypoint which is not a problem imo.


               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Exploring areas
« Reply #5 on: March 11, 2014, 02:27:46 pm »


               

How is an AOE problematic? I like them because it means you don't have to painstakingly draw every trigger. You just generate them on area enter.



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Exploring areas
« Reply #6 on: March 11, 2014, 02:52:34 pm »


               


How is an AOE problematic? I like them because it means you don't have to painstakingly draw every trigger. You just generate them on area enter.




Ok problematic is bad word. They work. But they are very inefficient and uses lots of resources from the module. Trigger is always better idea when its not moving. Plus as I said already, you have to paint something anyway so why not trigger already instead of waypoint. 1 object instead of two, advantage itself.


               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Exploring areas
« Reply #7 on: March 11, 2014, 03:08:26 pm »


               Are AOEs inherently inefficient? Even when just using enter and exit scripts?


The advantage is that you do not have to paint anything. Instead you spawn it all. The advantageousness of this depends on number of builders.
               
               

               
            

Legacy_meaglyn

  • Hero Member
  • *****
  • Posts: 1451
  • Karma: +0/-0
Exploring areas
« Reply #8 on: March 11, 2014, 05:45:54 pm »


               

Thanks guys. Some nice food for thought. I may combine things. I want to paint things because the builder (being me at thins point) knows the right number and location to paint, But I don't really want to bother drawing actual triggers. Waypoints with the area init generating the AOEs may do nicely. Although I may prototype it with triggers.


 


I thought about the entry count approach. But that seems ripe for abuse. Come to a new area and dance back and forth across the transition a few times to see if the area clears up ...


 


This would only be for the subset of areas that are either not always revealed (main towns etc)  or not ever persistently revealed (like dungeons).



               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Exploring areas
« Reply #9 on: March 11, 2014, 05:52:38 pm »


               


I thought about the entry count approach. But that seems ripe for abuse. Come to a new area and dance back and forth across the transition a few times to see if the area clears up ...




Was to solve that by only registering one entry per server reset, or time stamping the entry and only recording additional entries if x amount of time has passed.


 


Anyhow, goodluck.


               
               

               
            

Legacy_ffbj

  • Hero Member
  • *****
  • Posts: 1097
  • Karma: +0/-0
Exploring areas
« Reply #10 on: March 12, 2014, 02:36:28 am »


               

This is something I did based off of Carcerian's work:


http://nwvault.ign.c....Detail&id=3866


 


The original mapping solution was woefully inadequate.  With the map case idea I think I addressed one aspect of the problem.


Usually for the exploratory feel I will leave it to level for certain areas as mentioned earlier.  Then also maps can be given as treasure, gifts from npc's or found, in unique treasure chests.  These chests are part of my treasure map system.  Some areas have chests which can only be looted once for the whole game by one player. Another player could of course find the same chest, but again, only once.


I also have regional maps.  That is each area if  assigned a region local: region1, region2...etc.. will show up for the player if they have that region.  Usually associated with a town and nearby areas.


Then with the map case, say I have 25 areas where those maps take up just 4 squares in your inventory. So quite a space saver.  Additionally the maps can be retrieved.  I takes a bit of time to set up the map case but it's pretty simple.


Ii also have players pull out their maps and consult them when they enter a mapped area. Then the map show up on a delay-command.  I just think it's a nice tough. 



               
               

               
            

Legacy_ffbj

  • Hero Member
  • *****
  • Posts: 1097
  • Karma: +0/-0
Exploring areas
« Reply #11 on: March 12, 2014, 02:51:22 am »


               

You could set a persistent local on the PC for the area, and then when that local is incremented to the point you wish, which could vary by area, for instance mountains may take longer to map, then the entire area is revealed. You could also set the same local on the PC say newarea set to  1. So since locals on PC do not persist the PC can not increment the local set on the database object, if the local on him is in effect.


In other words only every server reset can the PC increment the local that will increment towards the stated goal, no matter how many times the player skips in and out of the area. Or how much time they spend there.  You can always say  it takes days to completely map out an area. Which it does.



               
               

               
            

Legacy_ShadowM

  • Hero Member
  • *****
  • Posts: 1373
  • Karma: +0/-0
Exploring areas
« Reply #12 on: March 12, 2014, 03:08:11 am »


               

I would divide the area into 1-4 triggers / key areas in each area representing important sites of the area, that reward the player(xp, other stuff) for finding them and let the players know that they have to find the set number to unlock the area. The triggers will set variable on the pc or into a database and let them know how many of the total they have found in that area.



               
               

               
            

Legacy_meaglyn

  • Hero Member
  • *****
  • Posts: 1451
  • Karma: +0/-0
Exploring areas
« Reply #13 on: March 12, 2014, 01:40:23 pm »


               


This is something I did based off of Carcerian's work:


http://nwvault.ign.c....Detail&id=3866


 




 


Thanks, that looks interesting. I had not seen that one. The actual use of maps and map books etc is not really the problem I'm trying to solve, though.  


               
               

               
            

Legacy_meaglyn

  • Hero Member
  • *****
  • Posts: 1451
  • Karma: +0/-0
Exploring areas
« Reply #14 on: March 12, 2014, 02:05:14 pm »


               


You could set a persistent local on the PC for the area, and then when that local is incremented to the point you wish, which could vary by area, for instance mountains may take longer to map, then the entire area is revealed. You could also set the same local on the PC say newarea set to  1. So since locals on PC do not persist the PC can not increment the local set on the database object, if the local on him is in effect.




 


I was planning to make it more specific than just a counter. I was going to set a different bit for each piece of the map explored, and require say 8 out of 10 or whatever (depending on area as you suggest). This means they really have to walk to a good percentage of the accessible parts of the area to map it.    For simple areas the PC just needs to traverse you could have one near one entrance and another near the exit. For a more interesting wilderness area, or mountains as you say, there may be a bunch scattered around.


 


The bit map would be persisted so PCs would not lose partial work.


 


 




I would divide the area into 1-4 triggers / key areas in each area representing important sites of the area, that reward the player(xp, other stuff) for finding them and let the players know that they have to find the set number to unlock the area. The triggers will set variable on the pc or into a database and let them know how many of the total they have found in that area.




 


That's sort of the basic idea, but without the feedback (except at the end when It say "You've mapped this area" or whatever). This is more for general wilderness and such not so much for a real adventure area like a dungeon. For that I may just have a map in the boss loot to make it easy. But I could use the same approach there. If it is a specific task to map the area then reporting the number required and current status makes a lot of sense. This is not really that case though.     In general these markers would be fairly evenly spread around the area so that looking at the current minimap gives an indication of how much you've done.  Not quite as tight as Henesua's suggestion of every tile


but maybe around the middle of each 4 tiles.


 


Anyway, I appreciate the suggestions and will see what happens.


 


Anyone have a short example of scripting AOEs?  I don't want any visual effect of course. Is it just a matter of creating it using AOE_PER_CUSTOM_AOE?   How/where is the size controlled or specified?