东京绅士物语-第1060部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！



　　　　今日之节操，喵喵喵～

第一千零七十二章　UI的问题（）　
“唔……这感觉……”

　　　　当家用机的游戏被放到掌机上的时候，高桥龙也有什么感觉？

　　　　高桥龙也想说的是“奇妙”这个词语。

　　　　首先是奇妙，然后是兴奋。

　　　　当掌机上面出现了这样惊奇的一幕之后，高桥龙也心中的感觉就是这样的。

　　　　精巧的VR战士出现在小小的掌机屏幕上，对于这个时代的人而言，这几乎是不可能的事情。

　　　　但是，现在的森夏做到了这一点。

　　　　虽然并不是让掌机本身拥有这样的能力，而是使用家用机进行运算，然后将画面输出到掌机上面，形成“串流”。

　　　　当然，出了这种最普通的串流方式之外，其实技术员那边还提出了很多种的解决方案。

　　　　首先就是和掌机输出到主机类似的模式。

　　　　简单来说，就是将家用机的数据进行重新处理，然后与掌机进行交互，最后以适合掌机的模式呈现出来。

　　　　但是这个方案被否决了。

　　　　原因并不是因为这种操作不好，而是这种操作费时费力。

　　　　费时费力，而且提升的效果与成就不成正比。

　　　　这才是最糟糕的事情。

　　　　资本家是要赚钱的。

　　　　所以到了最后，这个方式被否决了。

　　　　不是因为做不到，而是因为实现的过程稍微有些复杂。

　　　　所以现在的输出模式，就是按照原本森夏制定的模式进行渲染。

　　　　但这种半成品的输出模式现在也是很微妙。

　　　　“但是这样的话，UI也太小了吧？”

　　　　和掌机输出到电视正好相反，使用家用机输出到掌机上，UI就变小了。

　　　　一个变大，一个变小，这感觉就很怪异。

　　　　“感觉更适合玩动作游戏？”

　　　　高桥龙也嘀咕了一声。

　　　　但是用来玩文字游戏的话，果然还是不行的吧。

　　　　这种模式还是太糟糕了。

　　　　“不过我记得有一个开发者社区……”

　　　　高桥龙也打开了电脑开始上网。

　　　　马上就要新年了，虽然高桥龙也留在了会社之中，但在这个时候，却也没有其他人。

　　　　叶社是老牌的游戏会社，但为了与时俱进，他们这边的机器，也还是有接入互联网的。

　　　　打开网页，然后进入了开发者社区。

　　　　“关于解决UI问题的一些看法。”

　　　　“串流重设UI对于串流的影响。”

　　　　“有关于XBOX与DC之间的输入延迟问题。”

　　　　……

　　　　在论坛上有很多的帖子，不过这些帖子之中，最多的果然也都是讨论UI的问题。

　　　　XBOX的分辨率有限，而UI太小的话，且不说图像大小的问题，光是那有限的分辨率，就很难完整的显示问题。

　　　　这个问题甚至比掌机输出电视机更严重。

　　　　至少UI过大的话，大家只是看着觉得有些问题，但是游戏本身还是可以阅读的。

　　　　但是反向输出的话，那就不一样了。

　　　　玩不了也是一个问题。

　　　　高桥龙也点开了一个帖子。

　　　　这是一个技术贴。

　　　　高桥龙也本身对于这方面的技术并不是很能够看得懂，但对方说的部分内容，高桥龙也还是明白的。

　　　　“……根据情况，实现UI管理最佳的方式，便是设计两套UI，在切换设备，UI本身也能够无缝切换，这样所能够实现的效果才是最好的。”

　　　　这位仁兄认为，最佳的实现方法，就是厂商在开发的时候，就设计两套UI，UI本身可以切换，而且并不影响游戏机制和设计本身。

　　　　这也是开发团队本身就想要促进的事情。

　　　　——毕竟，如果是游戏已经开发好了，然后利用游戏本身的机制和机器自身来实现画面和UI的转换，这种事情很不现实。

　　　　但如果厂商自身就制作了两套UI，倒是可以方便一点，更重要的是，UI本身的设计其实并不会怎么影响开发。

　　　　然而在回帖的楼层，就有人提出了会串流的玩家数量并不是很多的这一看法。

　　　　“虽然夏森老师提出的这个创意很多，但是我个人认为会使用串流的人很少。串流固然有趣，但实际上还并不是最佳的解决方案，如果XBOX能够将那根串流线取下来的话，这样才是最佳的解决方案吧。”

　　　　这个人说的有道理。

　　　　高桥龙也在玩游戏的时候也是这种感觉。

　　　　UI是一个方面，而另外一个方面，就是上面那根线。

　　　　如果没有那根线的话，这游戏的感觉，至少能够提升一倍！

　　　　除此之外，也有帖子对于通用的游戏UI提出了解决方案。

　　　　“关于方舟引擎的通用转化系统。”

　　　　这个帖子的作者是一名独立开发者，他曾经使用方舟引擎制作了属于自己的Galgame，这个集程序员、美工、脚本于一提的开发者认为，如果重新定义游戏的输出接口，然后做成新的UI。

