Droid Engineer Archive
Thread: Module Stacking and General Socket Module Clusters
Page 1 of 1
Icarus-6
Wed Nov 12, 2003 5:30 pm
#1
(continued from http://forums.station.sony.com/swg/board/message?board.id=droid_engineer&message.id=37916 in order to stop hijacking that thread)
As I said above, if the stacking were done properly that would help to alleviate some of the feeling that module stacking is a bug. It is basically the fact that 2 level 4 modules max you out and give you the same results that can be achieved with level 6 modules that causes the problem. If it were to take two level 5 modules to max you out we probably wouldn't feel quite so shorted. Level 5's tend to require hard to get materials and lots of skill, and if two of them equalled a level 6 then I think many of us could shrug and say 'Yeah, but it takes an extra slot' and feel the level 6 has some inherent worth.
Personally, had I designed it I would have probably made it so that each level is the equivalent of 2 modules 1 level below it, so it takes two level 5 modules to equal a level 6, four level 4 modules, and eight level 3 modules (an impossibility if the cluster 'bug' was fixed).
However, the current method -I believe- is to total the modules and subtract 1, so you can actually max out with one level four and one level three. Being an arithmetic progression it causes lots of gameplay problems.
So how to fix it? Well, I would personally probably do something along the lines of giving each module a number of 'points' equal to 2^(Rating-1)*Experimental Efficency (or Quality or whatever). This means a well done level 6 module would probably give you between 29 and 30 points. (2^(6-1)*.95=30.4)
I would then total up all the points from modules and use those to determine the effectiveness of the droid, probably through a chart like below:
1 - 1 item storage
2 - 2 item storage
3 - 3 item storage
4 - 4 item storage
5 - 5 item storage
6-8 - 6 item storage
9-12 - 7 item storage
13-17 - 8 item storage
18-24 - 9 item storage
25-36 - 10 item storage
37-52 - 11 item storage
53-71 - 12 item storage
72-91 - 13 item storage
92-120 - 14 item storage
121+ - 15 item storage
This is just a rough chart. The curve probably needs to be smoothed out. The point to it though is that if you make a bunch of crummy level 3 storage modules (50% efficency) you are going to need about 15 of them to equal one nicely made level 6 module.
Grimjakk wrote:
Icarus-6 wrote:
I think that the bug is that you are not suppose to be able to put cluster modules into general module sockets, but the code is goofed and it lets you.
I think another element to this "issue" (bug or no) is the built in function caps. If stacking 2 level 3's give as much functionality as 1 level 6, but 2 level 4's 5's or 6's don't give any more functionality, where is the incentive to use the better modules?In my personal opinion, stacking multiple modules should give diminishing results. Say just for argument that the only two modules can be stacked, and the second (or lower rated) module always gets its functionality cut in half.
Say for example, Storage6 gives has 10 storage units (just guessing... all my time as MDE, I've never built one) two Storage6's would give 15 storage units. And THAT's where it should cap out.
There should be an upper limit, but it should cap out only when the top quality modules are used.
As I said above, if the stacking were done properly that would help to alleviate some of the feeling that module stacking is a bug. It is basically the fact that 2 level 4 modules max you out and give you the same results that can be achieved with level 6 modules that causes the problem. If it were to take two level 5 modules to max you out we probably wouldn't feel quite so shorted. Level 5's tend to require hard to get materials and lots of skill, and if two of them equalled a level 6 then I think many of us could shrug and say 'Yeah, but it takes an extra slot' and feel the level 6 has some inherent worth.
Personally, had I designed it I would have probably made it so that each level is the equivalent of 2 modules 1 level below it, so it takes two level 5 modules to equal a level 6, four level 4 modules, and eight level 3 modules (an impossibility if the cluster 'bug' was fixed).
However, the current method -I believe- is to total the modules and subtract 1, so you can actually max out with one level four and one level three. Being an arithmetic progression it causes lots of gameplay problems.
So how to fix it? Well, I would personally probably do something along the lines of giving each module a number of 'points' equal to 2^(Rating-1)*Experimental Efficency (or Quality or whatever). This means a well done level 6 module would probably give you between 29 and 30 points. (2^(6-1)*.95=30.4)
I would then total up all the points from modules and use those to determine the effectiveness of the droid, probably through a chart like below:
1 - 1 item storage
2 - 2 item storage
3 - 3 item storage
4 - 4 item storage
5 - 5 item storage
6-8 - 6 item storage
9-12 - 7 item storage
13-17 - 8 item storage
18-24 - 9 item storage
25-36 - 10 item storage
37-52 - 11 item storage
53-71 - 12 item storage
72-91 - 13 item storage
92-120 - 14 item storage
121+ - 15 item storage
This is just a rough chart. The curve probably needs to be smoothed out. The point to it though is that if you make a bunch of crummy level 3 storage modules (50% efficency) you are going to need about 15 of them to equal one nicely made level 6 module.
Icarus-6
Wed Nov 12, 2003 5:56 pm
#2
Ok, I'm a geek. Here's a smoothed out version of the chart:
>0 - 1 item storage
1 - 2 item storage
2 - 3 item storage
3 - 4 item storage
4-5 - 5 item storage
6-8 - 6 item storage
9-12 - 7 item storage
13-16 - 8 item storage
17-22 - 9 item storage
23-32 - 10 item storage
33-44 - 11 item storage
45-61 - 12 item storage
62-86 - 13 item storage
87-120 - 140 item storage
121+ 15 item storage
So why did I spend 10 minutes to smooth out the chart? Because it only took 10 minutes. Maybe it still needs a little tweaking to be determined through game play but I would hazard to guess that it's pretty much right on target for where it needs to be.
I guess my point is, if I can do this that quickly I wish the Devs would spend time to work out a better system as well.
(BTW, you could express this as a formula of S=log(P)/.14364, so it doesn't even really need a chart and you could tweak the constant to give more or less storage depending upon what the game needs)
>0 - 1 item storage
1 - 2 item storage
2 - 3 item storage
3 - 4 item storage
4-5 - 5 item storage
6-8 - 6 item storage
9-12 - 7 item storage
13-16 - 8 item storage
17-22 - 9 item storage
23-32 - 10 item storage
33-44 - 11 item storage
45-61 - 12 item storage
62-86 - 13 item storage
87-120 - 140 item storage
121+ 15 item storage
So why did I spend 10 minutes to smooth out the chart? Because it only took 10 minutes. Maybe it still needs a little tweaking to be determined through game play but I would hazard to guess that it's pretty much right on target for where it needs to be.
I guess my point is, if I can do this that quickly I wish the Devs would spend time to work out a better system as well.
(BTW, you could express this as a formula of S=log(P)/.14364, so it doesn't even really need a chart and you could tweak the constant to give more or less storage depending upon what the game needs)
SinjenRandall
Wed Nov 12, 2003 6:08 pm
#3
I like the one that gives 140 item storage best!
Seriously, though, I know what you are saying. I agree. I don't think that module stacking in and of itself is a problem (besides the module clusters, which are obviously a bug), I think the low cap, low module diversity,and the linear stacking is.
There has been discussion on this before, most recently pounded on:
http://forums.station.sony.com/swg/board/message?board.id=droid_engineer&message.id=37192
I am sure Drashk would appreciate your disscussion in that thread, or in his new version if he gets it up soon.
Icarus-6
Wed Nov 12, 2003 6:34 pm
#4
Whoops. That's a typo. Naturally it is suppose to be 14.
As for the other thread, it is really focusing on a lot of different issues. This thread is only addressing the single issue of stacking modules, and peripherally the issue of socket cluster modules.
Having skimmed his thread I think they a proper fix to stacking modules and to fixing cluster modules could clear many of the current headaches with one more modification; droid types would need to supply some sort of modifier to the base points granted by the modules. This is necessary so that an advanced R3 unit with six high quality medical modules won't exceed the abilities of a surgical droid loaded up with medical modules.
Off the cuff I would be inclined to divide the base medical points of any non-surgical droid by 4. While this might seem heavy it would allow a non-surgical droid with a single high quality medical module to have a medical rating of around 85 (assuming the new medical chart roughly paralleled the old one and that a single level 4 module in a surgical droid gave a medical rating of 85). While that might seem a little low, remember that a) we are talking about a non-surgical droid (MSE droid with a medical module) and b) it would be possible to put in a second module to boost the rating (unless you are dealing with a 'lower' droid like a base MSE, at which point I think an 85 medical rating is pretty darn respectable.
As for the other thread, it is really focusing on a lot of different issues. This thread is only addressing the single issue of stacking modules, and peripherally the issue of socket cluster modules.
Having skimmed his thread I think they a proper fix to stacking modules and to fixing cluster modules could clear many of the current headaches with one more modification; droid types would need to supply some sort of modifier to the base points granted by the modules. This is necessary so that an advanced R3 unit with six high quality medical modules won't exceed the abilities of a surgical droid loaded up with medical modules.
Off the cuff I would be inclined to divide the base medical points of any non-surgical droid by 4. While this might seem heavy it would allow a non-surgical droid with a single high quality medical module to have a medical rating of around 85 (assuming the new medical chart roughly paralleled the old one and that a single level 4 module in a surgical droid gave a medical rating of 85). While that might seem a little low, remember that a) we are talking about a non-surgical droid (MSE droid with a medical module) and b) it would be possible to put in a second module to boost the rating (unless you are dealing with a 'lower' droid like a base MSE, at which point I think an 85 medical rating is pretty darn respectable.
Kitsunetsuki
Wed Nov 12, 2003 7:56 pm
#5
Heh. That 140 makes me imagine droid experimentation to be something like blackjack. An "amazing success" causes you to bust and go over 121. Augh!
Anyhow, to drag in the last paragraph from my post in the other thread, and the response to it, I'm not sure an opened cap on droid storage would necessarily lead to everyone owning five Advanced R3s with 60 slots each and no other droids of any kind. Especially if this is combined with more attractive droid features in general, so that people wouldn't want to use all their droid slots for extra inventory storage.
As I said, I understand the concern with grossly inflated inventories, but it's not really an absolute black and white issue. After all, most professions don't need to plant harvesters on every available lot the way artisans do. For relatively cheap they can get 300 extra free inventory slots by building two small houses. In fact, they can own five small houses and own 750 extra things. I've seen plenty of extra "storage houses" around the galaxy as it is, usually right next door to the owner's residence. The reason it's not as big a deal is that you can't carry the houses around and many players want to use those plots for other things.
That's roughly analogous to the argument I'm making with regard to droids. A droid with inventory slots offers players the ability to own more things at once, but is somewhat less convenient than regular inventory storage (due to the limitations on calling droids), much more expensive (due to the resources involved), and most players will not want to dedicate every single one of their potential droid modules to obtaining a few more inventory slots.
Yes, a droid is more portable and convenient than a house, but it's also much more expensive than a small house for the types of droids we're talking about, and still offers less theoretical maximum storage than the houses do.
So beyond the question whether to leave the cap where it is or open it wide up, there is the more general question of, given the constraints on the convenience of acquiring and using storage droids, what is a reasonable upper limit? I would suggest it's definitely more than ten slots per droid. Furthermore, how could the convenience of using droids be tweaked to balance out a higher potential capacity?
Off the top of my head, perhaps once droid battery usage is a little more reasonable, droids could burn through power quicker the more items they contain. Add on top of that a restriction that you can't open the inventory of a droid in need of a charge, and you've got an additional downside that would make use of multiple 60-slot droids more trouble than it's worth for many people. That might be sufficient to allow removal of any sort of hard limit on droid inventory without causing an imbalance, and while still allowing players to find their own ideal level of compromise.
Anyhow, to drag in the last paragraph from my post in the other thread, and the response to it, I'm not sure an opened cap on droid storage would necessarily lead to everyone owning five Advanced R3s with 60 slots each and no other droids of any kind. Especially if this is combined with more attractive droid features in general, so that people wouldn't want to use all their droid slots for extra inventory storage.
As I said, I understand the concern with grossly inflated inventories, but it's not really an absolute black and white issue. After all, most professions don't need to plant harvesters on every available lot the way artisans do. For relatively cheap they can get 300 extra free inventory slots by building two small houses. In fact, they can own five small houses and own 750 extra things. I've seen plenty of extra "storage houses" around the galaxy as it is, usually right next door to the owner's residence. The reason it's not as big a deal is that you can't carry the houses around and many players want to use those plots for other things.
That's roughly analogous to the argument I'm making with regard to droids. A droid with inventory slots offers players the ability to own more things at once, but is somewhat less convenient than regular inventory storage (due to the limitations on calling droids), much more expensive (due to the resources involved), and most players will not want to dedicate every single one of their potential droid modules to obtaining a few more inventory slots.
Yes, a droid is more portable and convenient than a house, but it's also much more expensive than a small house for the types of droids we're talking about, and still offers less theoretical maximum storage than the houses do.
So beyond the question whether to leave the cap where it is or open it wide up, there is the more general question of, given the constraints on the convenience of acquiring and using storage droids, what is a reasonable upper limit? I would suggest it's definitely more than ten slots per droid. Furthermore, how could the convenience of using droids be tweaked to balance out a higher potential capacity?
Off the top of my head, perhaps once droid battery usage is a little more reasonable, droids could burn through power quicker the more items they contain. Add on top of that a restriction that you can't open the inventory of a droid in need of a charge, and you've got an additional downside that would make use of multiple 60-slot droids more trouble than it's worth for many people. That might be sufficient to allow removal of any sort of hard limit on droid inventory without causing an imbalance, and while still allowing players to find their own ideal level of compromise.
Icarus-6
Wed Nov 12, 2003 9:23 pm
#6
I'm not completely convinced a hard cap is necessary, though from a game design standpoint it probably would be desirable.
Using a system like I outlined a person with 6 high quality storage modules would wind up with only 16 or 17 storage spaces. Certainly a lot better than to 10 items currently, certainly far less than the 60 items a strict arithmetic addition would give you.
Using a system like I outlined a person with 6 high quality storage modules would wind up with only 16 or 17 storage spaces. Certainly a lot better than to 10 items currently, certainly far less than the 60 items a strict arithmetic addition would give you.
Page 1 of 1