Droid Engineer Archive

• 
  
  Create two distinct markets for Droid Engineer - By turning Droid design into a Modular / Chassis system, two seperate markets would emerge. Since a number of modules and droid models do not require Master quality Experimentation, the Novice market could potentially expand by a great degree. This would allow Novice Droid Engieers that ability to have sales market, while making the climb to Master.


• 
  
  Greater Customer Freedoms - A Modular Upgrade System would give droid owners a much greater range of freedoms and would allow the owner to change the modules of their droids, without having to buy an new droid. This would give the Customer the ability to own a droid that could grow and evolve while the owner gains different skill sets.


• 
  
  Reduced 'How should I configure this run?' - Implimentation of an Upgrade system would give Droid Engineers greater freedom, when it came time to build droids. Droid Engineers could simply make a run of the Droid Chassis' and Droid Modules, and place them on their vendors independently. This would take out the guess work of what configurations would sale best.

As you can see, the list of Pro's that I came up with is rather short. I tried to come up with more positive benefits from the stand point of our profession, but I could not think of any more. Now, to outline the Con's of that I see..

Con's of a Module Upgrade System
includes Development issues

• 
  
  Price Cutting - We already see this as an issue in our current market. If droids were redesigned, it is likely that we will see a greater increase in price gouging by other Droid Engineers. Such a system would cut back on the work load and make Droid Engineering a lot easier. Doing so would allow anyone the ability to factory run massive amounts of modules and chassis', and place them on a vendor. Since a number of the Chassis' and Modules do not need experimenation, many would be tempted to sale our product at 3-5 cpu.


• 
  
  Loss of Sales - With the addition of a Modular Upgrade system, the potential for lost financial gain is increased. Allowing a customer to simply upgrade the modules on a droid reduces the need to sale additional droids down the line. Since modules cost less to produce then chassis, the overall pricing of modules will be lower then that of a current droid.


• 
  
  Increased DE Interaction - A Modular Upgrade System would lead to the need of increased interaction between DE and Customer. Imagine the number of times we are asked the same questions by different customers under the current droid design. Now imagine the number of times we will be asked the same question, if the same people are given the ability to install their own modules. Everything from 'Why doesn't my droid have more storage with 2 Level 6 modules?' to 'Why does my LE tank keep running away?I put 3 Auto-Repair Modules in it'.


• 
  
  Loss of other Development - The time that would be taken to revamp Droid Engineer would mean that time on other projects was sacrified. Each team of programmers is given a set number of tasks to work on for a Publish. If a Modular System was pushed for, it would cut into the time needed for other projects such as Decay, new Modules, new Droid Chassis, and other cool stuff.


• 
  
  Information Overhaul - Many of the issues that we know about our profession would likely change after the introduction of an Upgrade System. Not only would we have to update ourselves on the different issues, but we would also have to update our customer base on the issues as well. Droid Engineers finding out the information is rather minor, since we have a handful of really great testers around. Its keeping our customer base informed, as well as updating local Droid Engineers that don't read the forums. Most of us have already run into damage control, by having to explain to a customer of a Droid Engineer that was not up-to-date on the issues.


• 
  
  Complete Droid design Overhaul - Completely pulling the code on an existing system isn't the easiest of jobs, nor is it the always 100% effective. Unlike the Ship upgrade system, Droids were not designed with this intent in mind.


• 
  
  Droid Built before the Upgrade System - What would happen to droids built prior to the introduction of a Modular Upgrade System? It is apparent that the database does not track the number of modules installed into a droid, nor the rating of each individual module. If it did, then the issue of being able to stack Module Custers would have never been an issue. Designing a method of disassembling the droid from its modules is one thing. Not having a way to break apart the 6 Combat Modules, so that you end up with 6 modules instead of 1 overpowered module is another thing. Even this is a simplified example, since some droids that have stacked modules installed will more then likely not have the full number of possible modules installed. The potential for problems in the back engineering is a daunting task in itself.


• 
  
  Increased Database Requirements - There would bean increased database requirement for upgrading droids to a Modular system.


• 
  
  Removal of Cluster Modules - Cluster Modules would more then likely need to be removed, to allow for a Modular System, so that each individual module could be installed, instead of a lumped together module. Leaving the Cluster Modules in would reduce the upgrade freedoms.


• 
  
  Revamp Module Listings - Majority of the listed information on the would need to be updated, so that non-Droid Engineers would understand the system.


• 
  
  Removal of Level based Stacking - To help with Database tracking issues, and reduce confusion by non-DE, Level based stacking would need to be removed. A check would need to be placed on each droid that would only allowed one level of each level based module to be installed.


• 
  
  Revamping non-Level based Stacking - This would need to be addressed, to cut down on database requriements.


• 
  
  IncreaseDroid ChassisRequirements - To off-set the changes made, Droid Chassis requirements would need to increase.


