Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

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

You'd think since Unity is so easy, porting your game from Flash would be super fast. That's not necessarily true, but it's still a good choice. Here are top 5 things we learned.

Alex Nichiporchik

March 12, 2014

8 Min Read

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. 


You can already see the results in this Unity web build, it supports the Xbox controller and full-screen.

Read more about:

Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like