基于 Java 的 I Don’t Wanna Be The Bugger 冒险游戏

一、课程设计项目简单描述

在美国早期游戏业比较宁静的时代，I Wanna Be The Guy 作为一款难度较高的冒险类游戏，在当年很多人玩过。玩家将体验一个年轻、懵懂的孩子为了追寻理想中的角色所经历的过程。变幻莫测的完美剧情只是这项无限创意中的一部分，令人沮丧的跳跃和射击的挑战会使你对这个主角小孩产生敬意。

I Wanna 出名后，一些地方开始举行 I Wanna 大会，并利用 GM8 和 MMF2 等工具制作 I Wanna。这些可在百度 I_wanna_be_the_guy 吧或日本的 wiki 或维基百科 I Wanna 专题上找到并下载。除此之外，在 PIXIV 上也有 I Wanna 相关的作品。

该课程设计项目属于 I Wanna Be The Guy 游戏同人作品，构建了人物、关卡、关卡元素等模型；获取了相应的素材图片与音乐，丰富了游戏的内容；实现了基本的人物移动跳跃死亡，关卡和各种多种机关的创建，关卡切换和重开，存档等多种功能。基于 Java 语言封装使关卡的布局更加方便，精心设计了四个关卡使游戏更加具有乐趣。

二、需求分析

三、系统设计

1.碰撞检测算法

该算法为较为重要的算法，所有的关卡元素以及人物都继承自 Thing 类，judgeCrash 方法通过判断传入两个类的图片是否重叠进而返回是否碰撞。

矩形重叠判断公式

X 轴：[（x1+w1/2）-（x2+w2/2）]<（w1+w2）/2

Y 轴：[（y1+h1/2）-（y2+h2/2）]<（h1+h2）/2

当判断公式返回真值时说明矩形重叠。

2.GameComponent 类

1）Timer 类和 ActionListener 接口

通过 ActionListener 监听器和 Timer 结合定时调用 Kid 类的 run 方法和 Level 类中的 scan 方法，使画面每隔固定的一段时间改变并调用 repaint 刷新画面显示从而达到动效。

2）KeyListener 接口

使用 KeyListenr 对键盘输入监听，并对相应键的 KeyPress 调用 Kid 或者 Level 的方法对其的状态进行改变。

3）窗体的绘制

GameComponent 继承于 JComponent 重写了 paintComponent 方法，调用 Kid 类和 Level 类的 draw 方法绘制出当前的画面。

4）重新游戏

当监听到键盘键入‘R’或‘r’时调用 restart 方法，进而调用 Kid 对象的 reset 和 Level 的 reset 重置关卡。

3.Level 类

1）Level类的数据域

2）关卡的设置与重置

Level 中的 reset 具有关卡设置与重置的功能，将对应关卡的元素载入对应的 ArrayList 中，在 draw 类被调用时会根据载入的元素的坐标和贴图绘制出所有载入的元素，从而形成关卡，重置亦是如此。

3）关卡元素的检测和动态变化

Scan 方法会对所有的关卡元素进行扫描，如果满足触发条件，则调用关卡元素的触发内容。还可以定义关卡进行时的动态变化（触发后某个机关才会出现的某个机关需要在这里设置）。

4.Kid 类

1）Kid 类中的数据域

2）Kid 类状态的改变

通过 jump，walk，fall，idle，die 方法，使 Kid 对象进入某种状态，并改变 Kid 对象的数据域。

3）Kid 类的坐标根据状态的改变

人物根据坐标数据定位，在 run 方法中定义了当 Kid 处于某种状态时，实际的坐标根据随之改变。由于 GameComponent 的定时调用，从而达到人物状态改变的效果。

4）Kid 类的绘画

Draw 方法根据人物当前的状态载入对应的图片，并显示在窗体上。

5）Kid 的重置

当 Kid 经过死亡状态后，触发重开游戏后调用 reset 方法将 Kid 设置为初始状态。

6）Blood 类

在 Kid 进入死亡状态时，将人物死亡坐标传入 Blood 类，初始化 500 个血液坐标，并使用随机数方法随机出 500 个横纵轴速度，使 500 个血液坐标改变，最后调用绘制在屏幕上。

