业余程序员如何制作2D平台游戏的控制器
发布时间： 11:32:04
Tags：,,,,
作者：Yoann Pignole
在“业余程序员”系列，我想分享一下作为一名业余程序员的经验。我的分享有两个主要目的：一是证明非专业的程序员也能制作出原型；二是向专业程序员展示设计师是怎么做程序的，也许能得到一些反馈和建议吧！最后，本系列也是对我本人工作的一些反思。这次我先介绍我如何使用Unity为个人项目制作自定义操作器：
为什么使用自定义操作器，而不使用Unity默认的那个？
你可能会问自己：“但为什么不使用Unity自带的角色控制器呢？”事实上，我试过了，至少在一开始的时候。但后来我遇到了一些问题：
1、Unity的默认角色控制器是基于Unity的物理引擎的：如果你想制作一款物理平台游戏（游戏邦注：如《Little Big Planet》、《Trine》等），这也许是个不错的解决方案。然而，我需要一种“敏锐”而准确的操作，像老式2D平台游戏（《马里奥》、《索尼克》、《超级食肉男孩》等）那样的，所以Unity的物理引擎太难调整了。
2、Unity默认的角色操作器是基于胶囊状碰撞器：所以，玩家能够轻易地在斜坡上行走，但当你要做的是朝右移动的平台游戏时，胶囊就会卡在边缘上，这是不可行的：
2d Platformer-01(from gamasutra)
3、最后，当我想到以后的AI寻径，我决定自己做一个控制器：我认为在一般的平台游戏中，使用简单的功能如跑（速度）和跳（高度）可以更容易控制AI在路径上的移动，并结合游戏世界的限制条件（碰撞和重力）。
没什么特别的，关于2D游戏的碰撞有很多网上教程，我采用的方法不过是结合了我看过的东西和我自己的（不成功的）经验。
因为我的原型是一款贴图平台游戏，我本可以使用简单的系统来检查我想移动的贴图是不是墙体。出于若干原因，主要是因为我之前不懂得用这种方法处理斜坡，我选择了更通用的系统，即使用光线投射来检测碰撞。
所以，基本的碰撞概念是非常简单的：控制器以一定的速度值移动，除非这个速度导致它的碰撞器遇到另一个碰撞器。所以，我们只需要检测这些可能的碰撞！
为了检测这些碰撞，正如我前面所说的，我使用光线投射：当有一个速度值时，就有光线会搜索这个速度的方向（X轴和Y轴）的碰撞。如果光线发现碰撞，命中点会确定这个控制器在这个轴上能够达到的最大值。
对于四个方向上的各个光线，伪代码如下：
If speed on x axis & 0
If raycast to the right hits a collision on point (Px,Py)
Set xMaxLimit = Px
取决于控制器碰撞器的大小和贴图的大小，我必须在每一边放两束光线，即一个角一束。但如果你的两束光比你的贴图要大，那么你使用两束光就会遇到如图所示的问题：
2d Platformer-02(from gamasutra)
对一边的光线不止一束的情况，我还必须比较它们的命中点P1和P2，并保留最接近的一个：
Set xMaxLimit = Minimum value between P1x and P2x
最后，我检测控制器的各边是否被阻塞，如果是则速度设为0。如果没有，则控制器将仍然被阻塞，但保持原来的速度值。所以，如果你突然想走另一条路，你必须等到相反的加速度弥补实际速度，最终将速度增加到另一个方向上：它使玩家感觉到“被卡住”。
解决办法相当简单：
If controller position on x axis &= xMaxLimit – 1 (I added a 1 pixel buffer to prevent errors)
Set rightBlocked to true
If rightBlocked is true AND
speed on x axis & 0
Set speed on x axis = 0
我想这是非常简单和传统的办法吧……
重力就是指，当控制器在空中下落时，每一帧，Y轴上的速度会在重力的作用下加上一个均匀加速度：
speed on y axis = speed on y axis + gravity acceleration * delta time
（在这里我就不谈delta time（时间增量）了，因为程序员知道那是什么东西，而非程序员可以很容易在网上找到解释。）
我现在不想在这里详细地解释跳跃系统（因为我想另写一文介绍）。这里的重点是，当跳跃输入被调用时，一个冲击速度会在Y轴上被赋加给控制器，然后重力一步一步地抵销高度，使控制器进入下落状态。
然后我使用相同的系统来确定移动限制和着陆标记：
If raycast to the bottom hits a collision on point (Px,Py)
Set yMinLimit = Px
If controller position on y axis &= yMinLimit + 1
Set grounded to true
If grounded is true AND is not jumping
Set speed on y axis = 0
Apply gravity (see above)
你可以看到上述代码的一些变体：
1、如果底部方向到光线上有速度，则不必检测，因为总是有速度（由持续的重力加速度产生）。
2、相同地，如果着陆，则不必检测。
3、如果控制器正在跳跃，则在设置Y轴上的速度为0以前需要检测：否则，当跳跃冲力被赋到Y轴上的速度时，它直接回到0，因为控制器在下一帧里可能仍然贴着地面。
2d Platformer-03(from gamasutra)
光源的重要性
这不是一个大问题，我认为对专业的程序员来说是小菜一碟。但我自己花了一些时间，我真的想在这里分享一下我是怎么理解它的：
一开始，我的光线是由控制器碰撞器的角产生的。问题是，控制器不能正确地处理右边的碰撞。现在我知道它是一个代码执行顺序的问题，用下图更容易解释：
2d Platformer-04(from gamasutra)
后来我发现了一个解决办法：光线从更远处投射，以产生“缓冲区”：
2d Platformer-05(from gamasutra)
斜坡……当想到碰撞系统时，我总是很怕斜坡。我怕到不得不去寻找“无斜坡”的做法！但是，我最终克服了斜坡障碍！
令人吃惊的是，在我整合基本的碰撞系统后，控制器居然能够应付斜坡了。好吧，虽然处理得不是很漂亮，但至少不会卡在斜坡上了，这极大地鼓励了我。事实上爬坡很好，因为X轴上的极限位置总是“推回”。然而，下坡很成问题，因为当玩家跑得非常快时，他会先在X轴上移动，然后受重力作用在斜坡上下落，这就产生了“弹跳”下坡现象！
另外，在老式2D平台游戏中，玩家碰到斜坡的底部中心。但当我的基本碰撞系统运作时，控制器碰到的是斜坡地面的最接近底部角度的地方。
2d Platformer-06(from gamasutra)
为了让控制器固定在斜坡地面上，我尝试了多种解决办法，从各种教程到自己购买方案，我最终决定使用比较简单的一个。基本上就是：
1、检测控制器是否与斜坡接触
2、如果是，则直接设置Y轴关联到斜坡碰撞的Y轴位置
检测是否与斜坡接触
首先，为了检测控制器是否与斜坡接触，我检测它是否“在斜坡的上方”。为此，当一束底部光线发现碰撞时，我只要检测这个碰撞法向量和右边的单位向量之间的差异：
If raycast to the bottom hits a collision on point (Px,Py)
If angle between collision hit normal vector and right unit vector differs from 90°
set slopeOnHitPoint to true
当两束底部光线之一不能确定控制器是否真的在斜坡的上方时，是因为发生了如下图所示的情况：
2d Platformer-07(from gamasutra)
所以为了确定是否在斜坡之上，以下条件之一必须为真：
1、如果左光线和右光线均检测到斜坡，则控制器在斜坡之上
2、如果只有一束光线检测到斜坡，且作为命中点的斜坡被另一个命中点来得高
然后，为了确定控制器是否在斜坡上，我必须确定它是否接触斜坡或在斜坡的上方。然而，我发现我需要更大的“缓冲区”来防止当控制器在斜坡上时退出它的“着陆”状态。所以，修改法的伪代码是：
If aboveSlope
Set groundCheckValue to yMinLimit + 5
Set groundCheckValue to yMinLimit + 1
If controller position on y axis &= groundCheckValue
Set grounded to true
If grounded is true And is not jumping
Set speed on y axis = 0
If aboveSlope
set onSlope to true
Apply gravity
Set onSlope to false
设置控制器Y位置
既然我已经知道控制器是否在斜坡上了，那么接下我只要确定它的位置就行了。
因为我希望控制器“呆在”斜坡的底部中心，从它的中心投射一束垂直向下的光线，且使用命中Y位置当作新的yMinLimit。
2d Platformer-08(from gamasutra)
然后，为了避免控制器产生弹跳下坡的现象，我抛弃了Y轴速度，直接设置控制器Y位置为yMinLimit（X轴上的速度从未改变）：
If onSlope
Set controller y position to yMinLimit
Set controller y position to actual y position * y speed * deltaTime
Set x position to actual x position * x speed * deltaTime
当所有这些棘手的小问题都似乎解决了，我又遇到一个新问题：顶点！事实上，当达到顶点时，控制器就被认为位于斜坡上，它继续用来自中心的光线确定yMinLimit。所以，只要这个中心超过顶点，控制器就会产生碰撞，yMinLimit如下图所示：
2d Platformer-09(from gamasutra)
作为开发者，我必须承认当时我不知道我是否希望我的游戏中出现这种碰撞……但我不想因为自己不能处理它们就回避它们！
事实上，我没有找到这个问题的清楚解决办法，但我所选择的做法似乎也蛮管用的……
首先，我检测控制器是否在斜坡的上方，也就是顶点在左边：左光线是否检测到斜坡，且介于左命中点与中心命中点之间的距离是否大于5（任意值，取决于对贴图大小、控制器碰撞器的大小的测试）。
最后，如果控制高于顶点，我就使用其他边的光线命中点来确定yMinLimit。
2d Platformer-10(from gamasutra)
这个办法并不完美，因为中心光线和边光线之间没有过渡，不能很精准地确定yMinLimit，且它产生一个有点儿怪异的切换。但我仍然希望有一天能找到更稳妥的解决办法。
总之，在自己处理碰撞问题上，我确实遇到很严峻的考验；但结果满足了我的要求。如果某些程序员看到本文能给我一些反馈，我会很高兴的。我还要问自己是否有更复杂的、处理其他类几何形状的碰撞系统也使用了类似方法？如果你知道，就请满足我的好奇心吧！感谢阅读，敬请期待“业余程序员”系列的下一篇文章！（本文为游戏邦/编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）
The hobbyist coder #1: 2D platformer controller
by Yoann Pignole
Hi everybody! With this “hobbyist coder” series, I want to share my experience as a…well…hobbyist coder. This sharing has two main goals: showing to non professional programmers making prototypes is not inaccessible and showing to professional programmers the way a designer takes on programming, and maybe have some feedbacks/advices about perfectible parts! Finally, it’s some kind of personal post-mortems… So, let’s start with the custom 2D platformer controller I made in Unity for a personal project:
Why using a custom controller and not the Unity’s default one?
You may ask yourself “but why not using the unity character controller from Unity?” Actually, I did. At least, at start! Then, I encountered some problems:
The Unity’s default character controller is based on the Unity’s physics engine: it’s probably a good solution if you want a physics-based platformer feeling (like Little Big Planet, Trine, etc.). However, I wanted a “sharp” and precise control, like old school 2D platformers (mario, sonic, meat boy, etc.), so the physics engine way turned out to be very difficult to tweak in this way.
The Unity’s default character controller is based on a capsule shape collider : so, the player is able to walk on slopes easily but, when you have to handle platforms with right-angled edges, the capsule gets stuck on the edges and it’s just unacceptable:
Finally, I decided to do my own controller when thinking about future IA pathfinding : I think it will be much easier to control the IA moves along the path with simple function like Run(speed) and Jump(height) on a generic platformer controller, dealing itself with the world constraints (collisions and gravity).
Basic principle
Nothing extraordinary here, there is a lot of tutorials about collisions on 2D games on the internet and the way I took is just a mix among different things I read and some of my own (unsuccessful) experiences.
As my prototype is a tile-based platformer, I could have used a simple system to check if the tile I want to move on is a wall or not. For several reasons, mainly because I previously had difficulties to handle slopes with this kind of approach, I chose a more versatile system, using raycasting to detect collision.
So, a basic collision concept is very simple: the controller moves with… a speed value, except if this speed brings its collider into another collider. So, we just need to detect these potential collisions !
To detect the collisions, as I said above, I use a raycast: when there is a speed value, some rays search for a collision in the direction of this speed, for each axis x and y. If the ray hits some collision, the hit point will define the maximum value the controller will be able to reach on the axis.
In pseudocode, it looks like this for each ray of the four directions:
If speed on x axis & 0
If raycast to the right hits a collision on point (Px,Py)
Set xMaxLimit = Px
Depending of the size of my controller collider and the size of my tiles, I had to cast only two rays per side, for each corner. But if one of your two is bigger than your tiles size, you may encounter some issues with only two rays:
With more than one ray per side, I also have to compare their hit points P1 and P2 and keep the closest one:
Set xMaxLimit = Minimum value between P1x and P2x
Finally I check if the controller is blocked on each side to set the speed value to 0 in case of. If not, the controller will still be blocked but will keep a speed value against the wall. So, if you want to suddenly go the other way, you have to wait the opposite acceleration compensate the actual speed to finally increase speed in the other direction: it results a “stuck” feeling for the player.
The solution was pretty simple:
If controller position on x axis &= xMaxLimit – 1 (I added a 1 pixel buffer to prevent errors)
Set rightBlocked to true
If rightBlocked is true AND
speed on x axis & 0
Set speed on x axis = 0
So, very simple and traditional way I guess…
Let’s bring Newton!
Gravity is just a constant acceleration applied on speed on y axis each frame when in the air :
speed on y axis = speed on y axis + gravity acceleration * delta time
(I won’t talk about delta time here, as coders now exactly what it is and non-coders can find much better explanation on the internet, for example here : http://alexreidy.me/game-programming-an-explanation-of-delta-time/ )
I won’t explain the jump system I chose in details now (maybe another post…). The important thing here is that when a jump input is called, an impulsion speed is applied on the controller on y axis and then the gravity makes its job to step-by-step compensate the elevation and bring back the controller to a fall state.
Then I used the same system as above to determinate move limits and grounded flag:
If raycast to the bottom hits a collision on point (Px,Py)
Set yMinLimit = Px
If controller position on y axis &= yMinLimit + 1
Set grounded to true
If grounded is true AND is not jumping
Set speed on y axis = 0
Apply gravity (see above)
You can see some variations with the previous code:
No need to check if there’s a speed in the bottom direction to raycast as there is always one (generated by the continuous gravity acceleration).
The same way, no need to check it when grounded.
I thought a new check if the controller is jumping was needed before set speed on y axis to 0: if not, when the jump impulsion is applied on y speed, it directly returns to 0 as the controller will be probably still considerate grounded at the next frame.
The importance of rays origins
It’s not a big problem and I guess not very hard to solve for a professional coder. But I took some time for me to and I really want to share the hard time I had to understand it
At start, my rays were generated from the exact corners of the controller collider. The problem is the controller was not able to handle correctly right-edged collisions. Now I understand it’s a question of code execution order that is much easier to explain with a little scheme:
So I found a solution casting rays from further to have a “buffer”:
The slopes problem
Slopes… it always frightens me when thinking about a collision system. It frightened me enough to really considerate the “no slopes” options! But, let’s see how I did to finally handle them!
Surprisingly, after I integrated the basic collision system, the controller was able to take slopes. Ok, really roughly, but it wasn’t stuck on them and it was encouraging for me
Actually, the climbing of slopes was pretty good, as the limit position on x axis was always “pushed back”. However, the descent was problematic because when the player was running very fast, he moved on x axis just before falling on the slope with gravity, resulting in a “bouncing” descent!
In addition, on old school 2D platform games, the player touches the slope ground with its bottom center. But when my collision basic system does the job, the controller touches the slope ground with the closest bottom corner.
After trying a lot of solution to keep the controller on the ground on slopes, from different tutorial or by my own, I finally decided to use a simple one. Basically:
Detect when controller is grounded on a slope
If it is, directly set the y position relating to the y position of the slope collision
Detect if grounded on slope
First, to detect if the controller is grounded on a slope, I detect if it is “above a slope”. To do that, when one bottom rays hit a collision, I just check the difference between this collision normal vector and a unit vector to the right:
If raycast to the bottom hits a collision on point (Px,Py)
If angle between collision hit normal vector and right unit vector differs from 90°
set slopeOnHitPoint to true
Only one of the two bottom rays can’t determinates if the controller is really above the slope because of this case:
So to determinate if above a slope, one of the following conditions must be true:
If there a slope detected with the left AND the right ray, the controller is above a slope.
If there a slope detected only with one ray AND the hit point were the slope is detected is higher than the other hit point
Then, to determinates if the controller is ON the slope, I just have to determinates if it is grounded AND above a slope. However, I found that I need a bigger “buffer” to prevent the controller to exit its “grounded” state when on a slope. So, the modifications in pseudo-code:
If aboveSlope
Set groundCheckValue to yMinLimit + 5
Set groundCheckValue to yMinLimit + 1
If controller position on y axis &= groundCheckValue
Set grounded to true
If grounded is true And is not jumping
Set speed on y axis = 0
If aboveSlope
set onSlope to true
Apply gravity
Set onSlope to false
Set the controller y position
Now I know if the controller is on a slope or not. I just have to determinate its position.
As I want the controller to “stay” on slope on its bottom center, I cast a vertical down ray from its center and use the hit y position as the new yMinLimit.
Then, to avoid the controller to make bounces descending the slopes, I discard the classic speed application on y axis and directly set the controller y position to the yMinLimit (the speed application on x axis never changes):
If onSlope
Set controller y position to yMinLimit
Set controller y position to actual y position * y speed * deltaTime
Set x position to actual x position * x speed * deltaTime
And now the peaks problem!!!
As soon as all these tricky stuff seemed to work, I encountered a new problem: the *$@! peaks!! The fact is, as the controller is considerate on a slope when on a peak, it continues to define the yMinLimit with the ray from the center. So, as soon as the center goes over the peak, the controller goes through the collision as the yMinLimit is defined below:
As a designer, I have to admit that I didn’t know at this time if I wanted to have such collisions in my game… But I didn’t want to refuse them just because I wasn’t able to handle them!
Actually, I didn’t found a clean solution to handle this case, but the one I chose doesn’t work so bad…
First, I check if my controller is above a peak which means, for a peak on the left: if slope detected with left ray AND distance between left hit point and center hit point & 5 (arbitrary value determinate with tests depends of tiles size, controller collider size, etc…).
Finally, if the controller is above a peak, I use the other side ray hit point to define the yMinLimit.
It’s not perfect because there’s no transition between the center ray and the side ray to determinate the yMinLimit and it results a little strange shift. But I haven’t lost hope in finding a cleaner solution someday!
Conclusion
In conclusion that was a really cool challenge for me to handle collisions myself and the result works pretty good for what I wanted to do. If some coders read this, I would be glad to have some feedbacks about this solution. I’m also asking myself if more complex systems of collisions with physics engines, working with different kind of geometrical shapes, are using similar approaches ? If you have some answers or reading about that, feel free to share and satisfy my curiosity ! Thanks for your reading and maybe see you later for another episode of the “hobbyist coder”!(source:)
CopyRight Since 2010 GamerBoom All rights reserved &&闽ICP备&号-12D格斗游戏制作工具教程_百度知道
2D格斗游戏制作工具教程
急求 2D格斗游戏制作工具教程啊``自己不懂``我已经初步了解了`就是不懂怎样做到会动的
会做的高手们+QQ 谢谢!!
我来帮他解答
其他类似问题
2d格斗的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁查看: 10770|回复: 133
交易诚信度0 最后登录注册时间阅读权限70UID5632帖子狩魂0 在线时间900 小时
猥然不动 Lv.7, 积分 5887, 距离下一级还需 4113 积分
UID5632积分5887帖子精华0浮云1132 猥币18476 汽油0
本帖最后由 crossztc 于
15:36 编辑
看了网友クルル的帖子后，我对这个两个软件很感兴趣，
于是研究使用了一下，发现操作很简单，效果却很不错！所以为了方便使用，自己汉化了一下软件！
（其中【单图景深调整工具_seeneon】为完全汉化，【MPO文件生成工具_stphmkre】只汉化了生成MPO文件所需的部分）
软件需要net framework 3.5支持，如果运行不了请下载net framework 3.5或更高版本
详细教程请看クルル的帖子：
汉化人员：
【汉化：CROSSZTC】【感谢：クルル】
软件预览：
05:26 上传
软件下载：
(976.56 KB, 下载次数: 4055)
04:56 上传
下载次数: 4055
汉化版.part1.rar
(661.29 KB, 下载次数: 2212)
04:56 上传
下载次数: 2212
汉化版.part2.rar
這實用又給力!!
总评分:&浮云 + 2&
交易诚信度0 最后登录注册时间阅读权限40UID5189068帖子狩魂0 在线时间397 小时
猥服出巡 Lv.4, 积分 954, 距离下一级还需 46 积分
UID5189068积分954帖子精华0浮云93 猥币2632 汽油0
交易诚信度0 最后登录注册时间阅读权限30UID帖子狩魂0 在线时间46 小时
猥乎其微 Lv.3, 积分 224, 距离下一级还需 276 积分
UID积分224帖子精华0浮云6 猥币676 汽油0
交易诚信度0 最后登录注册时间阅读权限140UID99帖子狩魂0 在线时间2086 小时
UID99积分41218帖子精华1浮云4597 猥币165396 汽油0
竟然是付费的。。好吧
交易诚信度0 最后登录注册时间阅读权限60UID2092007帖子狩魂0 在线时间1952 小时
猥人师表 Lv.6, 积分 4568, 距离下一级还需 432 积分
UID2092007积分4568帖子精华0浮云178 猥币14853 汽油0
似乎是不错的东西啊
wii FC： 97 6154
金心FC：09
口袋白FC：58
交易诚信度0 最后登录注册时间阅读权限80UID576467帖子狩魂0 在线时间729 小时
猥风八面 Lv.8, 积分 17480, 距离下一级还需 12520 积分
UID576467积分17480帖子精华0浮云588 猥币75548 汽油0
交易诚信度0 最后登录注册时间阅读权限50UID940439帖子狩魂0 在线时间786 小时
猥言大义 Lv.5, 积分 1600, 距离下一级还需 400 积分
UID940439积分1600帖子精华0浮云55 猥币4415 汽油0
顶，制作出来是不是伪的？
机核网3DS专区
http://www./thread.php?fid=57
交易诚信度0 最后登录注册时间阅读权限120UID1570帖子狩魂0 在线时间4166 小时
UID1570积分15303帖子精华0浮云6445 猥币14365 汽油175
交易诚信度0 最后登录注册时间阅读权限0UID51241帖子狩魂0 在线时间1031 小时
头像被屏蔽
UID51241积分3794帖子精华0浮云39 猥币15827 汽油0
提示: 作者被禁止或删除 内容自动屏蔽
交易诚信度0 最后登录注册时间阅读权限70UID405807帖子狩魂0 在线时间868 小时
猥然不动 Lv.7, 积分 5540, 距离下一级还需 4460 积分
UID405807积分5540帖子精华0浮云129 猥币20716 汽油0
这个粉给力的说
豪血寺一族QQ群 2524923
游聚X-ZONE对战平台QQ群
双截龙格斗QQ 群
交易诚信度0 最后登录注册时间阅读权限50UID帖子狩魂0 在线时间50 小时
猥言大义 Lv.5, 积分 1298, 距离下一级还需 702 积分
UID积分1298帖子精华0浮云21 猥币5082 汽油0
這個要頂~~~
Ayase Haruka
交易诚信度0 最后登录注册时间阅读权限0UID24840帖子狩魂0 在线时间158 小时
头像被屏蔽
UID24840积分264帖子精华0浮云9 猥币2246 汽油0
提示: 作者被禁止或删除 内容自动屏蔽
签名被屏蔽
交易诚信度0 最后登录注册时间阅读权限30UID1925620帖子狩魂0 在线时间24 小时
猥乎其微 Lv.3, 积分 456, 距离下一级还需 44 积分
UID1925620积分456帖子精华0浮云20 猥币2014 汽油0
好东西，要下来耍耍
什么都没有
交易诚信度0 最后登录注册时间阅读权限1UID133846帖子狩魂0 在线时间2 小时
UID133846积分6帖子精华0浮云0 猥币1607 汽油0
收费的不知道功能如何呵呵
交易诚信度0 最后登录注册时间阅读权限80UID30903帖子狩魂0 在线时间2019 小时
探究口袋妖怪世界起源的学者
猥风八面 Lv.8, 积分 12978, 距离下一级还需 17022 积分
UID30903积分12978帖子精华0浮云351 猥币44507 汽油0
什麽東西？
還是慢慢玩PMXY吧……
84（Platinum）
89（HeartGold[漢化版]）
56（Black）
67（Black2）
91（White）
64（White2）
97（αSapphire&X—3DS[水晶藍]）
32（ΩRuby&Y—3DS[火焰紅]）
全主机制霸之环【光辉事迹】
首先我要感谢我的把拔马嘛，还要感谢各种TV，感谢@#%&*…让我拥有现世代所有的游戏机。（PSP、PSV、NDS、3DS、PS3、XBOX360、WII、WII U、PS4、XBOX ONE）
正版党【光辉事迹】
不是咱要晒正版，实在是游戏太好玩(自曝拥有任意平台10款以上的正版游戏)
论坛贵宾【光辉事迹】
曾为论坛做出过杰出贡献的版主、会员所持有的徽章。象征丰硕成果的华美之证。(获得“论坛贵宾”头衔)
精英手环【普通成就】
维护世界和平，拯救BUS精华区的重任就交给你了，好吗(累计发表1篇精华帖子)
展会先锋【普通成就】
每当有游戏展会，我都有很多事情要做，根本停不下来！（参与任何游戏展会报道直播及其他相关内容制作）
学院之心【稀有成就】
学院里的精英，任区里的好榜样，就是你了！（任天堂学院优秀组员成就）
S·P·Y【稀有成就】
呵呵想揭下我的面具看看我的真实身份吗？知道的人都死光了哦……(同时列名于3个以上用户组)
水元素【普通成就】
水、H2O、みず、water，额...总之怎么叫都行了
(累计发帖1000即可解锁)
水精灵【稀有成就】
我很喜欢水，因为这就是我存在的意义...(累计发帖10000即可解锁)
浮云爱好者【普通成就】
一朵，两朵，三朵，呵呵呵… (累计获得1000朵浮云)
浮云收藏家【稀有成就】
已经收藏到这么多浮云了吗，不错嘛！(累计获得5000朵浮云)
常客【普通成就】
《我的业余生活》从前有一个论坛叫TGBUS…(在线时间超过1000小时)
我的朋友很多【普通成就】
朋友不只是踏脚石,偶尔也可以当坐垫的哦(好友数超过100名)
与猥皮共成长【史诗成就】
日…值得纪念 (注册时间显示于日)
成就猎人Rank.D【普通成就】
你已经踏上了成就收集的不归路，5个成就怎么可能满足你的需求，继续努力吧！ (获得累计超过5个成就--不包括负面成就)
成就猎人Rank.C【稀有成就】
随便玩玩就拿到这么多了，SO EASY，妈妈再也不用担心我的成就 (获得累计超过10个成就--不包括负面成就)
光辉守护者【光辉事迹】
你的意志，再一次击败了罪恶之源-迪亚布罗。(时限:日前于【暗黑破坏神3】游戏角色达到60等级)
Powered by