With the current system, a great sword can still break on the first hit. At least with these systems you can guatantee more than that. Even if it was a guatantee of only 10 hits, that's still 10 times more reliable, no?
depends, the breakrate would increase so you'd have more chance to degrade it 10 times and poof it, where-as on the other side with just lower breakages you'd have small chances your item degrades, then have an attempt for Tankel to fix/break it.
in either situation shit can happen, one has 10 "back-ups" and high breakrate, the other low breakrate and a gc sink/uncertain back-up repair.
besides with just decreasing breakrate he could fix that quickly and focus on the attribute system and maybe later think about this instanced break system, while we still enjoy lower breakrates in the meantime.
rather then think about this instanced breakrate system now and have him focus on either 1 of 2 things while we still have high breakrates in the meantime.
Atm weapon type is determined by an 8bit value that presently uses 68 out of a possible 255 slots. That leaves 187 slots that could be used immediately to implement an instanced quality system. If you also vary the quality graduations so as lower end items have fewer, and higher end items more, a rough calc suggests you could cover all weapons under the present system right away (particularly if you are intending limiting the overall choice to exclude some of the el weapons). Bear in mind the system is even easier to apply to shields, as very few of the slots are currently utilised, ditto helms etc.
As far as breakage factor is concerned, it makes sense to retain both that and a degradation factor for each weapon as it gives a greater choice and variety of weapon characteristic, ie :
1) Weapons that don't degrade but have an increasing break rate.
2) Weapons that don't degrade but have a constant break rate.
3) Weapons that degrade with reducing characteristics, but only break at the lowest value
4) Weapons that degrade with reducing characteristics, with increasing break value throughout
5) Weapons that degrade with reducing characteristics, with a constant break value throughout
6) Weapons that degrade but retain a constant characteristic, but only break at the lowest value
7) Weapons that degrade but retain a constant characteristic with increasing break value throughout
8) Weapons that degrade but retain a constant characteristic with constant break value throughout
I'd suggest the coding effort in applying the above would be relatively simple, as it wouldn't affect storage, trading or the comms protocol. The only thing that would need to be changed client-side would be the defines in client_serv.h, plus maybe some of the graphics links. On the server-side, (I should imagine) there would be no time-consuming changing of data types or comms protocol or much else, simply the implementation of a structure to hold breakage/degrade values and some straight forward changes to the existing subs to implement that characteristic.
Yup, in the long term, it will be necessary to implement a 16bit data type to hold weapon values, particularly if it is intended to extend the range. However, that can take place gradually in the background without significant impact on delivering features that deal with more immediate gameplay issues.