[erlang-questions] If you are homesick for object.selector

[David Goehrig]

On Jan 23, 2013, at 9:37 PM, Loïc Hoguin <essen@REDACTED> wrote:

> Character.current_weapon.ability.points_req
>
> Or
>
> Character.inventory[0].name

Putting my game programmer hat back on, given a choice I would prefer:

  Character weapon ability cost

Where each is an application of a method on the prior or in Erlangy speak:

    cost(ability(weapon(Character)))

Where in each function destructs and returns an element of the nested structure. I might for sake of argument want to further name them:

  costOf(abilityOf(weaponOf(Character)))

Now in a typical game, weaponOf vectors to the currently selected item from the inventory. AbilityOf vectors off of the currently selected special assigned to the B button / right click slot, and the cost is tied to the level of the character for scaling (if you assume a fixed sized mana pool). 

Usually each of these behaviors require implicit knowledge of other state, and would likely make extensive use of get/put  in the Character's process dictionary to vector accordingly.  

This would imply these structures are best managed in an entirely different manner, where the Character process should memoize the values in a process dictionary, and the interrogation should happen only once upon an equip(Weapon) method. 

Same issue goes with inventory. We probably need a weapons manual process that can be interrogated for details based on names.  These changes would make it more likely to be a bunch of message sends. To WeaponManual, Inventory, Character, etc. 

It would be difficult to justify the dot notation as it wouldn't even remotely resemble how one would structure the message sends. 

Dave

-=-=- dave@REDACTED -=-=-



> 
>  Character.current_weapon.ability.points_req
> 
> Or
> 
>  Character.inventory[0].name