Droid Engineer Archive
Thread: OFFICIAL Droid Engineering Report August 4th, 2003 (Please read.)
Couple things from a non-DE here. It all sounds good except the general droid decay. I think a lot of people would not replace thier crumbling probot. 15-25k (on my server) is worth it for a one time thing. You will get some return buisness if the droid decays, but i don't think nearly as many people as you expect would come back for a new one. You'd get a lot of 'why? it wasn't the best combat thing ever and 20k every month is too much upkeep for a toy'.
DE should get unique droid thing, command, thier own bot, etc. That sound more than fair.
Creating a looping system for return buisness may backfire. I love droids, i buy new ones a lot. But when i have to stop doing other things to hunt down a repairman or allocate regular fund to droids... my droid fetish will end. The only way a decaying droid, or having DEs required for repairs would work is if droid were worth thier cost in the rest of the game again.
If they un-nerf probot, yeah, decay, i'd keep buying. As they are, no, i would no longer use my probot, or LE, or MSE, or R4. I would just take them out to look at, and when they went poof, that i wouldn't buy more.
As of right now, 99% of droid sales are based on 'thats neat'. I don't know many people who actualy NEED them or thier game play. I use my probot a ton, more then needed, just cause it is fun. I have an R4 repair just to six him up. Both well worth the money. If they are going to decay, thats fine, i can live with it. But it won't bring me back for more.
Anyways... If you want return buisness, I sugest that you make better power sources for droids. Batteries are cool, but i mean like big friggin nuclear power sources that last a good week or two and you can turn an nice profit on. I'd pay well to keep my bot running more then 60min without complaining about power (yeah, cheap batteries). Or bot upgrades... like attachable lasers, or add-on modules. or... like the weapons... DROID POWER UPS! They last a little, make the probot worth while, then wear off.
OMG, i'm brilliant (and modest). A power up for a droid that over charges it and suits it with temporary armor. Last about 15-60min. Makes the bot actualy combat worthy, then decays. There would be lines at ever DE doorstep. At some point the droid market will near saturation, but power ups would offer a good droid for a shot time while keeping the basic thing intact... something to feed.
There ya go, droid power ups.
Jellybean -- the CH who cares more about droids then creatures.
Sin -
First, great job you are doing.
I don't say that lightly. I still have reservations about the corrispondent systems that I had the day they were announced - and in other professions my fears weremore then duly confirmed.
It is nice, however, that it has worked out so well for you/us.
Just a note, though - if you wade through the patch notes for the "big one" I think your deed issue is being addressed. 
I saw it the other day - didn't know myself until then. There are several versions of it floating around, but according to one of them, it's gonna be fixed.
So you got your wish.
(And next week, if we don't get the very simple to fix bazaar issue addressed, I'm gonna eat my R2 droid for breakfast... )
Audio
I like the skill tree as it is, but fill in the other lines so people may learn different lines instead of all clumping into blueprints.. I know one DE who went into production line to start with only.
Another thing we need are more modules. Functional droids will serve as tools for the user. Droids should be able to take data or items from 1 point to another provided the waypoints. This kind of use would instantly give a micro use to the data module, as schematics could be traded with the droid doing the delivery and not the owner. I remember a great game on the apple2 computer where you would build a virtual robot and program it to do certain moves depending on circumstance.
The point I'm trying to make is the droids really have no purpse in game except to act as portable surgery and crafting stations, with the touch of a attack droid that basically is as strong as a player on their 3rd tier train of markmanship or brawling (if that). I'd love to be able to sit back and make droids while I have 1 or 2 out gathering resources from my harvester or delivering deeds to a droid sale. I know this requires elaborate programming but based on what I've seen so far it's not out of the question as to what's possible.
Also what is a droid repair tool for? LOL
Re: Point #3 - Decay and Detrioriation over time
Sentrosi wrote:
"Possible Solutions?:
We would like to see some type of system implimented that causes a droid to decay slowly overtime, or something similiar that only a Droid Engineer can fix. Other suggestions have been to have modules wear out over time instead of the droid so modules have to be remade and replaced. Perhaps make the Repiar module only funtion with a DE as master of the droid, or remove the repair module completely and give DEs the innate ability to repair and "heal" droids like a medic can a humanoid."
I have a solution for this - we need a MTBF (Mean Time Before Failure) system similar to computer hardware. A droid is only the sum of it's parts. Depending on Experimental Quality when crafted a droid's parts each have a built in MTBF stat - a critical number of "hit points" for each part - the better the part crafted the longer it should last - the higher the MTBF "hit point" for that part. Each droid action in it's program would (when an action is performed) have a percent chance to do damage to that MTBF ("hit point") number to all parts making up the droid.
e.g. you have a droid "follow me"
on "follow me" is attached a 10% (arbitrary coders will have to determine what is right) chance to cause MTBF damage, a random # is calculated and it fits in the 10% range, now we know the action the droid has taken has caused MTBF damage, we now roll a random number between 1 and whatever the max parts for that droid is (i.e. we assign part #1 - motivator the number 1, we assign the sensor package the number 2, we assign the manipulator arm package number 3, the chassis number 4 etc., in this example for simplicity let's just use these 4 parts all of which would have a different MTBF number of "hit points" based on their quality - so our random generator would need to choose a random # between 1 and 4). Lets say the random number for the part taking the MTBF point hit is 1. Now we need to assess a calculation to determine how many MTBF points are hit - I suggest a formula like this:
All droid activities need a MTBF base min and max potential damage range.
So for instance "follow me" can cause between 1-5 point potential base damagerange: we then do a calc like this:
(random(range min - range max base potenital damage)) * (length ofactivity in seconds*5%) = total damage caused to MTBF by this droids activity
The total damage in points is then deducted from the part number which recieved the damage, in our example this would be the motivator.
When any droidpart gets down to 0 (zero) the part has failed, and the droid is DISABLED (will not function).
TheONLY way to repair a failed droid part isfor a player to take the droid to a DE.
The DE must do an "examine" on the droid to be repaired. In the examine window add the list of parts making up the droid and their MTBF hit points, turn red anyparts whichhave failed (hit zero).
To repair thedroidthe DE must then craft a new part to replace the failed part (e.g. if the motivator failed the DE musthave crafted a new motivator - and havethat part available in their inventory) andof course a Droid RepairStation/Kit.
This is the only way a failed droid part can be replaced.
Thisis totally logical, of course with different activities there is higher risk of part damage - e.g.sending a droid into combat - attack should have the highest % chance to cause MTBF damage.
AND finally - if ALL the droids parts reach0 (zero) MTBF points the droid is destroyed (perma-death) - see your local droid engineer for a new one!
Anyways - my 2 cents on a system that would work if implemented.
--------------------------------------------------------------------------------------------------------
"Hey? what are you trying to push on us here? That droid has a bad motivator!" - Uncle Owen.
Linea said:
"...actually lose us money because of all the droid and travel costs. "
Actually I think Linea hit upon a possible solution should (that Sintrosi (sorry I keep spelling that wrong btw) hinted at) also help BHs coming to DEs instead of BH vendors (if we can't kill the BH vendors).
I love the idea of making DE crafted seekers last longer (100 missions from DE seekervs 1 from BH vendor), lets make it even more appetizing to buy seekers from DEs - let's have DE crafted seekers COST BHs less to use - the cost Linea is crying about IS NOT the cost of the actual droid (only 200 for a single use module) - it's the added fees when the droid performs it's duties - lets DECREASE the cost of those fees for DE crafted seekers (or better yet eliminate them altogether for DE crafted seekers).
My 2 cents.
MstrArtsn,
I think your "we need a MTBF (Mean Time Before Failure) system" idea is brilliant!
Remember when Luke and Uncle Owen went to the jawas and picked out that R5 unit? As soon as they started to leave the R5's head blew up! I'd love to see the MTBF system implemented with animations like that!
Failed motive system - smoke pours from the droid's wheels
Failed droid brain - droid head explodes and smokes
Failed droid (insert part here) - smoke animation
Brilliant!
Thanks Bantaar!
Love the idea of custom animations to visually represent those failures too! That would be very cool!
These are the best ideas, why are we voting on things that don't matter when these issues have not be resolved? Further more to add to the skill tree changes that would actually be a benefit would be to put droid customization on another XP curve and furthermore with the exception of Blueprints the XP need to obtain new skills should me much lower. If it were lower then people would spend some XP in these slots, as it stands now its a grind to lvl 4 blueprints first, nothing else matters. Oh and modules still do not work, ie compartments and medical modules. The Data moduule is usless if working.
Please fix whats wrong before starting new issues.
Hey Chubbs thanks for asking.
Please let me clarify - this MTBF system is anINTERNALdamage system only related to decay and deterioration (depretiation) as it relates to overall droid use. It's meant tomodel internaldamage over time incurred as it relates to how the droid is used, how long it's used and what actions it performs. This is meant as an addition to the currentEXTERNAL damage model of the droid where if blasted by 10 bad guys the entire droid suffers damage which could lead to it's destruction.
I was suggesting permadeath as a result of catastrophic failure where a series of actions the droid performed led to a zeroing of all MTBF points.
Remember that the MTBF model is an INTERNALLYgenerated damage model as opposed to an EXTERNALLY generated damage model where damage comes from someone blasting your droid to bits.
If I can use the analogy of a car, the MTBF system is mean to represent the damage your vehicle takes to its engine, suspension, brakes, transmission as it relates to how you use it, how long you use it, or how you abuse it while driving (operating it).
You could still crash your car into a tree or have someone sideswipe you - but that is a different type of damage- one that is generated externally.
So in terms of realistic damage modelling for droids I am proposingthe MTBFas a means of modelingINTERNAL damage due to use/deterioration/depreciation.
There is an existing external system right now that uses the HAM bars model. I don't like the external model (for droids) either since droids are not flesh and blood. I'd rather see a system that works with just three bars: S(heilds), S(tructure), P(ower) - the SSP system if you like.
For Droids with no Sheilds - this will bar will be zero, Sheilding is pretty self-explanatory
Structure represents the total "hit points", if you will, of the droid calculated using a base chassis/model hit point table, added to which is armor, added to that is the sum of all MTBF points and finally a quality bonus from the individual components and the final droid assembly is added - The structural bar represents both external and internal "hit points" - a droid can become incapacitated at any time if a very very rare coupleoflucky shot blows a component while the bar remains quite full, or if the MTBF damage system during an action by the droid calculates a component failure. if the bar hits zero, or the MTBF damage system asesses that all internal components have blown - the droid is permadead.
Power is also pretty self- explanatory. Power is power, if the droid runs out while attacking (again folks reason to have 2 droids out at once - have out an attack droid attacking and your power droid out powering your attack droid) it stops dead in it's tracks and the sheilds (if it has any) go to zero. The droid can still be damaged even if incapacitated.
External damage should go outward to inward and be subracted from it's total as it is applied inwardly against the droids components. IE if a shot hits a droid damage is applied in this order:
1) shields (if any)
2) structure (chassis component)
3) armor (if any)
4) components (all component parts - motivator, droid brain, personality chip, sensor package, manipulator arms etc.)
Thats the external damage system I would like to see.
Thanks for everyone's feedback and support! This is great!
Gorantoth wrote:
Much better than the first post. No problems with the content of this one. I'm a little disapointed that the community voted for wishlist items rather than fixing bugs, but that's how it goes sometimes. Thanks for choosing an important issue as your personal choice.
Yes, that's been my point since this started.
I would really like Sin to only do /bugs one week, or wishlist items another.
Mixing them up is only confusing people, I think.
Like I said in another thread today, they have more things in development from rough concepts on up that ideas for new features are NOT their problem - it's getting the ones we have to work, and work effectively.
Audio