5.Platform，Trap，Judge，Save 类

（四类具有大部分相似的数据域与方法，以 Platform 为例分析）

1）Platform 类的数据域

2）Platform 类的站立与阻挡

judgeKidCrash 方法通过对 Kid 对象和 Platform 对象当前坐标进行一系列碰撞的判定，并对站立与阻挡两种不同的状态对 Kid 对象内部数据进行改变，从而达到站立和阻挡效果。其余三类均有通过碰撞检测实现的一些功能。

3）Platform 类的移动

Platform 对象在 Level 类中检测是否触发自身判定区域，若已触发判定区域，则调用 move 方法对 Platform 的坐标进行改变。由于 GameLevel 会定时调用 Level 类的检测方法，从而达到移动的效果。

4）Platform 的绘制

Draw 方法根据平台当前的状态载入对应的图片，并显示在窗体上。

6.ImageTool 和 MusicTool

在GameComponent创建时就将图片数据和音乐数据载入内存中，提高读写速度的同时也方便之后的读取。

四、效果及存在问题

1.运行效果

Level 1

Level 2

Level 3

Level 4

Level 5

Level 0(author page)

2.存在的问题

1）碰撞算法精度问题

由于能力暂时的有限，所有的碰撞检测都只采取了矩形检测重叠的方法来判断是否碰撞，导致碰撞判定的精度并不高（会导致还没触碰机关元素到就死亡的现象）。

预期解决方法：引入检测像素碰撞方法，在一些需要精度比较高的地方使用。

2）人物物理引擎的死板

原作的物理引擎可以根据按下键盘时的停留时间对人物跳跃的高度和速度做相应的处理，本作并没有做到比较死板，会造成有时候关卡的设计难度增大（因为需要人物本身是否能够通过）。

预期解决方法：监听键盘按键时间，并对其做出不同的反应。

3）陷阱形式比较单一

只设计了最基本的移动陷阱方法，并没有设计出更多的陷阱方式（虽然已经可以衍生做到很多不同的陷阱效果），游玩过久可能会觉得枯燥。

预期解决方法：多设计一些不同的陷阱类型并应用。

4）关卡放置方面过于底层，不是很好操作

关于关卡的放置还是处于代码层，新设计的关卡都需要重新写进代码里才可以显示，参数过于繁琐，不够方便。

预期解决方法：制作一个具有交互界面的游戏制作器，可以直接生成数据并传入内部程序运行。

五、心得体会

游嘉升：

经过本次课程设计后，在团队协作方面更加知道小组工作时配合的重要性，很多时候小组如果没有配合好会出现不协调的现象。比如某个地方需要另一个成员的某段代码，而另个成员还没写就会导致工程滞留，这是很严重的问题。还有成员之间的沟通需要相互理解，沟通是建立在理解的基础上的，如果互相不理解就容易造成更严重的误会。身为组长还需要做好分工协调的工作，提前将任务明细布置。

在技术层面，更加体会到 MVC 和封装的优越性。根据 MVC 模式构建的代码比较清晰明了，各个模块各司其事，相互使用又互不影响。封装后的代码若是想要修改很快就可以找得到其作用的位置。所以在写代码前需要设计框架，再将其填充。这次课设算是累计了不少有用的经验。

吴旭婷：

最大的体会是分工合作的重要性，这也是和之前所做课设的一大不同。明确的分工能避免不必要的争执和推脱，所以从一开始就需要和队友做好沟通，在做的过程中也需要不断磨合。在合作的时候曾起过小纠纷，让我误以为队友对于我设计的机关不满，好在最后解释清楚，也让我在后面制作的时候参考了更多元素，设计得更好。在这期间我也了解到有些组合在合作方面就做的很差，也没有好好沟通，导致最后心中不满，觉得还不如自己完成就好。相比之下我只想说，队友好给力！！！

♻️ 资源

大小： 17.2MB
➡️ 资源下载：https://download.csdn.net/download/s1t16/87354132