Let's see,
- Suppose at the beginning any item has owner column so that they will called up and appear in owner inventory when said owner logged in.
- To have an item lend-able, dev must add another column to item database, borrower
- If owner and lender borrower has same value, item will appear in owner inventory, with their original attribute (tradability/stashability/etc)
- If owner and lender borrower has different value, item will only be called if the borrower log in, with it applied lender attribute (egg hatching script can't run, tradability disabled, so on). Uh oh, seems like a lot of work.
- To apply that special attribute, it's easier to create new item with new classes attributes than slapping on those special attributes through a rewrite. So that whenever somebody lend something, a new item is actually created, while old item has a column rewritten so that they're disabled. This effectively doubled the item classes.
So, this is your game client do to server when logging in.
- Pull list of item owned by this player,
- Check if owner === borrower, to see whether this item available to owner to be used
- Pull list of item lent to this player,
so far so good.
This is your game client do when player initiate lending scenario,
- Check if owner === borrower, to see whether said item can be lent.
- Initiate lending window, so that system can establish from and to which player an item will be lent.
- Upon hitting lending button,
- disable the item on owner inventory
- rewrite borrower column so that it's different than owner column
- create new row on item table. This item will appear on borrower inventory.
Starting to look like database inefficiency. But let's move on.
This is your game client do when borrower want to return an item.
- Upon hitting return button,
- seek original item row
- enable that original item
- write so that that item owner === borrower once again
- destroy lent item from database.
It's still doable.
This is your game client do when lender want to recall an item.
- Upon hitting recall button,
- seek lent item row
- check whether said item is in use,
- do stuffs so that item is free to be deleted, comprise of many steps.
- enable original item
- write so that that item owner === borrower once again
- destroy lent item row from database.
OMG.
I'm sure I missed about 90% of the steps (excluding steps I intentionally omitted), but all in all, it can be done from programming point of view. From game economy point of view, it still need a review. From game return of value, it also still need a review. Will this feature lead players playing the game more? Will this feature entice new player to start playing the game? The proponent must appeal to game designer so that it can be kicked up on their priority list (and so that the game executive can give a green light to do it).
Bookmarks