HeroEngine Forums

HeroEngine Support => Scripting & Programming => Topic started by: Triplelexx on Jan 18, 13, 12:10:21 AM

Title: Item System & NPCs
Post by: Triplelexx on Jan 18, 13, 12:10:21 AM
Hi, I could really use any support with using the new item system in the context of NPC characters.

I am confused over the container ownership restrictions and would appreciate any advice regarding what is required to give an item to an entity without an account.

Could I just pass other references and still use a container via association?
Any examples regarding doing more than giving the player an item would be a great help.

Say I create a weapon item and an appearance to glom with it, how would I best go about "giving" that to a NPC?

Title: Re: Item System & NPCs
Post by: Tarra2012 on Jan 18, 13, 03:47:18 AM
I havent done it for npc´s. But cant you add parent class _itemcontainerowner to npc class and use the Itemsystem?   

In this case Create Container. Add Container to npc. Create Item inside.
SingleVisualization Decorator would enable appearance and rendering to bones and such.
 (But you can do that on your own too)

Title: Re: Item System & NPCs
Post by: Triplelexx on Jan 18, 13, 09:29:07 AM
I think I would want to do something like this but it looks like it will at least require rewriting the container class as it seems to be referencing _PlayerCharacter and creating an association with the players account.

  where me is kindof _PlayerCharacter   

Or maybe I'm over complicating it in my head and some parts only refer to the replication, yet the item could still be owned?   
Title: Re: Item System & NPCs
Post by: HE-CHRISTOPHER on Jan 18, 13, 09:45:16 AM
A few architectural comments...

It is generally a good rule of thumb to make the representation of an NPC as lightweight as possible (e.g. consume the minimum amount of memory and CPU processing possible) so that you can leave as much of the server resources as possible for other things like servicing player requests and simulation. 

As a consequence of this rule, it is very common that player characters and non player characters have very different representations and may even utilize "abilities/spells/skills/items" in a different fashion from each other.

The general purpose for representing items and skills/abilities as mutable objects in most games is to provide the players with the opportunity to customize their characters.  This ability to customize however, comes with additional overhead in both memory and processing as more code has to run and analyze more variables (such as adding up all of the +damage modifiers that apply to an attack whether from skills or inventory items.  Yes, you can and likely should cache the calculated value but you still have to invalidate and recalculate the values when circumstances change).

NPCs (in most games) are generally spawned with full knowledge of exactly what their modifiers are and what their "outfit" will be, removing the need to  provide them with inventory or abilities.  There is no need to have the NPC actually have a "sword" item in their inventory in order for the player to see them using a sword.  Nor is it necessary that combat logic process the more extensive types of analysis used for players to determine modifiers to combat.

But Christopher you say, "How do I let the player's loot the sword when they kill the npc?".  Lets start with a rhetorical question, "Will the players always loot everything they kill?" 

We know from observation, that a significant portion of the potential loot generated in any treasure systems is not looted.  Sometimes this happens because of inventory limitations, other times because the player judges the value of the object to not be worthwhile.

Knowing that a large percentage of objects are not looted, does it make sense to waste all of the time/cpu generating persistent items (with the corresponding hit to the database)?  Hopefully we agree, no.

Well, then how do we do treasure/loot? 

Until the player actually chooses to loot an object, there is no reason to create the full persistent representation of it at all.  Instead you would create a system that knows how to create proxy non-persistent "loot objects" that know how to create (probably through the spec system) the real item if/when the player loots it.  In fact, until the non player character is killed there is no reason to waste any CPU time figuring out what loot it might have at all.

A proxy loot object then encompasses all kinds of logic that conceptually are not part of the items themselves, such as restrictions on who can loot it.  All of this means, you end up with lots of systems that know how to factory things (often all using the spec system) that work together.

But Christopher you say, "Do I really need all of those spec systems?"  No, you certainly do not. 

A simpler system might implement all of that logic in specific scripts used by npcs of some specific type.  Or perhaps you implement your npcs using custom Entity Component architecture (though in many ways the spec system already supports much of this architecture).

Title: Re: Item System & NPCs
Post by: Triplelexx on Jan 18, 13, 10:35:06 AM

Many thanks for taking the time to explain the implementation in more detail.
I will continue to consider how best to go about writing these other spec implementations.

It seems the best approach, "Do I really need all of those spec systems?" 
Probably more!

Awareness would be something else to look at.... If anyone does want to group up to speed up work on similar implementations for this, I'm all ears.

I'll keep at trying to implement something viable myself as best I can.
Thanks again for the concise reply.