More on actions.
function example:PrimaryAction() end function example:DefaultPrimaryAction() end function example:GearPrimaryAction() end function example:RangedPrimaryAction() end function example:HitPlayer() end function example:HitCharacter() end function example:HitScriptedObject() end function example:Throw() end function example:SecondaryAction() end function example:OnObjectSecondaryAction() end function example:AffectMaterial() end function example:AffectObject() end function example:Interact() end function example:Use() end function example:Bounce() end function example:Consume() end function example:ProduceDrops() end function example:PlaceObject() end
Part of this was me looking up what functions I could use for porting Portal Stones in the advent of the loot system. I ended up feeling a bit bemused and so decided to looked at the problem from a designers perspective instead.
So the initial question is, why so many functions? I mean, could you more or less boil them all down to:
I have two thoughts towards this why question.
function example:Action() end function example:Reaction() end
The first is that this is a by-product of building on old code, of which I'm not going to deny that there's definitely an argument for re-using code. At this point however I'd argue it looks more like something that should be refactored.
The second is minecraft. How so? Well there's this interesting thing that happens in MC where after punching a block, it drops into the players hand. Well... it looks like the block is in the players hand but actually as far as MC is concerned, nothing has changed and you can keep punching away at other blocks as normal. Interesting right? Holding blocks doesn't change the players actions. What a kicker, because as soon as the player holds a tool, boom, actions change. I think this is a problem and TUG is in the same boat; Holding voxels doesn't change actions but tools do.
Just to be clear about that, I'm imagining the left mouse button as being responsible for executing all actions an object may execute on another object(s). This builds the case for just this type of action to be assignment to this button.
But what's the real question here?
How do we define actions.
I'm of the opinion that one type of action is like a conversation. First, an object defines its action(s) and/or reaction(s). Then, that object may execute it's action on another object. The other object then reacts to that action. Part of the other objects reaction may be to execute it's action(s). Lastly, if the other object took any actions, the initial objects subsequent actions may change.
To make that more concrete: Let say we've got a player looking at some dirt with empty hands. Let's say we've also got a mod such that a dirt voxel's reaction to a player with empty hands is to be picked up into the players hand. The player executes their empty hand action on the voxel. The voxel's reaction to the players action starts up it's action to put itself into the players hand. The players reaction to the voxels "put me into your hands" action is successful. Now the player's action changes because of the voxel in it's hands.
Programmer, designer, artist.