How blocks and items interact should be defined in config files. Bukkit uses YAML, other options are YAST and JSON (please add other nice markup languages to the comments).
The difficult question is what to model. But lets discuss the (conflicting) requirements first:
Easy to understand and modify for moderately competent people
little to no redundancy
makes it difficult to make errors
Offers a simple way to handle rotations (i.e. so that it's not necessary to define every pumpkin interaction 4 times because there are 4 ways to orient a pumpkin)
There are several things that could be modelled, here are some ideas (these are somewhat mutually exclusive):
blocks define what can be done with them and what happens.
Simple and robust (behaviour should always be well defined, even if it could lead to confusing behaviours)
Redundant, all block transitions need to be specified in both directions.
Items define what they do
Easy to understand, since most people will probably look at this from the point of view of an item.
Less redundancy, a slimeball would define which blocks it can turn into which other blocks and that this is a reversible transaction
Complicated if an object has multiple uses
Can lead to conflicts if multiple items define reversible transitions that lead to the same block
Actions (e.g. the torch offers the "attachTorch" action and the pumpkin defines what it will turn into when the attachTorch action gets applied to it.
Robust
Confusing
It might be best to do a combination of the two. For example, slime balls and torches are passive objects, so they could be defined from the perspective of the block they attach to:
mossycobblestone {
is=cobblestone
sides=slimeball
}
jackolantern {
is=pumpkin
front=torch
}
This is enough to define that you can attach slime to a cobblestone or a torch to the front of a pumpkin. Things like pickaxedamage could be a special thing, like this:
crackedstonebrick {
is=stonebrick
sides=PICKAXEDAMAGE
}
And the plugin code specifies what this special PICKAXEDAMAGE thing is.
Also, the block definitions themselves should be in a config file, e.g. (values made up):
pumpkin {
id = 86
data {
0 = { front = 2 }
1 = { front = 3 }
2 = { front = 0 }
3 = { front = 1 }
}
}
// Inheritance might be overkill here, though.
jackolanternt < pumpkin {
id = 91
}
stonebrick {
id = 98
data = 0
}
crackedstonebrick {
id = 98
data = 1
}
mossystonebrick {
id = 98
data = 2
}
This makes it very easy to adapt the plugin to new versions of minecraft.
How blocks and items interact should be defined in config files. Bukkit uses YAML, other options are YAST and JSON (please add other nice markup languages to the comments).
The difficult question is what to model. But lets discuss the (conflicting) requirements first:
There are several things that could be modelled, here are some ideas (these are somewhat mutually exclusive):
blocks define what can be done with them and what happens.
Items define what they do
Actions (e.g. the torch offers the "attachTorch" action and the pumpkin defines what it will turn into when the attachTorch action gets applied to it.
It might be best to do a combination of the two. For example, slime balls and torches are passive objects, so they could be defined from the perspective of the block they attach to: mossycobblestone { is=cobblestone sides=slimeball } jackolantern { is=pumpkin front=torch } This is enough to define that you can attach slime to a cobblestone or a torch to the front of a pumpkin. Things like pickaxedamage could be a special thing, like this: crackedstonebrick { is=stonebrick sides=PICKAXEDAMAGE } And the plugin code specifies what this special PICKAXEDAMAGE thing is.
Also, the block definitions themselves should be in a config file, e.g. (values made up):
pumpkin { id = 86 data { 0 = { front = 2 } 1 = { front = 3 } 2 = { front = 0 } 3 = { front = 1 } } }
// Inheritance might be overkill here, though. jackolanternt < pumpkin { id = 91 }
stonebrick { id = 98 data = 0 } crackedstonebrick { id = 98 data = 1 } mossystonebrick { id = 98 data = 2 }
This makes it very easy to adapt the plugin to new versions of minecraft.
Please contribute your ideas in the comments.