Java Reference
In-Depth Information
The arrows show where I've added the
squidpurge
command. I get a list of all
squid in your world with
me.getWorld().getEntityLivingList()
and then traverse the
list with an iterator. For each squid, depending on the setting in the config
file, I can then decide whether to set it on fire, like this:
victim.setFireTicks(600);
or just kill it by setting its health to zero suddenly:
victim.setHealth(0.0f);
So with just a humble
if
statement and a config file, you can have your plugin
users tune your plugin's behavior without modifying the source code. Sweet.
Store Game Data in a Database
That's great for configuration data, but not so useful for game data—data
that changes as the game plays on, like player scores and status, inventory,
health, and things like that. We need to access data a little differently, and
be able to write game data from the plugin as well as read it.
There is one important limitation to storage approaches, however. You can
only save and load simple types: strings, integers, floating point, and boolean
values. You can't save Minecraft-specific objects—things like
Location
or
Player
.
You can save a player's name as a
String
, and save a
Location
as a set of
double
x-, y-, and z-coordinates, but you can't save the Minecraft objects directly.
That turns out to be a reasonable limitation, because you really
should not
store
Player
objects, worlds, locations, or other “live” game elements.
Keep in mind that the game is still playing in real time. Players log off, they
change locations, blocks change types, and things catch on fire, fall, and go
in and out of inventory, all while your code is running. If you store a
Player
object on disk, or even in a list in memory, there's no guarantee that object
will still be valid when you go to use it the next day or next week. In fact,
odds are it probably
won't
be valid. All a player needs to do is disconnect and
reconnect, and
bam
—the old
Player
object is no longer valid.
So instead of storing a
Player
object, you store the player's name. When you
load the data back in and are ready to use it, you'd check to make sure the
player is actually online.
Now there are two ways to go about saving and loading game data using
Canary. One is to use a full-fledged SQL database like SQLite or MySQL,
using the SQL language to search for and store data. But that's a lot more
complicated than we have space to cover here. If you're dealing with thousands
