I do this at work all the time, although in my sector it is more usual to refer to the meta-information as a metamodel. Of course the next logical step is to have a metamodel for the metamodel.
Before attempting to answer theagentd's questions let me take a step back. I tend to think of the entity-system as being the logical block of code that seperates the engine-side from the world-building/scripting side. As such I'll typically have a wider notion of "entities" than most programmers and an entity is any potentially scriptable individual thing. So will include things like triggers, delayed events, factions, encounters, etc. etc...i.e. may things that have no visual representation. It may also include things like UI elements...this is game design specific. And an ArchType is something that defines what a specific entity is and what it does. The world-building/scripting side pretty much only cares about the external interfaces that ArchTypes, Entities and the Entity system define. The engine side hardly cares at all about the entity system, which feeds it the information it needs to do it's black magic. Notions like this will be over-engineering for very simple games and should be avoided, but as the complexity increases you mimimzie your risk by have a reasonably well define system that cleanly seperates these three logical systems.
Have a general Item class which contains a Equipable ArchType (I'd call that a component, but whatever =S) which can be null and a Usable ArchType that can also be null to accomplish both?
If you were to go this route (as these types of design decisions are not dicated by the model I'm describing) it still wouldn't be component-based. There's no dynamic look-up and the type is of a concrete supertype. Personally this isn't a direction I'd head in. Also for these types of pseudo-mixins I'd tend to avoid nulls. I'd have composed elements directed to sinks which either do-nothing if legal or do-nothing and log an error if illegal. OR high-order logic handles depending on what exactly where talking about. My view is that scripting/world-building side should be as fault tolerant as possible and the game should (hopefully) continue to be playble even though some scripting portions are currently broken.
The overall goal is to lower complexity. Make scripting and world-build as easy as possible and spend as little time tinkering with the entity system itself and get onto actually creating a working (and hopefully fun) game.
I way I've always used this model in the context of entity-systems is a single ArchType instance uniquely describes an indiviual game thing.
I didn't really like it though, since in the end I might want an equipable item which also has a use effect (a throwing axe, for a concrete example), or a reusable item. It seems like this method suffers from the same problems as hierarchy based ones, so how would I solve such a problem?
I'm not sure that I'm understanding you here. Let me try to anwser your question. The game design tells you what kind of events you need to handle. For some uber-RPG-thing a partial list (off the top of my head) for items:
Give away item
Add to inventory
Remove from inventory
Equip item in slot
Unequip item from slot
Use item (For consumables/single kind of usage items...but not nessisarly consumed on usage)
Active item (for other things..aka...it can be 'used' in multiple ways.
Item hits something
Item gets hit by something
Spawn this ArchType
The exact list of events and whom is responsible for dealing with them is game-design specific. And note that game-design specific includes not only the things that various "kinds" of archtypes need to handle...but equally how the process of world-building and scripting is going to be performed. World-building app vs. text-based (XML, JSON, whatever) plays a role. Scripting in Java? some DSL? Some other JVM language? Basic hard-coded lego blocks? Some combination of the previous? This plays a role as well.
Let's take the first two "receive item" and "give away item". It seems highly unlikely that these are something that each-and-every item should be able to handle as it seems like something that would be very uncommon. And the base entites and archtypes should only deal with thing that are common amoung their specific kind. Uncommon and exceptional things should be handled in a separate way. Since I've only scratched the surface of some the various possible abstraction models that can be combined...this isn't obvious yet. One thing that might come to mind about "give away item" is the if game design doesn't allow the player to give away a quest item. Have the item archtype have a isQuest flag and disallow in higher order logical...manually setting an OnAquireItem handler for each quest item would be a PITA (more work than clicking a check-box). Of course all quest items could come from a common template to solve this problem. It's a design decision. I'd not have any archtype kind respond to an event I deemed to be uncommon as it would be simple to reverse my decision and add them in at a later point if I desired. Now it might be interesting to allow responses to these two events, but associate them with the "module" or "player" for instance...which could examine the item and determine if it needs to do something special...in the case that a player is the giver or reciever. What about some placeable thing getting or losing a specific item? Ah..I'd have placeable things respond to the two inventory change events for instance to handle this situation.
"Item hits something" & "Item gets hit by something": Say for magic weapons & armour. I'd pass. Allow items to have list of attached properties. These property specify what the do and when they do it. Higher order logic deals with applying these effects to the appropraite entity at the correct time.
OK. Do these examples help?
Maybe some items can stack in one inventory slot? I can think of solutions...
Add and remove from inventory events OR stackable items are handled by higher order logic. For example an item ArchType could specific a maxStack value and could be handled at a higher level than events...game design specific.
I have to say that this is interesting, but the last example isn't terrible clear to me. I also look forward to responses to theagentd's post.
I have a tendency to minimize my write-ups. It's a combination of assuming that my attempted descriptions are clear and that extending the notion is obvious along with the pragmatic thought that if anyone doesn't understand and need clairifcation then they will ask. Likewise I've have a tendency to ignore low-complexity situations for similar reasons.
So people ask questions if something isn't clear.