Droid Engineer Archive

Well, I can say that the idea of modular droid configuration has been brought up before, but was not considered a priority over the other wants/needs of the DE community. It's a "nice to have" at this point. Even then, there's a lot of people who prefer not to go that route, as it has the potential of decreasing long-term sales. I for one would find it an interesting aspect to play with, and find it a natural fit into crafting a droid. In the SW universe, droids are supposed to be upgradeable for the most part.

That being said, I've heard rumblings that they also might introduce the modular crafting model to vehicles sooner than later.

---

Gron_DM wrote:

Hello!Previously i was one of the largest (if not the most vocal) for the modular system...ill try to track down the url to our old posts on the topic and here is a quick sumation of the pros and cons of the system:

Pros:

-More intutive use of droids

-Allows for more oportunities for users to customize and interact with droid

-Allows user to use one droid frame and get the overall mix of desired modules/abilites as needed.

-Allows for other useful ideas like modules with charges, modules that are from loot components and modules that are only usable by people with specific skills (in other words useful when coupled with other ideas)

---

Indeed, it would lead to a more natural seeming usage for droids. Here is the way I see it:

You buy the droid frame together with essential components. You then equip that droid with modules that suit your needs, upgrading and replacing them as your needs change. The frame of the droid can decay and receive damage over time. It should be capable of taking considerable damage, but eventually need replacing. It should not be repairable. When it has degraded enough it should start to suffer in effectiveness and functionality, possibly breaking down more often, or causing damage to its modules over time.

The modules themselves can take damage and could decay. Usage over time should cause decay, damage in combat should result in damage and perhaps using a module in a beaten up droid chassis can result in sudden catastrophic failures. Droid engineer would have a diagnostic tool that let them determine damage levels and causes - and proscribe fixes. This would require specialized knowledge available only to the DE in some cases, but some simple changes could be done by anyone who bought a module.

Some droid chassis should take some modules but not all, so that functionality of modules requires certain specific chassises. Alternatively they could simply work better in specific models. I think Storage Modules should fit in a Binary Load Lifter with a max of 80 objects say, I think storage in a MSE might be limited to 4 objects or something. LE Repair droids ought to offer greater functionality in the repair role etc.

---

Cons:

-The system as a whole doesnt add any new functions for droids

-Doesnt fix our current problem, (informing the customer not withstanding)

-Allows for people to run being a DE strictly as modular sales and not whole package...ergo means less sales and lower value on the droid itself. Also means market will get flooded with mods.

-Doesnt address other problems like decay, more possible droid frames.

-Takes development time the likes of which would really be like a complete patch, which is unlikely to get that kind of attn...and if we did more DE's are for bug fixes, decay, a combat prof droid handler, more combat droids and more utility functions(whew that is a long list).

-(Related to above)Even though there is a space mod system it wouldnt really be easily codable as the previous mods would have to recoded to work with it and prexisting droids in turn would require a great deal of code to handle the conversions.

---

On the contrary I think it might clarify some of the roles of the various components, and might make testing functionality of modules much easier. Translating current droids to the new roles might take a bit of work and we would want to avoid invalidating all existing droids because that would simply annoy their current owners (not to mention DEs with a lot of stock on their vendors). By providing an interface for installing modules and configuring your droid modeled on the one used by Ship owners - with some operations requiring a DE to perform them and some being user managed I think it would provide a much friendlier environment to inform users of how droid modularization works and what components can be installed where. Taking a page from the Image Designer interface, it ought to be possible to adapt that mechanism/code for the use of DEs working on a user's droid. A similar interface would let us install components, set a price for our actions etc, and nothing would happen until everyone agreed on the changes. This could include customization of droid colors etc, allowing senior and Master DEs greater pallets to choose from etc.

I think I have already made suggestions as to decay etc that would go a long way towards alleviating that concern.

As for the coding. Yes its a substantial change, but in fact much of the coding will already have been done when they built the ships design. This is the point of object oriented programming (yes I am a programmer) - much of that code, if its well written, can be adapted to making this change to the way droids work with relatively little adaption. Many of the problems they faced in designing modular ships will already have been resolved and can be adapted to this new design concept. It seems a natural development to me, and would result in presumably better implementation of droids because it too is more modular (and this more easily fixed as each module would be a type of object in the code and can be dealt with individually or collectively). RIght now it feels like the development on droids has been very piecemeal and is probably not all that clean an implementation as it has evolved over time.

Conversion would require a module capable of reading the values for your droid in the database, then creating a replacement droid, probably keyed on the next time you call it. When all old droids are replaced in the database (and it would require a new table or set of tables in any case), they can wipe the old data. Once the means to define the new droid objects is present in the code, and a mechanism exists to translate old droids to new droids, it would be a simple process to make people convert them on calling them, or when a deed is activated.

---

Dont get me wrong i would love some form of implementation of a modular system. I think the pros really do outweigh the cons but honestly there is soooo much wrong with DE (espcially post CU) it is seriously doubtful you can expect that kind of commitment of dev time let alone getting a strong backing for this from the DE community(not that our correspondants wouldnt want to help DE but as listed above most consider the other problems with the profession to be more critical). ouch bad run on sentence....

---

I think the revision of droids along these lines would make dealing with those existing problems easier in fact by making them more consistent. It woudl require some thoughtto get the best implementation but I think it would possibly make dealingwith existing problems easier, since the code could be rewritten to reflect the desired functionality rather than having to edit existing code (which is often slower as you have to figure out the impact of any change, writing new code gives you a clean slateto work on and can sometimes be faster. Many of the existing problems might well go away entirely - although undoubtedly new ones would be created in the process.

---

Thank you for posting this still, its nice to see that the fun factor in modularity is still desired by others.

---

I like making droids, I just want to make ones that do what they are supposed to do and seem *right* to users, so they are happy to buy them. I want droids that facilitate playing the game without overpowering characters. I want droids free of exploits so they can't be used to macro, can't be used to exploit or powerlevel, but are still functional, useful and fun to play with. I want to be able to have more than one droid out at a time. I want combat droids that are at least as useful as a player controlled pet, but not more so. I think modularizing droids will go a long way towards making them seem more "starwarsy" and more acceptable to players, particularly now that they have seen the way ships work...

Long time crafter, noob DE here. When I decided to make a change (quitting BE after a year and a half) the reason I decided on DE rather than say shipwright were the for the exact things you are suggesting changing. Just because theyare able to adapt theshipwright crafting system for DE, doesn't mean that they should

I look a shipwright and pity them basically, because what I suspect is that their customers are having a lot more fun putting together the ships they make, then they themselves are in making those components, and that is a real shame for them. I also pity them because of the fact that shipwright customers are basically able to loot a really large percentage of the components that shipwrights are able to create. If I was to point at one crafting class and say "that's the worst one, thank gawd I'm not a ...", shipwright would be that one, no question about it.

Lets not change a good thing. If you like modular component crafting, and you like the idea of creating things for certified customers, then I've got just the answer for you... shipwright!

---

Sneev wrote:

Just wondered if there has been any mention of the possibility of the Devs revising droids to use the modular system employed by ships in JTLS? Obviously they have developed the code that allows a player to configure a ship with various modules for various purposes. It seems natural to me that we would hope they implement the same sort of code for the next stage in droid development. Having proven this game concept works in the one instance, it should be quite possible to rework it in the case of droids - that being the whole purpose of object oriented programming.

---

Message Edited by ArthurDentOnBria on 05-26-2005 05:09 PM

I've spoken at great length about this before, but eventually I realize it all comes down to one thing : for what end?

Ships have modularity because of the varied practical applications. One engine makes your ship faster than another, one weapon has better damage than another, one capacitor has a higher recharge (but may be worse at something else). All of these factor in to the ship performance, because the object in question is so dynamic.

The same cannot be said for droids. One droid doesn't move faster than another because of the motive system, or responds to commands faster because it has a better brain.

People have said, "but why not? let's do that!" to which I again would ask, "to what end?" Let's say that all of a sudden quality mattered on a droid brain, and the better the brain the faster the droid replied to the command. Well, right now it's instantanious - no where to get "better" from here. So, in effect, implementing that type of system in this case require a nerfing of droids - in this case making some droids slower than instant - instead of getting what we already have, we'd have to work harder to get it.

Same can be said for things like droid speed, or any other attribute. The reasons ships are modular is because their behavior (acceleration, top speed, manuvering ability, weapon refire rate, weapon strength, and over a dozen others) as well as their quality (HP/armor) varies on a huge, tierd, certed level. Droids do not even approach this.

The next thing many say is, "well, we need to make droids more useful then!" This is true, but making droids more complex just for the sake of it at the same time isn't going to help. It's also going to be all but invisible to the end user, or at the very least inconsequential. Would someone pay a lot for a ship part that used a rare resource to get a higher refire rate? Sure. Is someone going to pay a great deal extra for a droid that responds in .5 seconds instead of .9 seconds? Probably not, unless you nerf the low-end so unreasonably (say, making it 1 second versus 15) which in the end again just becomes a big nerf to how our droids already work - making us work harder for something we already have an certainly isn't bringing any new functionality to the end user.

This also doesn't begin to touch the economic aspect. Because droids do not decay our biggest reason for repeat sales is reconfiguration. An architect becomes a scout and has to buy a new droid with the proper tools. If droid modules were modular, we wouldn't see that sale again. With the Global Vendor Screw...er, Search some guy would just run off crates of modules and sell them for crap. At least now a DE has control over our product - we don't under modularity. One suggestion has been to only let DE's work on droids they make, but that comes with a whole slew of problems (turning DE's into socket monkeys, what happens if the DE leaves, etc.). Under any other scenario, you'd see a bunch of guilds get DE alts and people willing to do it for nothing, which would cripple our profession - again, especially under the current crafter economic enviornment.

Now, as a mini-game for DE's, it would be interesting. Even fun. But with the dearth of salable product we have now - after losing a good half of our modules in the past few months - we cann't afford to be asking for something that, in the end, is mostly for DE's and wouldn't have a positive impact on sales. When and if we get attention, we need to be clear in asking for simple, effective items to sell that people actually want to buy from us. Putting the shipwright code in just because they could isn't the soloution because a copy wouldn't be good enough - it would actually defeat the purpose. Look at the BS we've had to deal with because in beta they didn't have time to write a true droid code, and droids went from inventory objects to CH pets. Even wonder why a repair droid used to say "Do Trick One" for repair?

Some form of DE mini-game, or limited module swapping under controlled circumstances (perhaps the DE could decide during construction if it can be added to by leaving empty slots as a consequence?), might be fun some day in the future when we don't have anything else to worry about; for the time being, however, I think when you really look at what the actual benefits would be versus the possible consequences, quite frankly we have much bigger jawas to fry.

AO

Okay, first of all, whats up with the stupid forums!!! Laggy as heck!!

Its a kewl idea but like others saud. it would make for less droid sales. and also. your droid user profession seems kinda like the droids handler thing that been talked about and that seems to me to be a bad idea.

I thinkthe key element in any modular droid system is that _only_ the DEshould be able toaccess the modular interface (and I suspect the devs wont go for that)

Others have already stated it very well, and I'll just weigh in my viewpoint on the issue. It comes down to one of two senarios. Scenario one: its easy to swap modules in/out (so non-DE's can do it) and we lose sales and become parts brokers rather than droid engineers. Scenario two: It takes a DE to swap the parts, and we're no better off than we were. Besides that, most of us are DE's to build droids, not to build droid components. Droids are cheap enough (resource wise) resource wise that throwing together a new one if someone wants a new setup is about as easy to make them a new one as it is to swap out the module. Add to that that the number of available DE's on each server is low enough that most people couldn't swap modules when they needed to anyway, and you end up with no benefit for a massive amount of development time.

One thing to keep in mind is that a change to modularity would require a complete scrapping and re-coding of half the droid functionality in the game, and most likely would not be able to be backwards compatible (old droids could not be modular). It would require more database storage, would cause more server processing... just not worth it at this point (or any point in the forseeable future).

1. This would mean less money for DE's in the long run.


2. Droids keep no memory of what the stats on the modules installed were. Meaning you would need huge changes to how droids work. This is a lot of work for no other benefit then it being "cool." Ships work this way, droids don't.


3. Developer time could be much better spent for other things with Droid Engineers.