268.社长真乃神人也！ (第1/2页)

微看书 www.vkss.cc，最快更新才不是做galgame呢!

“先别说不可能完成。”

青智源赶紧打住，“赤西桑，你也是程序总监，pokeni的元老，你要是一开始就打退堂鼓的话，以后其他同事们也没法做事情了。”

“好，好的社长。”赤西健苦着个脸回应到。

“我们一个一个问题来解决。”青智源说，“先大地图吧。”

“1000*1000对于程序来说，可能确实是有点大，加载效率慢可以理解，但是我们可以先做分块加载嘛。”

“你先切割成4块，实在不行就切割成16块，25块，都可以。只要能满足流畅加载的需求就行。”

“中间过渡的时候有卡顿什么的，都是很正常的。”

青智源说。

“但是，看起来过渡的时候会很别扭呢。”赤西健说，“可能我在这个小块儿上面看的所有东西都是清晰的，但是就隔了一米远，结果前面这个地图块儿没被加载出来，就全是空。”

“预加载。”青智源说着站了起来，在白板上面画了一个图示：

先画了一个方块，然后在方块的四条边上面又各自画了一个方块。

“伱看，”青智源指着中心的方块说，“我从这个区域跑到这个东边的区域，这个时候你别等我走到了你再把右边的方块给加载出来，而是我在走的过程当中，你就应该要加载右边的这个方块了。”

“然后呢，当我走到最右边的这个方块的时候，最左边那个不是已经超出我的视野范围了吗？这个时候你就把它给删掉就行了。

相当于我们同一时间只加载了2到3个块儿，在程序开销上面就可以得到最大程度的节约。”

而且，为了满足这一点青智源决定在第一代《怪物猎人》当中，不投放坐骑系统。

玩家们的跑步速度也要做个上限限制才行。

“但是，哪怕是这样，可能在怪物模型面数上面还是有困难。”赤西健继续看着文档说，“草食龙，一种群居类怪物，经常会成群结队出现，大概在4到6只左右。

我们现在对模型面数的支持，就没有那么多。”

“而且一个大场景当中，可不是只有一种怪物会出现，会同时加载好多不同的怪物进来，也就是说，有可能在视野当中，会同时出现10多只怪物，一旦发生这种情况，就会卡顿，甚至会导致系统崩溃。”

emmmm……

青智源托着下巴思考着。

赤西健说的问题是客观存在的，毕竟现在的硬件水平就放在这里，还没有到达前世随便挥霍的程度。

在2023年的时候，大概只有在手机上面才要节约资源，节约内存，在端游上面几乎不存在这个问题。

你想想看，一个游戏可以做到几百G的大小，谁会在意这么一点点的开销？

手机是内存受限没有办法。

也就是说，现在的游戏得按照手游的开发标准来制定才行，能压缩的尽量压缩，能节省的尽量节省。

啊~

青智源不由得感叹，还是太慢了，时代还是太慢了再发展迅速一些就好了。

“这个问题其实也好解决。”青智源拿起记号笔在白板上面写了三个大字——

“LOD。”

“LOD？”

赤西健和小池一脸懵逼。

“分层显示技术。”青智源用人话再说了一遍。

“什么意思呢？”

“你看哈，”

青智源先在白板上面画了一匹特别写实的马，然后再在旁边画了一匹马赛克马，再后面是一个不知道是什么鬼的特别抽象的马，大概也就只有几根线条而已。

“我们制作不同的精度的模型。”

“近距离范围内，按照优先级最高，加载实际面数多的这个模型出来。”

“如果离得远，没有战斗需求和交互需求，但是又在可见范围内的话，就可以使用粗糙一点的，面数少的这个。”

“再远一点，勉强可见的话，可以只加载这个特别特别粗糙的模型，甚至不加载都行，只加载地形就行了。”

“除此之外，给地形、材质、不同的物体模型上打一个优先级的标签，这样方便程序来进行判断。”

“比如地形是最重要的，那么在预加载的过程当中，就会先把地给加载进来，之后再是一些环境当中的重要元素，什么大石头啊，悬崖，河流……

就按照这个模式去做就行了。”

“哦哦，懂了懂了。”赤西健和小池点头如捣蒜。

社长真是太可怕了。

居然能想到这种方式。

