The Infernicore: Flash Game to Unity Game Part 2

This is the second part of the two-part post where I’m describing my experience with transferring a Flash game into Unity. In the first part I went over the differences in the physics and overall coding structure between the two pieces of software. In this part I’ll talk about creating objects dynamically, as well as my findings with transferring graphical assets.


Unless I’ve overlooked something, in Unity you can’t spawn objects from your project panel directly into your game scene without having had a reference to them already at compile time. But I really don’t think this should be a deal-breaker for any game. It’s quite simple to do. For example, in The Infernicore, I created a script called ICMain and attached it directly to the Main Camera object as a Component (the Main Camera is created in every scene by default). Within the ICMain script itself, I declared a variable called oreObject. Upon saving the script and returning to the Unity editor, I saw that “Ore Object” became a property in the Inspector Panel of the Main Camera object. I could then drag my Ore prefab from my project Panel directly onto the “Ore Object” section of the Inspector Panel. Voila! My main then had a reference to an Ore object, in code, that it could create at will. When I needed to do just that, I called Unity’s Instantiate()method and a new Ore object was created.

Referencing Objects to Instantiate
Create a variable and drag the object from your Project Panel to this field in the Properties Panel.

Like I said, I don’t think being required to have a reference to an object at compile-time is necessarily a really bad thing. I can understand how someone, especially a programmer, may balk at the idea at first, perhaps claiming that it limits control over the project, but I think the way Unity handles it will work in the vast majority of situations.

UPDATE: It turns out there actually is a way to instantiate objects without having a direct reference to them at compile-time. Simply place them into a Resources folder and use Instantiate(Resources.Load(“Object”)) instead. This method does have its own pros and cons, however. See this page for more information.


Since The Infernicore was originally a Flash project, all of its graphics were vector-based. Fortunately, however, converting vectors to bitmaps is quite simple with the newest version of Flash Professional.

One thing I want to talk about is utilizing textures with alpha channels, despite their irrelevance to this particular game. When we first started developing this project in Unity, we weren’t sure if we wanted to do everything in 2D or 3D. We settled on 3D eventually, which meant that alpha textures were more or less not needed, due to the 3D models using form-fitting skin textures instead. When I first searched for the answer of how to use alpha textures, I was met with directions that told me to install plug-ins for Photoshop. That seemed like a pretty janky solution, and it confused me as to why something like that would be on Unity’s site when it actually wasn’t necessary.

In order to use alpha textures, you simply have to ensure that the background of your image is removed (such as by deleting the background layer in Photoshop and cropping the image accordingly), save it as a PNG, import it into Unity, create a material for it, and set the material’s shader to Transparent/Diffuse. This worked like a charm for me.

We still plan on using 2D images for things like backgrounds and GUI elements, obviously. And when it comes to all of the different screen sizes for the myriad of Android phones out there, I definitely have some testing to do. I may post my findings on that adventure later on, but for now I’ll leave it at this: the transition from Flash game to Unity game has been relatively painless, and I hope others can say the same.

The Infernicore: Flash Game to Unity Game Part 1

Jestermen’s first game project, titled “The Infernicore”, began as a casual Flash game I created in my spare time over a year ago. But then came the time to get into the real world of game development; The Infernicore needed a make over, and Jestermen decided that Unity was the right tool for such a job. In the next couple of posts I’m going to highlight some of my experiences with transferring The Infernicore from a Flash game to a Unity game.


If you’re familiar with Flash game development, then you know that there is almost nothing inherent in ActionScript 3.0 that makes it easy to simulate physics. Of noteworthy exception are the built-in collision detection functions, but effects such as gravity and velocity must be handled solely by the developer unless he or she decides to utilize plugins or other frameworks like the popular Box2D. I decided to handle all physics simulation on my own in the Flash version of The Infernicore rather than delegate those tasks to outside libraries so I could maintain full control over my project. That’s not to say that I think utilizing libraries is a bad thing; I just find it more rewarding and simpler to organize when I’m able to solve such problems on my own.

When bringing The Infernicore into Unity, one of the bigger decisions I had to make was whether or not I wanted to keep the physics logic I had already written in the Flash version or replace it with Unity’s pre-built physics engine. Gravity, velocity, and collision detection are automatically supported with Unity, and would only require accessing the requisite properties and functions when necessary. That’s exactly what I did when it came to collision detection. One interesting note, however, is that I actually had to scale down each ore object’s Box Collider Component by 10% in order to attain the desired results. If I hadn’t done this, then collisions would have been triggered when I didn’t actually want them to; namely, when two ores’ edges were touching but not actually overlapping. For the purposes of this game, where ores are constantly sidling up next to each other, I needed to have a smaller “hit box”, if you will.

When it came to velocity and gravity, I fell back to my old Flash habits. I experimented with Unity’s gravity at first, but I kept getting unexpected results. That’s not to say that there’s anything wrong with Unity’s physics (I have no reason to believe that there is), but it felt and looked better to just use “fake” gravity by manipulating objects’ y-coordinates through the game loop. In the future I may take another shot at using Unity’s built-in velocity and gravity functions, but for this project they weren’t necessary.


Coming from an ActionScript 3.0 background, I found it incredibly helpful to be able to do all of The Infernicore’s code in JavaScript when I put it into Unity. The syntax differences between AS3 and JS are very few and far between. In fact, I literally copied and pasted all of the source code from my AS classes into JavaScript files that I created directly from the Unity IDE. Of course, heavy modification was required, but I was able to keep some of the code exactly the same.

The biggest change between AS3 and JavaScript was undoubtedly the lack of events and event listeners in JavaScript. That functionality had to be replaced with code that directly accessed objects that needed to be talked to, rather than dispatching and listening for events.

Some other changes included: replacing my class constructors with Unity’s Awake() function (it serves basically the same purpose); detecting keyboard input during the main game loop instead of listening for key press events; utilizing delegate methods to simulate changing game screens (very interesting concept); accessing other Components and Game Objects via Unity’s methods (see my previous post for more information); and wrapping my brain around the fact that (as far as I’m aware) it’s not possible dynamically instantiate objects in Unity without references to them beforehand. But no worries! That’s not as bad as it sounds.

In my next post I’ll go over how to create objects at run-time, as well as my experience with converting graphical elements from Flash to Unity.

The Decision to Use Unity, Part 2

So, what makes Unity better than the other game engines, in our eyes? That’s what I’d like to go over in this post. There are several reasons Matt and I chose Unity as our game engine for Jestermen’s first project, “The Infernicore”.

Its Simplicity

Unity's UI
Relatively simple, but effective!

Unlike quite a few other pieces of software I’ve used, Unity’s interface is exceedingly simple. It is intuitive, easy to use, and allows the user all of the options he or she needs without requiring row upon row of toolbars and menus. In fact, there are only five main panels within Unity: Scene, Game, Hierarchy, Project, and Inspector. The Scene panel displays the game assets during construction; easily navigable using common keyboard/mouse controls (such as holding Alt + dragging with left click to rotate the scene). The Game panel offers a view of the game as the user would see it; in fact, by simply pressing the play button at the top of the interface, one can immediately begin playing the game. The Hierarchy panel lists all assets that are currently in the scene. The Project panel displays every file that is in the Assets folder of the project for quick access to dropping any of them into the scene directly. And the Inspector panel simply waits for you to click on something, at which point it will display all properties associated with the clicked object. Of course, there are other buttons and menus, but the point is that none of them are vital to the core development process, which is why it was a smart move to keep them hidden until they’re needed.

Its Target Platforms

Unity 3D version 3.5 offers a new publishing option which has a potential that is quite difficult to overstate. Its ability to build projects directly into SWF files that automatically run in Adobe Flash Player means developers who want to distribute their content through the web no longer have to worry about whether sites support the Unity Web Player. And now that Flash Player 11 has a new 3D graphics rendering engine, the fact that Unity creates 3D content is also not a problem.

Unity 3D Build Settings
So many options, so few clicks!

Flash Player support isn’t the only upside to Unity’s publishing potential, however. The fact that it can build to so many different platforms without modifying a single line of code, as well as the ability to switch between target platforms with the click of a button (literally, just one button!) should be even further cause for excitement. PC standalone, Mac standalone, Flash Player, Unity Player, Android, iOS, XBox 360, PlayStation 3, and Wii build options are all supported.


Its Robustness

