Hammer vs. Coffee Machine

I implemented a simple "competition" feature. Competition means, that some items can damage other items. This is another check of the item server design.

Competition is a bit more advanced and demanding, than the crafting. During implementation I learned, that we need floating point values in addition to integer values. I could map all crafting actions onto integers. But competition needs finer grained computations. So I had to change the database. I also added time values to implement a cool down period and had to change the database structure again. Effectively, the cool down implements a hit-rate limitation, which leads - in combination with damage values and modifications - to the usual DPS (damage per second) statistics.

Before I started coding, I modeled the behavior in Excel:



Here is what we can see at on the inventory web pages. This is the inventory with a hammer and a coffee machine. I used the coffee machine to make coffee, but the hammer can also damaged it:



This is the coffee machine. It is in perfect shape (Condition: 100%, Hitpoints: 1000). Obviously, the coffee machine is susceptible to shock damage and piercing damage. But shock damage is more dangerous. Piercing damage can be absorbed more easily.



The hammer. It can be used once per second (Attack cooldown). The hammer is a shock device. It smashes into something. It does no piercing damage. A knife would be different. The hammer makes 100 points shock damage. But the victim will absorb some of the damage.



Now I can hit the coffee machine one with my hammer with this command:

http://localhost:3277/Portal/Inventory/DroidAction/61/Hit/47

After the "hit", the coffee machine is in worse condition than before. It lost a bit of its "Condition" value (Condition: 93.0 %):



The hammer lost also a bit of its condition. Much less than the coffee machine. It is just a bit worn down (Condition: 99.9 %). The hammer will have to be repaired after some time in order to project the full damage.



Very simple, isn't it? But there are powerful mechanisms implemented which we will use later. The design of the item server has been verified and completed with workflows of different areas. The item server:

• caches items,
• loads items from a database
• returns item properties on request
• has user actions
• has interactions between items, and
• saves changes to the database
  

I will now leave the item server and return to work on the client. The client has lots of back-end and protocol code. But it does not really show avatars. We want to see animated avatars chatting on web pages. The client also needs a user interface. It needs windows, dialogs, a settings dialog, a buddy list, etc. But most important are avatars. That's the next step. Not a small one. I'll keep you updated.