按照赤西健原来的设想，一个场景当中加载那么多的东西进来，起码得有几万面了，这程序消耗怎么可能吃得消。

但是青智源一说分层级加载，预加载，突然一下子就把几万面给干到了只有几百面了，简直可怕。

这其实还有一个好处，就是可以模拟真实的人眼。

人看东西，也是近处的圆形范围内，越靠近焦点的越清楚，越远离的就越模糊。

LOD做出来之后，其实也是这样的一个效果。

离得越远，加载的模型就越粗糙，面数越少，自然就越模糊。

不但不会因为面数减少而导致玩家们觉得不舒服。

反而显得更加真实。

不过就像青智源说的那样，你得将玩家的移动速度控制在一定的范围内才行。

不然的话，当你的移动速度超过了预加载的速度，那就很容易穿帮了。

比如说旁边这块地板还没加载出来，你就直接开着摩托车过去了，有可能一下子就陷入地板下面。

这也是很多游戏当中常常存在的bug。

但是实际上就是因为预加载没能匹配上的问题导致的。

……

“除此之外呢，程序那边还需要做一件事情。”青智源说。

“嗯？”赤西健疑惑地抬起头来。

“你们知道拓扑运算吧？”

“知，知道吧……”赤西健有点犹豫。

倒不是自己的程序水平不够，主要是社长那副盛气凌人的样子，就好像是在课堂上面讲课的老师一样，突然提问学生，你一下子心里面多少会有点儿慌。

“那就好办了。”青智源说着，将一个粉笔盒放到了桌子上，然后再掏出一根粉笔来放到它的后面，只露出半截脑袋。

“在3D领域当中，物体之间其实是有遮挡关系的。”

“比如说，这根粉笔，有半截藏在后面，那么它从你们的视角来看，其实就只有一半可见。”

“在这种情况下，按照一般的程序逻辑，不管后半部分可不可见，是不是也会被加载出来呢？”

“嗯，”赤西健点点头，“那是肯定的。”

“但是实际上，我们并不需要加载后面的部分对不对，因为对于玩家们来说，藏在盒子后面的半截粉笔是个无效信息，那么就应该将后边这个部分给裁掉。”

“而且，就粉笔盒而言，能被玩家们看到的也就只有三个面而已，在后面和底下的面也是多余的，将这些面都给裁掉的话，内存开销一下子就释放出来了。”

纳尼？！

赤西健和小池两个人都惊呆了。

短短的一个教学，立刻就让他们见识到了社长的程序功底有多么的强大。

甚至你都不知道这算是程序范畴还是数学范畴内的东西。

“但是，它是个整体，没法做切割啊。”

“这不就来了吗，用拓扑算法计算一下，将后面不可见的部分给裁掉就行了。”

“那不就得要求一个实时运算吗？这个运算导致的开销似乎也不小。”

唔……青智源托着下巴，赤西健说得好像有点道理啊。

差点儿忘记了时代限制。

现在的算力可能真的不够支撑。

面数加载是少了，可是带来的实时运算量增加了，究竟哪一种更加合算，还真的不太好说。

“那就这样，”青智源说，“静态的物体构成，比如说这些东西不会动，并且遮挡关系都是固定的，那么就按照我说的，在美术制作完成之后就由程序来做第一次的剪裁合并工作。”

“如果是会变化移动的，这样的遮挡关系，你们就想办法做优化，哪怕现在不行，未来肯定可以。”

呃……

赤西健狠狠皱了皱眉。

感觉工作量无形中又增加了不少。

前面说的东西是一个满足基本需求，到这里变成优化内容了。

众所周知，程序优化是最难也最花费时间的。

……

“AI方面也很难做到吧？”赤西健难受地说。

他几乎已经找不到任何可以刁难社长的问题了，只能通过最后一搏来死死挣扎。

如果这样还不行的话——

我们就要开始动工去攻克这些可怕的难题了呢。

虽然说在青智源已经给出明确方案的情况下，倒也不算难，但是这都是工作量啊。

没有思考的工作量，更加没有成就感。

有的只是作为一个工具人的疲劳而已。

现在赤西健有些后悔了，不该这么早来找社长的，应该自己拉着小弟们商量一遍，看看能不能找到解决方法，实在不行才去找社长，这样才对。