As if simplicity and distribution potential weren’t enough, Unity comes packed with enough features to make one wonder exactly why the entire program doesn’t require a purchased license in order to use it. For example, its built-in physics engine means developers don’t have to spend time messing with things like gravity and collision detection unless they really want to. Simply use the included script editor to apply a script with an OnCollisionEnter function. If more information is desired, the full documentation for every aspect of Scripting in Unity can be found on Unity’s website. JavaScript, C#, and Boo are the supported scripting languages. For the full list of features, look here.

What’s the downside to all of this? Surely it sounds too good to be true. I thought the same thing myself. And while I’m not exactly an expert Unity developer yet (I’ve only been using it for a couple months at most), I think I’ve seen enough to know that the pros greatly outweigh the cons. But as far as I can tell there is only one major con: the cost. Most features are present in the basic version, but building to anything except PC/Mac standalone and the Web Player will require a fee of some kind. Building to Android or iOS requires a $400 license for each. The Pro license costs $1500. And when version 3.5 comes out of public beta, publishing for the Flash Player will also require a fee. Jestermen encourages anyone to snag the basic version and actually develop something first, though. That’s what we’ve done, and we fell in love with the program. Try it and see!

The Decision to Use Unity, Part 1

Before Jestermen was even conceived, I had created a relatively simple Flash game that we have since renamed “The Infernicore”. I actually finished it in one week flat, and immediately uploaded it to Newgrounds. At the time it was just a small personal project based on what I thought was an interesting game mechanic. I didn’t even plan on converting it to a mobile app, much less make any money off it. So there it sat (and still sits!) until Matt and I decided it would be a good idea to push that sucker onto an app store.

Naturally, I figured that since the game was already done in Flash, and Adobe started supporting publishing for Android and iOS directly, I would just use the intended workflow to publish an app file using AIR in the Flash IDE. Long story short, I was quite disappointed to see that the performance on my Motorola Droid was far less than satisfactory. I spent hours trying to optimize the game, eventually coming to the realization that the problem most likely was not in my code; rather, it seemed to be that the graphics were not rendering fast enough. The slow frame rate completely eliminated the possibility of using AIR for Android with this particular application. Now, I’m not going to claim to be an expert on the subject, but I think I was diligent enough in my research that I could safely disregard the Flash/AIR route without any regrets.

AIR Render Mode GPU
Nope, didn't work.

With the project deadlines looming (yes, multiple deadlines; we set high standards for ourselves!), it quickly became less and less of a good idea to continue spending time trying to fix the Flash/AIR problem when I wasn’t even sure the problem could be fixed. So I decided to take my chances with a completely different engine. The only question was, which engine should I choose?

A quick Google search turned up a myriad of Android game engines, each claiming to be the right tool for the job. Among the more popular options included AndEngine, cocos2d, libgdx, Corona, Google App Inventor, and, of course, Unity.

AndEngine, cocos2d, and libgdx are purely frameworks; they’re code bases that will appeal only to those who are comfortable with programming. No visual IDE is included with them, which would have been fine except for the fact that proper documentation was either non-existent or perpetually out-of-date. Since the repositories are updated almost daily, bad timing could spell disaster for those who want to learn how to use them without having to spend hours sifting through old video tutorials and forum posts that may or may not be relevant to the current builds. Unfortunately, such was the case for me. Of course, I could have just opted to use a previous, more stable version of any of the repositories, but I decided to keep shopping around for the time being.

Hardware Acceleration Direct
Also no good. Curse you, Flash!

Corona is also just a code repository, but publishing using Corona comes at a premium. When I first learned about it I didn’t realize that it was possible to download the SDK for free, but by the time I learned that, we had already chosen Unity as our new engine. In any case, Corona may offer some potential, but it’s going to have to sit on the sidelines for now.

Google App Inventor was really user-friendly and simple. It used a completely visual, browser-based interface (no coding at all). In lieu of programming it offered a “blocks” UI, wherein the user simply created and snapped together blocks that represent variables and functions. But despite the satisfaction that came with the clicking digital jigsaw pieces into place, Google App Inventor had (at least) one fatal flaw: the inability to create objects at run-time. Obviously, such a limitation is a deal-breaker if one desires creative freedom in his or her games.

Finally, we’re left with Unity. There are many reasons that Unity stood out amongst all of the other engines, and I’ll get to them in my next post.

Unity 3D Logo
The end-all be-all of mobile game engines?