游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

分享将游戏从Flash移植到Unity的5个体会

发布时间:2014-03-14 17:13:23 Tags:,,,,,

作者: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)

sprite sheets(from gamasutra)

在不久之前,我们几乎无法在Unity中有效使用Flash美术。现在有了2D插件,这一操作就方便多了。但它仍然是一个问题——在Flash中,你可以仅使用矢量美术,而无需担心其他情况。在Unity中,你就必须将一切内容输出到大型精灵工作表中令其生效。

因为这里不存在你可将过场动画和无缝转场到游戏玩法的唯一时间轴,所以你要编写大量代码。《No Time to Explain》从一个短暂的过场动画开始,然后让玩家挑选一杆枪并开始游戏。这在Flash中需要1小时的制作时间,包括简单调整动画等操作。

在Unity中,这个开幕就让我们花了数小时才调整正常。

2.本地物理效果并不适用于Flash游戏移植

physics(from gamasutra)

physics(from gamasutra)

Unity是一个含有内置物理系统的3D引擎,它在某些情况下甚为管用,但却不适合用于重制之前在缺乏物理系统的引擎中创造的游戏,因为后者的一切都是完全定制的。

在发现这根本不可行之前,我们捣鼓了本地物理引擎。我们使用了Unity的碰撞检测系统,写下了我们自己的“定制代码”物理系统,这与在AS2中编写的方法非常相似。

Unity在此的好处就是我们仍然可以在场景中添加一些物理支持的对象,让它们四处弹跳,并执行你所预期的操作。

3.粒子效果

particles(from gamasutra)

particles(from gamasutra)

粒子效果很强大。在Flash的局限性下开发内容,你会为雪花或火焰等效果而抓狂。但在Unity中,这就好像注入了一股清新的空气,让游戏看起来比Flash版本强多了。

4.帧率和像素

frame rate(from gamasutra)

frame rate(from gamasutra)

所以,现在游戏可以用疯狂的分辨率在高帧率情况下运行。你一开始永远不会想到这一点。所有的动画在第二帧时看起来与Flash完全不同了,你也无法进行像素探测。在Flash游戏中,我们只看像素是否正常,并据此分配碰撞效果。在Unity中,我们就得重新考虑检测碰撞的方法,尤其是在使用Unity本地引擎的时候。

5.关卡创造工具很棒

level creation tool(from gamasutra)

level creation tool(from gamasutra)

在《No Time To Explain》中,关卡是由JSON字符串生成的。我们能够相当轻松地由此创造一个转化器。但由于第4点的关系,多数关卡需要重新设计。它要以一个更高的帧率运行。

尽管如此,我们还是很容易使用Unity的内置场景预览来检查情况,而无需像我们在Flash中所做的创造自己的定制编辑器一样。

无论如何,Unity似乎都是从Flash中移植游戏的最佳选择,仅仅是因为它支持我们面向更多平台发布游戏,并在Steam平台上升级我们当前的版本。我们的玩家一直想要控制器支持和稳定性,而Flash设置令这些要求几乎无法实现。现在有了Unity移植版本,他们的这一梦想就能成真了。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

5 things learned: Flash to Unity port of No Time To Explain

by Alex Nichiporchik

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.

The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

No Time to Explain was initially a web based flash game, and then went to Kickstarter to become a commercial release on Steam. Long story short, the commercial game was also developed in Flash (ActionScript 2). Not the best decision as it turned out.

Here’s a trailer of the commercial game:

We had to do space ship trickshots to make it work. First of all, it has an ActionScript 3 file that is the launcher. This launcher is wrapped into ZINC with custom extensions — to make it a standalone app, able to communicate with Steam’s APIs.

However the only way for the AS3 launcher to communicate with the actual AS2 game is via local connection.

Here’s where the fun starts. You can’t rely on a local connection for constantly sending data back and forth, nor can you send large amounts of data.

So some players have issues with achievements not registering, others simply can’t launch the game on first try, etc. The way it’s structured is also not entirely stable — especially on multi-monitor setups.

After adding a level editor (which also uses the local connection…) we decided it was enough of work in ActionScript 2. Time to port No Time To Explain to Unity.

Here are the top5 things we learned.

1. Flash art & workflow vs Sprite Sheets

Up until recently it was next to impossible to efficiently use flash art in Unity. With the 2D plugin it became a bit easier. Still, an issue remains – in Flash, you can just use the vector art and not worry about anything. In Unity, however, you need to export everything into large sprite sheets to make it work.

Since there isn’t a single timeline that you could use for cutscenes and seamlessly transition into gameplay, you need to do a lot of coding. No Time To Explain starts off with an instant cutscene, and then you pick up a gun and start playing. This takes about an hour to do in Flash, including easy tweaks to animations and all that.

In Unity, however, that opening sequence took us hours to get right.

2. Native physics aren’t great for flash game ports

Unity is a 3D engine and has built-in physics. It’s good for some things, but definitely not for remaking a game previously created in a physics-less engine, where everything is completely custom.

We played around with the native physics engine before realizing it will never feel right. Instead, we use Unity’s collision detection system, and wrote our own “custom code” physics, very similar to the way it was written in AS2.

The good part about Unity here is that we can still drop some physics-enabled objects into the scene, and have them bounce around and do things you’d expect.

3. Particles, particles everywhere!

Particle effects are awesome. After working in Flash’s limitations, you can just go nuts with effects like snow or fire. It feels like a breath of fresh air and makes the game look really, really cool comparing with the old version.

4. Frame rate and pixels

So the game now can run at insane resolutions at high frame rates. You never really think about this initially. All of the animations will look completely different at twice the frame rate from flash, and you won’t be able to do pixel detection. In the flash game, we’d just see if pixels are touching and assign collision based on that. In Unity though, we had to rethink the way we detect collision, especially when using Unity’s native engine.

5. Level creation tools are great

In No Time To Explain, the levels are generated by JSON strings. We were able to pretty easily build a converter for that. But due to point 4, most of the levels need to be redesigned either way. It just plays different at a higher frame rate.

Regardless, it’s very easy to use Unity’s built in scene preview to check what’s going on, instead of creating your own custom editor like we did in Flash.

tl;dr Unity is great for most parts, but converting from Flash can be annoying and very long for parts that depend on timelines

Regardless, it feels like Unity is the best choice for porting from Flash, simply because we would be able to publish the game on more platforms, and upgrade our current build on Steam. Players have been asking for controller support and stability for ages, and with the Flash setup we stretched it to impossible limits. Now it looks like they’ll be getting it. (source:gamasutra


上一篇:

下一篇: