引言：
这篇文章为本人Blog中的一篇Post，因排版原因，就不贴全部内容了，只贴出概述部分。
Q：为什么访问速度这么慢？
A：因为访问速度就是慢=_=||洛杉矶的机房呢=_=||
A：Blog系统自动生成的=_=||本人看着这个URL还可以就没改=_=||
概述：
我们假设需要做一个传送命令（这里就姑且叫做TryTeleport吧），我们想要什么呢？
- 输入/tryteleport notch 64 128 64
将把玩家notch传送到坐标为（64，128，64）的位置 - 输入/tryteleport 64 128 64
将把自己传送到坐标为（64，128，64）的位置 - 输入/tryteleport DIM-1 64 128 64
将把自己传送到坐标为（64，128，64）的下界位置 - 输入/tryteleport notch 64 128 64 0 0
将把玩家notch传送到坐标为（64，128，64）的位置，
同时后两个参数决定了传送时的姿态坐标（Yaw和Pitch） - 输入/tryteleport notch ~ ~ ~
将把玩家notch传送到自己所在的位置 - 输入/tryteleport @a ~ ~ ~
将把所有玩家传送到自己所在的位置
需求其实挺复杂，但是还不止这些：
- 如果试图传送自己的是服务端控制台，那么将出错
- 如果试图在位置坐标处输入一些不合法的字符串，那么也会出错
- 如果试图传送的玩家不在线，那么将出错
还有呢：
- 输入/tryteleport后，按下Tab键会自动轮流弹出世界中所有玩家的名字
还有一项需求：
- 输入/help tryteleport后，会得到相关的参数信息，这里我希望它是：
Usage: /tryteleport [<source>] <location> [<yaw> <pitch>]
所以说，定义一个命令，主要定义的就是这四部分：功能、错误处理、自动补全、以及帮助信息。
实际上我们可以注意到，很多情况下处理命令的行为都类似，比方说输入玩家：
- 处理一个字符串作为玩家名称
- 若字符串对应的玩家不在线则出错
- 在按下Tab时自动从世界寻找已有玩家并轮流返回其名称
- 输出的帮助信息中，玩家参数的相应位置应输出<player>
在软件工程中，遇到重复的代码就需要想想如何合并，开发Sponge插件亦是如此。而（至少据我所知）Bukkit插件没有提供行之有效的手段，所以开发者就需要一遍一遍地写重复的处理命令的代码，如果涉及到选择器等情况问题还会变得更加复杂。Sponge（至少目前看来）很好地解决了这一问题。
本篇Post的内容就是简要介绍Sponge插件的命令系统。
正文内容：
http://blog.ustc-zzzz.net/sponge-plugin-command-system-brief-introduction/
[groupid=534]InfinityStudio[/groupid]