Droid Engineer Archive
Thread: Concept Series: Survey Droid
I thought of that too, and in retrospect I'm not sure why I changed my mind. I think I was just trying to come up with extra ways that experimentation could have an effect on the performance of the Droid. This would be much more useful.
Sirgleno wrote:
I was also thinking on doing some fleshing out of the survey droid concept, I especially like the part about having the range be very large, truely less than a 1km radius would not be worth using. I also fully agree that the better droids (ones with greater radai of surveying) would work faster than the normal ones. However I think that the droid, to be very effective (and this is also quite plausable with a droid that actually covers the area), should return the waypoint of the highest concentration of the specific resource within the survey area.
Message Edited by Sirgleno on 02-18-2004 03:05 PM
Message Edited by Sirgleno on 02-18-2004 03:05 PM
Lonkley wrote:
Personally I would be happy if they just replaced the need for swgcraft.
Combat tanks, especially for people who consider combat simply onerous, tend to get nerfed. A tank for any subsystem will get similar treatment.
Surveying's onerous for everyone, and I've heard many a person say "a survey droid should return a waypoint to the highest concentration on the planet" or even better, the galaxy. I don't think it should. That's just too easy and too powerful. Resources shift so as (a) provide a random draw element, and (b) to allow all kinds of people, powergamers and dabblers alike, the chance to lay down on a primo spot, if they work at it. Onerous task, rich reward.
I'm gettin all nostalgic now, thinking about shuttling to a new town, getting there, discovering a vein, and discovering that the vein maxes out at 26%, having your vehicle autostore 2 klicks out of town, running back in, shuttling to a new town, following a vein to the edge of the map, then there's the crying and the anger. Then there's the finally finding a 40% concentration only to find that it is in the middle of a lake and there are only two buildable spots but TFG one is still open. I mean, you want to give that up?
Anyway, I don't disagree with the proposal, but I caution against designing anything too powerful. I have a particular preference for a survey droid -- it would be a droid that you drop a single waypoint onto. After "traveling" there, it emails you the concentration. This design doesn't do all the work for you, b/c you still have to know where the promising veins are and where they are likely to max out. A tool that helps would be more likely to be approved than a droid that tanks.
I would be happy with just the Planetary resource survey droid. LIke the BH droids it should be charged. You call up a droid, select a resource type, select a planet and send it off. After a given amount of time the droid would report back the type of resource and its stats that it located via email.
Now the droid to survey for resource concentrations would be a dream come true but I agree it is probably too much to ask for. Would the droid map out the whole planet or would you just set the desired concentration percentage to look forand it would stop when it found one?
I know this the wrong place for this but,
When are they going to fix the harvester notification that they said they implemented a while back. We get an email when factories stop working/finish. What happened to the harvester email? I know i read it somewhere about it being a feature.
I disagree with the concept that if the droid is too powerful, it should not be implemented.
The way to deal with that is to make the modules required very expensive to build. IF the droid can be realeased and find the highest concentration of a resource on the planet it should burn out the module, and the module should require some inconvenient resource or quantity of resources to build so we DEs have to sell them for big bucks.
If, on the other hand, the droid goes to a waypoint and returns multiple surveys for whatever resource type it is set for, the modules should be more readily build and not burn out.
My two cents.
O-Jen