网站建设项目网络图滁州网站建设推广

当前位置： 首页 > news >正文

网站建设项目网络图,滁州网站建设推广,seo实战密码pdf,网页论坛一、前言 这两天三阳了#xff0c;头疼头晕恶心发烧打喷嚏流鼻涕咳嗽嗓子疼气管疼都找上门来了#xff0c;这导致一周以来都没学什么东西#xff0c;无意间又刷到各个游戏厂关于本人目标岗位HC骤减且要求造火箭的能力的消息#xff0c;这两天一直是在病痛和焦虑中度过的头疼头晕恶心发烧打喷嚏流鼻涕咳嗽嗓子疼气管疼都找上门来了这导致一周以来都没学什么东西无意间又刷到各个游戏厂关于本人目标岗位HC骤减且要求造火箭的能力的消息这两天一直是在病痛和焦虑中度过的躺着就焦虑自己在浪费时间坐到电脑前又没有精神集中可以学习因为阳了。但是我还是想尝试写一些东西说是打发时间也好或者恢复一下脑子总之就是想记录一下当时第一次游戏开发的一些经历和感想吧对自己以后的工作可能也会有一些帮助。写文章时脑子仍然处于发烧状态如果出现胡言乱语还请见谅 这里我主要想阐述我自己视角下的一些东西因为当时我是担任程序和一部分策划的工作关于美术我只负责了一定的美术资源的处理和使用并没有美术资源产出所以也不会有什么见解。我想写一些关于游戏开发的个人思考吧方便小白参考也方便我日后回顾当然和我所有的博客一样如果有大佬看到了错误也请指出我会虚心改正。同时为了大家都能读懂我不会用专业术语尽量让所有人都能读懂。 先说明一下经历的大概情况要求每个组5个人分工自定在6天之内做出一个完整的项目。本人在项目之初担任的是程序当然后来因为需要介入了策划和关卡设计与搭建等工作。 二、立项—磨合、集思广益 在立项的时候理想情况下如果策划已经有了想法并且如果策划是一个比较认真负责的策划的话他会直接写一个项目文档供大家讨论分析可行性以及潜在问题等等当然可能后续需要一些细化。 如果策划是一个不懂程序或者说没有经验的人那么立项这个事情将会非常拖延时间常见的情况比如策划天马行空的想法程序无法实现美术无法创作。或者理论上可以实现但因为团队中程序技术能力的原因导致的无法实现这无法直接说是谁的问题策划有考虑不周到程序有技术不达标这都有可能这是一个团队需要磨合的东西。 有些情况比如在本人的第一次的游戏开发经历中我们团队倾向于的是头脑风暴式的立项看上去是一个很民主的选择实则个人认为是最浪费时间的一个选择。我们团队的所有人都提出了1~2个想法并把它们按照自己设想的方法细化贴到公共的白板上供我们之间互相提出意见最后经过长时间的讨论交流我们投票选出了相对来说既可实现落地又有一定创意的方案之后在此基础上进行工程上细化和潜在问题的解决。 立项之初头脑风暴大家的各自奇思妙想 这个过程我用文字只描述了一点点但实际上在整个6天的时间里这个立项花费了我们2天的时间。在此我并不想说这样做不好因为我觉得大部分人做游戏都是有一定情怀在的大家想做出自己心目中的那个游戏而并不想完全追求效率把它当作一个工业化的产品当然如果是在公司那确确实实就是这样大家都是流水线上的工人这样可以提高很多效率。所以我在这想说明的就是立项这个选择因人而异但无论怎样策划的脑子里是一定要有东西的坦白地说作为程序我一开始就已经把自己当成了干活的而没想到要参与到设计中去如果大家都是这样那整个项目就是空谈了所以无论是策划一人独大也好还是集思广益也罢策划的脑子里一定要有东西。 三、程序的分工—交叉与并行 我们团队的分工是2策划2程序1美术也就是负责大部分项目内容工作的只有3个人美术只有一个人所以只需要自顾自即可。但程序有2个人一旦出现1个人以上就需要进行分工协作了。 在开发之处其实我已经遇见了一些可能会遇到的问题如果两个程序的开发内容存在交叉那么一个人写出的BUG另外一个人可能很难调试就算BUG修好了又可能会导致修改BUG导致原本程序的其它逻辑出现BUG。而避免这一问题我们需要把对方的代码再读一遍理解对方实现某个功能的逻辑因为一个功能的实现可以有很多种逻辑方法我们并不能想当然的觉得对方和自己的想法是一样的。因此读对方的代码理解对方的逻辑思路在前期花费了大量的时间。 既然交叉的工作内容会导致问题难道就没有解决方案了吗有当然有那就是两个人负责不同的大块的整块的内容比如在我们游戏里有三个角色它们有各自不同的移动逻辑和功能逻辑如果我负责写移动而他负责写功能那么这样发生冲突的概率就会减小很多这就是各自独立并行的工作内容既可以提升效率又不至于牵一发而动全身。但是问题并没有这样解决因为整个游戏中各个元素的交互导致了这些逻辑并不是独立的存在它们仍然有交互有影响在这种情况下我们最终决定我来负责游戏内的角色逻辑而另一名程序负责UI和关卡的逻辑其次由于我后续介入了策划和关卡搭建程序到最后基本都由另一位程序实现了这样效率有提高并且减少了BUG的可能性。 在这里我想阐述的观点是团队协作本身没有错但是整个项目在分工的时候最好把每个部分分为独立的个体这样最后把大家的结果合并的时候才会减小发生冲突的概率当然如果相互沟通能力特别强的话这应该也算不上什么问题但大多数情况不是。所以分工的独立性和并行性尤为重要无论是策划程序还是美术。 四、项目资产的管理—减少沟通成本 当时的项目整理后的资产 这里用我的经历举例不太具有参考价值但有一定的参考性因为作为一个6天的小项目需要管理的资产并不多但如果对于一个大项目所有的脚本美术资产等等都需要有一定的规范性整理从命名规则到文件夹包含关系团队内需要同一的规定来确保每个人都能轻而易举的调用项目资产并且每个人自身创建管理资产的时候也需要用同样的标准。这样做可以最大的减少沟通成本避免混淆冲突。 举例上图中的Prefabs就是一个例子预制体作为一个较为大的概况可以包含游戏内各个元素的预制体角色地图UI等等这样负责搭建场景的人一眼就知道哪些可以用来干什么。 其次Scene场景是我们存放游戏中关卡的文件夹这本身到没什么说的你可能会注意到关卡1-4后面都有一个后缀-new因为在初期没有美术资产的时候我们需要用简单的几何体来测试BUG而有了美术资产后将几何体替换掉后我们同一命名加上后缀-new以免引起误会并且很容易区分一眼就可以看出这是迭代更新后的关卡。 五、美术资源的需求和规范确定—让美术带着镣铐跳舞 1.需求确定 整个项目开发的过程中这个是最令我头疼的首先是因为我们团队里只有一个美术所以产能有限而另一边的策划经验有限会时不时的蹦出一些需要新的美术资产的新想法当然在我的拒绝下这些想法都被搁置了原因是项目的核心所需要的美术资产还没生产完成的时候美术不应该把精力放在其他地方。 在项目立项结束并且细化确定美术风格以后我们就应该想到大体需要哪些美术资源具体到UI的形状颜色等等等等写成文档或者列成表格一并交给美术去生产程序应当也是如此。这样做之后在此基础上查缺补漏不断迭代最后再优化细节。一定要避免的情况是简简单单的想了个大概然后跟美术说了说大概需要哪些东西然后在项目进行的过程中时不时蹦出新的需求这回严重影响进度效率。 2.规范确定 美术资产必须要有规范性而不能让美术闭门造车。 我举一个例子我们当时是一个2D的解密小游戏自然涉及到平台跳跃那么平台这个资产显然是需要大量复用的并且有着不确定性因为在关卡设计和搭建的过程中我们需要各种长度的平台如果只有一种固定长度的平台会严重限制关卡的设计种类。你可能会说不是有缩放功能吗当然但是缩放后扭曲了原本资产的形状会很丑。而在项目之初我们的美术确实没考虑过这一点所以只交给了我们一种平台的美术资产导致后续的关卡迭代非常繁琐浪费时间。最后和美术沟通完毕后我们终于有了分块的可复用的平台美术资产但是前期浪费的时间确是无法弥补的。 第二个例子美术资产的尺寸问题这个问题到最后项目完成时才发现但是当时已经来不及了。简单的说就像地图上的比例尺问题一样由于各个美术资产并不是独立出现的它们共同放在一个场景里那么它们就需要有一个相同的比例尺同时又要考虑角色的尺寸相称性并且方便角色的交互。 我们出现的问题如下图所示。 障碍物的比例出现问题 上图左边的石头乍一看好像没什么问题但是仔细看看就会发现有模糊/马赛克的现象原因是我们把美术给的资源进行了放大那么可不可以缩小呢答案是不可以因为角色的资产的尺寸和我们在脚本中设定的跳跃高度就是当前石头的大小其次这个石头在设定中属于初级障碍物也就是一段跳就可以跳过去而右边的粉色大石头属于次级障碍物需要垫着小石头跳过所以左边小石头的放大可以满足这个需求。 所以综上所述角色的尺寸导致了我们的脚本的跳跃高度的调整进而决定了石头的大小于是它无法调整只能这样。或者以我们的引擎中的规格来制定美术标准或者根据美术所生产的资产尺寸我们修改脚本但实际上这都是不现实的。唯一的解决方法就是在美术生产资产的过程中自己脑袋里清楚游戏的场景大致长什么样以及场景中各个元素都是用来干嘛的并且需要专门的人来制定一套资产规范和尺寸标准。 六、游戏机制与关卡设计—站在玩家的视角 1.关卡的逻辑设计 当时的关卡设计草图 游戏关卡的设计最初原本是交给我们的策划但是显然我们策划经验并不丰富所以我介入了一下当然这不只是我一个人的功劳大家都参与到了设计中只不过我提供了一种可行的产出方法。 在每个关卡/场景都有一些相同的东西我把它们列了出来如上图所示由于是解密游戏我考虑了玩家具有的能力以及玩家需要解决的问题那么设计关卡本质上就和老师出卷子一样你需要考虑到学生会些什么这样就可以把各个知识点杂糅在一起不断排列组合形成新的问题如上图所示玩家的障碍就是几个东西四个障碍我们如果排列组合可以得到44*44*4*44*4*4*4种不同的结果对于一个6天的项目设计5个关卡来说已经足够的不能再足够了当然这只是关卡的逻辑设计部分也是较为烧脑的部分至于场景如何搭建并不需要花很多时间来思考。 2.考虑玩家的感受 在关卡设计过程中我们还遇到了一些问题在最初我们并没有设计新手关卡我们自认为2D跳跃的游戏大家玩多了应该上来就知道怎么玩。但显然这种思路是错误的因为毕竟我们还是有一定的创新机制在里面并且它本身也并不是那么容易掌握。 于是在大家的一致建议下我们为玩家添加了3个新手关卡循序渐进难度依次递增来试图让新接触我们游戏的玩家能快速理解我们游戏的机制游玩并通关。 七、总结与反思—制定自己的工业化流水线 以上就是关于我第一次游戏开发经历的总结与反思。 还有一点对于我们这种第一次开发游戏的人来说个人认为这些是很容易遇到的问题对于成熟的独立游戏开发者工作室公司等它们应该有一套完整的工业流水线和体系能够完美的避免这些问题同时由于我们的项目很简单所以有许多问题可能是没到一定体量是不会遇到的因此本篇写的也只是冰山一角想要流畅的做出一款游戏还是需要很多碰壁和磨练的。 本质上来说这是一个工程性的东西和单纯的学习是不一样的本文没有提到的性能优化适配等等问题是工业中实际经常会遇到的问题而我们没有考虑并不代表没有这些问题。 本文提到的问题对于刚入门游戏开发或者想参加一些游戏开发比赛的小白来说应该还是有一些参考价值的总的来说提前的风险预测排雷很重要。希望大家都能在经历中总结和思考不断历练自己成为一个优秀的工程师。 八、结语 脑袋有点难受不想写了。。。。。。