[Cidan]

Howdy all.

My name is Cidan and I'm a UI author for World of Warcraft. I have recently migrated from that game to this one. I have a few thoughts on what to do when it comes time for an API to be implemented into LotRO and I thought I'd share a few with you all.

Before I get started I'd like to state my particular specialty is abstracting the API already in place in games such as WoW so they are modular and easy to use, and no, I don't mean Ace2. (Though really in a more general sense I abstract with all my projects, rendering engines, etc.) I also DO understand that any and all API functionality is not going to come for a lonnggg time, if ever.

Object Recycling

I think the very first thing that needs to be in place when exposing the API is recycling of assets. I can not stress what a mistake it is to not recycle assets and to leave things up to some garbage collection system. I'm assuming that LotRO will at some point use some sort of managed language, which is fine. However all objects created by this API must be pooled. That is, developers should be able to call a function on the object to sanitize it and the engine will put the object back into a pool for reuse. Next time an object of the same type is created, it will pull from the pool first before creating a new instance. Over time the game should garbage collect what is in these pools.

Signals

If I recall what I read a while ago, Frosty did mention that developers will be able to create their own signals. I applaud this, but make sure they are flexible enough that we can bind multiple calls to a single signal, etc. Other than that, woohoo! One less thing to abstract. :P

Click Casting and Interaction

I strongly suggest holding off on any sort of "click and you will cast a spell on this player" functionality in the API. We have seen it... er, destroy other games and raiding environments. I would hesitate including this feature at all. Once the player modifiable UI moves into the realm of in-game interaction you have to tread lightly. I would suggest that when it comes to actual game play, developers need to be limited to just information-type UI's and not interactive ones. At the very very most, limited interaction such as click to target should be safe. This is solved by never including a function that allows one to cast a spell/skill and including a function that allows targeting but still allowing a user to create action buttons.

Movement

This is a no-brainer but I thought I'd include it for good measure. Under no circumstances should an addon/UI be allowed to move the player or camera.

Unit Data

In games like WoW, events will fire when Health/Mana changes and it's up to the author to find out what the HP/Mana is at the time of the event firing. While functions that pull unit HP/Mana and other datasets are nice, I would take this one step further. Almost every (decent) addon/UI I know that deals with units has some sort of array with unit "objects" in them. These objects contain functions for various things. For example we'd be able to get a unit object by player name and then call functions on it. Unit.GetMorale(); Unit.GetStance(); Unit.GetName();, and so on. I highly suggest this is implemented. Some will argue it creates overhead, but I put forward the argument that having the engine do it versus having 4-5 addons each store units is a much better way to go about unit data. However developers should be able to augment units and add new functions across the units. Generally you don't have to worry about developers polluting the global/unit space because if an addon does break something then the end user will just not use it.

That's it for now, I think. I'm sure more will come to mind, but eh. Let me know what you all think!