• 
  
  Removal of Basic Models - It would be easier to remove the basic model of each droid, instead of having to program 26 seperate droids. Though nota major issue, since most DE do not bother with the basic models, it cuts down on what a Droid Engineer can build.

I know that not everything stated here would be correct, if such a system was introduced; however I wanted to listthe positive and negative issuesI think we would more then likely see.

Does this look to be on target? Discussion is encouraged.

Message Edited by Drashk on 11-04-2004 06:13 PM

Message Edited by GnomeAd on 11-04-2004 08:02 PM

---

GnomeAd wrote:

Another con to add to the list would be a large drop in sales.

---

Thanks GnomeAd. I forgot to add that one, after the Price Gouging.

Does everything else look to be appropriate?

Unless there is majorty support for such a system, I won't be including it in Phase 2 of Project: Droid Engineer. From what it looks like, in my intial post, there would be more negative issues then positive benefits. I just wanted to point them out to others, so that we are all aware of the potential problems with such a change.

---

LonelyGhost wrote:

Its not likely we will see any love till around this time next year.

---

---

TheRealTK421 wrote:

I'd rather need to build/use chassis but perhaps follow the idea of simply no more non-chassis/chassis models. They'd all simply be chassis and the number of modules available would be experimentable on a sliding scale (i.e. MSE 1-2, R5 2-3, etc.).

---

That wasa topicthat I was going to bring up in the next set of posts, for a modification to our current system. The problem was that I've been having problems with trying to think of a way that the modules could be added, using the same crafting interface that we have now.

If each droid required a chassis, then the crafting interface would have to change so that the available modules would need to increase or decrease depending on what chassis was used.

Theres some pro's you forgot.

Easier for total non de's to understand: Non DE's can understand how ships work pretty easily, they buy a ship, and some components, and put them together at a terminal. They cant however understand the limitations of what a droid can do, even players that have been playing for almost a year still dont understand whata DE can and cant do. Every DE has gotten an order at one time or another asking for a droid that could "help me kill rancors" or "heal people for me" seriously, if we had a modular type system then it would be practical to put a more detailed description for the modules since they would actually have a chance to read them.

Medical Module:

Requires: Novice medic

Description: The medical module allows you to heal your's or other player's wounds.

See? Even a CH or ranger or something who has never needed a droid in their entire time in SWG and therefore never exposed to their complexity can understand what that means when he puts it in a droid.

Versatility:With a module system a person no longer needs to get a new droid chassis every time they need something with a different function, it counters the increased database use quite well actually, as in you no longer need to worry about having less droids in data when you could switch out modules to alter your current droid's function.

Heres someWorkarounds to your Con's

Price Cutting: Raise the material cost for modules, therefore raising the price for all DE parts, I believe a Droid module should sell on a similar amount to what Shipwrights sell their parts for, but we arent, why? A: we use less resources B: no one wants our stuff once they buy something from us save for BH's.

Loss of Sales: modules should decay over use like weapons do. With a few exceptions. (storage mods)

Increased DE Interaction: We never seemed to have a problem with this, its what sets us apart from other professions, in the yellow text above I suggested to simplify the descriptions so the average joe rifleman can understand them since they will be exposed to the existence of said modules more. Plus people who want custom orders want to see what goes in their droid, dont they?

Loss of other Development: ? The JTL devs seem to work on stuff fast, why not have some of them work with the normal devs to speed up the development process for the revamp? You ARE doing this, arent you?

Information Overhaul : Send out in game mails? put in patch notes screen?etc.

Complete Droid design Overhaul: The weapons werent intended to go on a level system instead of a cert system, were they?