　　　　这种事情听起来很复杂，但师酱是很简单的。

　　　　如果一个文字AVG需要运行的话，需要很多运行库之类的，然后游戏本身与系统之间互相交互之类的。

　　　　想要移植的话，就要考虑另外一台机器的情况。

　　　　但这位程序员提出了一个看法。

　　　　他对方舟引擎研究比较深入，因此他提出的这个方法，就是将方舟引擎本身当成一个“黑盒子”。

　　　　甚至于，他认为可以通过这种方法使用打包和移植游戏，然后将其实现。

　　　　然后将游戏的接口进行重新定义，使其实现的功能产生区别。

　　　　什么是黑盒子呢？

　　　　简单的比喻一下的话，可以将一个程序看成是一个“1＋1=？”的数学题。

　　　　如果想要知道这个问题的答案，使用者便将这个问题递给一个黑房间里面，让其解答。

　　　　在这个黑房间里面发生了什么，外面的人是不知道的，无论里面是一只猫在做数学题，还是一个宇宙人在做数学题，但是输出的答案都是“2”这个正确结论。

　　　　这就是黑盒子了。

　　　　而这个程序员提出的解决方案就是类似这种。

　　　　在知道了“1＋1=2”的答案之后，那就无所谓中间的过程了。就好比这个问题的“原本答案”是一只猫做出来的，但自己这边让一只大象来回答这个问题，只要保证能够实现1＋1=2，那就没有问题了。

　　　　别说，这个人提出来的想法还挺有前瞻性的，在未来，也的确有类似系统做的引擎——例如让安卓平台运行PC上的galgame的程序ONS。

　　　　ONS的原理，就是在明白NS脚本编写语言的基础上，对其进行解析，使得内容能够呈现在手机、掌机或者其他的设备上面。

　　　　不过高桥对于移植本身并不是特别有兴趣，他更关心的是这个人提出的UI变换的想法。

　　　　简单来说，这个人就是重新定义了“1＋1=3”这个条件。

　　　　在输出UI的时候，对于原本的脚本进行重新定义，将原本a=b的内容定义为了a=c，这样，虽然原本输出的结果没有变化，但是这个结果“a”在画面中呈现的效果“b”就变成了效果“c”。

　　　　这种说法有些奇怪，但如果用18X催眠类别的小黄油来解释的话，就很明了了，那就是“常识替换”。

　　　　嗯，大概就是这样的意思。

　　　　高桥龙也艰难的看完了这篇文章，他感觉自己脑袋有些变成了浆糊。

　　　　在说了一大堆内容之后，他大概明白了对方的说法。

　　　　而在帖子的最下面，这位仁兄为了证明自己的说法，他也放上了几张截图。

　　　　在截图上面，是这位老兄开发的新游戏的DEMO，这是运行在PC端上面的画面。

　　　　可以看出，画面上的文字大小始终，按钮也很鲜明。

　　　　而第二张图的分辨率一样，但是这张图上面的文字却大了很多，并且按钮也变成了隐藏式的——因为只需要按动手柄上的按键就能够实现功能了，所以画面本身的按钮就变得不再重要。

　　　　对方强调，自己并非是制作了两套UI，而是使用了自己编写的程序变换了接口定义而已，利用方舟游戏引擎的特性，想要做到这一点，并不算很困难。

　　　　“所以才只适合方舟引擎么……”

　　　　叶社开发游戏有自己的引擎来着，这种方法并不适用。

　　　　但是他还是饶有兴致的继续看去。

　　　　“但是，这种做法也有一些要求，首先就是必须要使用矢量UI，使用图画素材定制的UI，画面会被强行拉伸，有时候甚至会让整个UI错乱，这是不可避免会产生的情况，方舟引擎并没有对此进行优化，我在此基础上正在重写这部分的内容，我制作了一个测试版以供测试，这部分内容，能够让新的引擎本身支持双UI结构，开发变得简单。”

　　　　在这下面，有一个名叫“ARK…KRKRV0。01”的附件。

　　　　“楼主可真厉害啊，竟然还能这么玩？”

　　　　“…回复楼上：谢谢。我原本便有自己想要开发引擎的想法，这个名叫‘krkr吉里吉里’的名称，其实就是来源于我自己的想法。”

　　　　“咦？那楼主为什么停止开发了呢？”

　　　　“啊，因为我发现我想要实现的功能，方舟引擎都已经全部实现了呢，而且效果比我所想象的还好要，更有一些我都完全没有的好点子，A社的人真的好厉害啊！嘛，不过也正因为如此，所以我才停止了自己的游戏引擎的开发吧。”

　　　　原来如此，这个人还打算自己开发一个引擎，难怪现在能实现这么多的功能，真的好厉害啊。

　　　　“嘛，不过还是单独设计两套UI比较好吧。”

　　　　这是高桥龙也的看法。

　　　　虽然这么做可能成本消耗高一点，但这种傻笨的方法，其实菜是最不容易出错的，可靠性上面远远高于之前那个人说的解决方案。

　　　　“咦？”

　　　　这么想着的高桥龙也，忽然又看到了另外一个帖子。

　　　　“关于使用DC与XB