c语言遍历文件内容_2019级C语言大作业 - 冷冻双侠

分享19级同学大一上学期用C语言实现的冷冻双侠，可从码云下载：

https://gitee.com/xingguiweichen/frozen_couple​gitee.com

C语言大作业 - 冷冻双侠https://www.zhihu.com/video/1212808014962577408

一、 游戏介绍

程序为C语言实现的简单的冷冻双侠游戏，游戏图片音乐等素材均来源于4399冷冻双侠游戏，主要内容为玩家控制角色使游戏中所有可冰冻物体冰冻，玩家可以通过跳跃，爬梯，甚至冰冻怪物等手段完成目标。

二、 实现步骤

1、图片和音乐素材获取

虽然游戏素材并非从一开始就大量使用，但充足的游戏素材可以免于开发时面临缺少素材的尴尬境地，所以素材的提取和使用尤为重要，本程序所用素材均来自于原游戏，使用录音和截屏的手段获取，并进行对之处理。

由于部分图片中游戏元素的颜色和背景颜色相似，对图片处理要求大，只能慢慢地对单像素处理，但图片素材较多，所以处理较慢，项目开始时间迟。

2、游戏界面绘制

由于本程序为原游戏在一定程度上的复刻，所以要求游戏界面贴近原游戏。主要问题在于背景中向左下移动的雪花的处理，文件读取通关记录后素材的放置和鼠标选择关卡的判断。

由于鼠标操作涉及音乐音效的开关，所以只是写好了判断的语句，省略了需要执行的语句。

3、处理玩家操作

即使玩家操作简单，只有四个键位，但操作的判断却是难点，爬梯子是否到达终点，跳跃后落地判断，以及冰冻的操作等等。

3.1、移动

玩家移动最快需要一定的时间，同时停下来也需要一段时间，于是加入速度变量，使玩家改变的是速度，而不是直接的位置。

3.2、爬梯

爬梯实现难点在于判断状态改变，包括玩家使用上键时梯子和玩家位置的判断和玩家是否离开梯子的判断。为了防止玩家中途离开梯子，出于便于判断的目的，存储了当前梯子的横向坐标，为了防止对玩家停止爬梯的误判，结合停止时当前位置和下面位置不会同时有梯子，加入防误判判定。

3.3、跳跃和落地

由于跳跃是具有速度影响的，于是跳跃便使用了二次函数作为轨迹描述，同时由于二次函数变化越来越快，判断落地时便用了模糊处理，即判断上一个位置和下一个位置与平面的上下关系，但由于使用较晚，导致写好的函数还要再次更改。

3.4、冰冻物体和得分处理

游戏核心玩法为冰冻可冰冻物体，所以冰冻的判断必不可少，而冰冻大多与落地相同判断，于是在左右移动中加入了对砖块和梯子遍历，进行冰冻操作并计算冰冻占比。而得分处理较简单，只是对位置的判断和计分。

4、处理怪物操作

相对于玩家来说，怪物位置移动不必加入速度，但是边缘的判断却更加困难，由于最终选择遍历判断当前位置下方是否有游戏元素，怪物移动频频出错，左面恰好而右面多一个，最后平均分配多的一格才解决了问题。

第二种怪物相对较难，加入爬梯的操作，虽然跟玩家判断相差不大，但是最后由于未知原因怪物不能进行上下楼梯的状态转换而搁置。在最终版中，第一种怪物和第二种怪物的区别仅为移速的区别。

5、处理玩家和怪物的交互

玩家和怪物的交互包括血量减少和无敌时间，冰冻怪物和解冻时间。血量减少和冰冻怪物两者区别仅是玩家和怪物所处位置的差别，涉及跳跃使用的二次函数的判断。

5.1、血量减少和无敌时间

血量减少的判断和无敌时间的实现相对简单，仅为位置判断和血量数的变换。

5.2、冰冻怪物和解冻时间

与上面相同，也为位置判断和怪物状态代表数判断。而出现的新的问题为形成的大冰块可作为垫脚物。

6、音乐素材的使用

开发的最后，使用音乐素材使游戏生动，由于各个界面都有关闭和打开音乐音效的开关，最后加入的音乐判断有些繁琐，但是使用封装音乐函数，最后变化行数却不多。

三、 部分上述未涉及的技术

使用多次按照需求开关画布使得游戏界面和开始界面显示正常，降低了原游戏使用视角变化的实现难度。

针对不同的游戏元素设定不同的二维数组，在一定程度上加快了遍历速度和针对性。

利用switch-case语句进行显示界面的选择，取消了界面嵌套带来的界面退出和游戏中退出重新选择关卡的问题。

利用continue语句防止不必要的遍历。

利用文件读取和写入进行了关卡内容的读取和通关记录的存储。

封装背景雪花和音乐开始、停止函数，减少了多余代码的数量，简洁代码。

四、 体会总结

在这次项目设计中还可以对程序进行进一步的优化，利用结构体存储游戏元素的位置坐标和状态，速度等等，利用枚举类型进行可视化的变量变换，在对所有界面处理时利用switch-case语句等等。

第二种怪物的实现难题让我意识到项目设计的重点应该放在核心内容的实现上，纵使美观的界面可以吸引人，但充实的游戏内容才是留住玩家，增加玩家游戏体验的根本。

游戏最后未能达到原本的项目展望让我意识到一个游戏的实现难度不应该只看游戏操作的难易，应该看到它的实现难度。

由于结构体和枚举类型未用到，代码可读性低，维护难度大，继续开发难度高。

单人项目最难的问题在于惰性，因为自己的项目要自己一个人做，任务量大而重，不但有各种相同作用的代码需要自己一个人判断和重复，而且枯燥的图片处理更是让人厌烦，但是只要有代码的热情，这些小阻挠便不足为惧。如果这里就放弃了，那在后面还有各种让人抓狂的bug岂不是更加劝退么。只有投入时间而不是拖延才能更快的完成项目，实现更多的功能。

发现错误时要有破釜沉舟的决心，防止有些微小却涉及众多的错误在开发过程中进一步放大，例如界面显示的嵌套问题。虽然也可以实现目的，但之后的关卡退出让我认识到它的不足。