|
作者：Alex Nichiporchik 《No Time to Explain》最初是一款网页Flash游戏，之后转向Kickstarter平台筹资，成为Steam上的一款商业游戏。这款商业游戏是由Flash(ActionScript 2)开发而成，但效果并不是特别理想。 我们要大费周折让它生效。首先，它拥有一个作为发射器的ActionScript 3文件。这个发布器用一个定制扩展名包装到ZINC中——令其成为一个独立的应用，以便同Steam的API通话。 但让AS3发布器与真正的AS2游戏通话的唯一途径就是通过本地连接。 这真是个有意思的开端。你无法依赖本地连接持续来回传送数据，也不能传送大量数据。 所以玩家就会出现没有记录在案的成就等问题，还有些玩家第一次时根本无法启动游戏。它的组织方式并不完全稳定——尤其是在多监视器设置的情况下。 在增加一个关卡编辑器（游戏邦注：它也使用本地连接）之后，我们认为它足够用于ActionScript 2。现在是时候将《No Time to Explain》移植到Unity了。 以下就是我们从中所学到的5个经验。 1.Flash美术&工作流 VS 精灵工作表  sprite sheets(from gamasutra)
在不久之前，我们几乎无法在Unity中有效使用Flash美术。现在有了2D插件，这一操作就方便多了。但它仍然是一个问题——在Flash中，你可以仅使用矢量美术，而无需担心其他情况。在Unity中，你就必须将一切内容输出到大型精灵工作表中令其生效。 因为这里不存在你可将过场动画和无缝转场到游戏玩法的唯一时间轴，所以你要编写大量代码。《No Time to Explain》从一个短暂的过场动画开始，然后让玩家挑选一杆枪并开始游戏。这在Flash中需要1小时的制作时间，包括简单调整动画等操作。 在Unity中，这个开幕就让我们花了数小时才调整正常。 2.本地物理效果并不适用于Flash游戏移植  physics(from gamasutra)
Unity是一个含有内置物理系统的3D引擎，它在某些情况下甚为管用，但却不适合用于重制之前在缺乏物理系统的引擎中创造的游戏，因为后者的一切都是完全定制的。 在发现这根本不可行之前，我们捣鼓了本地物理引擎。我们使用了Unity的碰撞检测系统，写下了我们自己的“定制代码”物理系统，这与在AS2中编写的方法非常相似。 Unity在此的好处就是我们仍然可以在场景中添加一些物理支持的对象，让它们四处弹跳，并执行你所预期的操作。 3.粒子效果  particles(from gamasutra)
粒子效果很强大。在Flash的局限性下开发内容，你会为雪花或火焰等效果而抓狂。但在Unity中，这就好像注入了一股清新的空气，让游戏看起来比Flash版本强多了。 4.帧率和像素  frame rate(from gamasutra)
所以，现在游戏可以用疯狂的分辨率在高帧率情况下运行。你一开始永远不会想到这一点。所有的动画在第二帧时看起来与Flash完全不同了，你也无法进行像素探测。在Flash游戏中，我们只看像素是否正常，并据此分配碰撞效果。在Unity中，我们就得重新考虑检测碰撞的方法，尤其是在使用Unity本地引擎的时候。 5.关卡创造工具很棒  level creation tool(from gamasutra)
在《No Time To Explain》中，关卡是由JSON字符串生成的。我们能够相当轻松地由此创造一个转化器。但由于第4点的关系，多数关卡需要重新设计。它要以一个更高的帧率运行。 尽管如此，我们还是很容易使用Unity的内置场景预览来检查情况，而无需像我们在Flash中所做的创造自己的定制编辑器一样。 无论如何，Unity似乎都是从Flash中移植游戏的最佳选择，仅仅是因为它支持我们面向更多平台发布游戏，并在Steam平台上升级我们当前的版本。我们的玩家一直想要控制器支持和稳定性，而Flash设置令这些要求几乎无法实现。现在有了Unity移植版本，他们的这一梦想就能成真了。
| 
IP卡
狗仔卡
发表于 2014-3-15 14:09:15
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
发表于 2014-10-19 09:34:37