Droid Built before the Upgrade System: simple, make them sipmly chassis, I am aware this will be chaos at first but it would level out and go back to normal, eventually, (curse the low number of DE's )

Increased Database Requirements: Why would you need 5 droids when you can change out the modules on the three or two that you would have instead?

Removal of Cluster Modules: See Droid built before upgrade /\

Revamp Module Listings: Make it like Shipwright modules, as in the capabilityrestrictions on the modules are more relaxed and depend more on experimentation, As in the module level is simply the minimum of what the module's effectiveness is. Also it should be more level dependent, as in a novice markman can use the best combat modules out there at first.

Removal of Level based Stacking: See above.

IncreaseDroid ChassisRequirements: See price cutting

Removal of Basic Models: have the number of modules depend on experimentation, so an LE or BLL can actually have 6 modules if you use good resources, and lets there be an actual place to put points in places other than "effectiveness" , so you can ask a customer "you want more HAM or more modules?"

THE FISH HAS SPOKEN

Message Edited by BillyBobthe50th on 11-04-2004 11:10 PM

Price Cutting -If droid chasis are to become more like the ship chasis, then would it not be pheasable to assume that instead of using "sockets" and "socket clusters" we use "chasis mass". Therefore, experimentation on the mass of a chasis will dictate the amount of parts that chasis can maintain, including all of the standard components such as Motive Systems and Brains.To add to that, each component could well gain a mass experimentation as well. Therefore, a Master will be able to build an R2 with greater mass and components with less mass to produce an R2 that can carry more modules compared to that of a novice. Thisalonewill actually generate the OPPOSITE.By producing "high-end" droids Masters will be able to RAISE their prices.

Loss of Sales - Simple solution to this; Each time a module is swaped, the chasis loses condition. When it hits 25% of its overal condition it will suffer the same as weapons and armour and become less effective until it eventualy hits 0 and will no longer function.

Increased DE Interaction -This is a CONN and a PRO.Yes there will be"bad press" but on the other hand we will finaly get attention from other people and will actuallygain an interest as well as a market.It really all depends on how you look at it

Loss of other Development - The decay and new chasis could be worked into the same publish since they are all interlinked. This modular upgrade would require the droid pograming to be completly re-worked as it is, so its pheasable to assume that it would require an entire publish or mini-publish. Therefore it makes sense to kill several birds with one stone. And if they used the decay idea I just mentioned it would HAVE to be done at the same time. The main thing this would prevent would be the Droid Commander... which for all we know has been dropped anyway.

Information Overhaul - Again, this can be a CONN or a PRO. I personaly would enjoy having something new about DE to explore and descover. When you've been working on a profession like DE for over 1 and a half years like I have, a big change like this is welcome even if it includes the annoyance of having to explain to others how it works. Like the interaction, it atleast gives us new found interest by others.

Complete Droid design Overhaul - Its very true that droids wernt designed with this type of changeability .. but lets look at the facts here. The "inter-changable module" didn't start with ships, it started with Lightsabres. The same code was then used for ships. Thats two forms of objects that gained from the one system. Obviously it involves a lot of work, but its not hugely different from changing a lightsabre to allow module changes.

Droid Built before the Upgrade System - Again, this could well be a PRO or a CON depending on how its handled. With Lightsabre's, Jedi were given the chance to "deconstruct" their older sabre's and gain the parts back to construct a new. The same could be done with droids. Otherwise we'd gain "legacy" droids which in some cases may work out to be better than the newer droids which means we'd gain a whole new market for selling "used droids"

Increased Database Requirements - Why? As far as the database is concerned, it says "Droid A has this function, this function and this function" the modular system would be no different unless it included an extra option for mass. Remember that if you examine a droid it already displays what modules it contains, its just in text format and not displayed as rotating graphics like a ship's components.

Removal of Cluster Modules - This would be CON unless the "mass" idea was used. In which case, it may work out that Master DE's could fit more modules into droid with good experimentation. Using mass instead of clusters and sockets allows for a greater freedom and greater range of difference between the droids that DE sell. For instance, right now I can build EXACTLY the same BLL as TK. With a mass system, TK could sell BLL's with greater mass than mine but I might well be selling components with LESS mass than TK. Experimentation difference is one of the issues we've had with the profession since day one. This modular system using "mass" fixes that.

Revamp Module Listings -This is clearly a CON which ever way you lookat it. Not much I can say here.

Removal of Level based Stacking -This finaly removes the whole "two level 4 modules = a level 6" issue. I personaly believe this to be a pro. As far as I am concerned, level stacking was a bug that should have been removed.

Revamping non-Level based Stacking - Only if stacking is kept. Not sure why it would need to be.

IncreaseDroid ChassisRequirements - Why? Again, if a mass system is used with it as well, the fact that the item needs to be experimented means good quality resources need to be used. This is offectively an offset.

Removal of Basic Models - Depends how you look at it and again by using a mass system you'd still gaina form of "basic model". One with no experimentation would effectively become that which wouldn't be able to hold as many items.

However, thereis a CON I CAN see that no one has thought off;

Usefulness/Experimentation of Chasiscomponents

If this really was to come about, then chasis component experimentation would really need to be introduced. For instance;

• 
  
  Droid Brains - There would need to be a clearly defined reason that a droid requires an Advanced Brain over a standard Brain. This could come in the form of mass i.e. an Advanced Brain naturaly requires less mass or maybe the brain itself would dictate how many inate functions the droid could do.


• 
  
  Motive Systems - Motive Systems should really gain a "speed". Experimentation and the use of Advanced over Standard obviously creating a faster droid. We all know how annoying it is to have a Power Droid or Protocol trailing you 5 miles behind because they are so slow but always amased at how well the probot keeps up with you, even on mount or vehicle.

Don't get me wrong, I'm not saying that I agree or dissagree with the idea of inter-changable modules. I just thought I would point out that there ARE ways to look past the cons.