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.

Unity Components: Scripts

One of the things I really enjoy about Unity is the way the engine handles objects in the game world. Everything you add to your game scene is inherently a Game Object, which is a data type built into the engine. The interesting part is the ability to attach different Components to any Game Object. For example, going to GameObject > Create Other > Cube will spawn a cube object in the scene with four pre-defined Components attached to it: Transform, Mesh Filter, Box Collider, and Mesh Renderer. But really it’s the same thing as if you had gone to GameObject > Create Empty and added those Components to the newly-created object manually. If you need to, you can even remove most of the Components. This allows a wide range of customization options for game objects within Unity.

Scripts are also considered Components that can be attached directly to Game Objects. They essentially provide the developer the ability to manipulate an object by giving allowing more control over it via a programming interface. From within a script, the developer can access any part of its parent Game Object, including its other Components and their properties.

Since all components except scripts have pre-determined names, accessing them through a script requires the knowledge of each Component’s corresponding property name within code. The entire list, along with every Component’s description, can be found in the official Unity documentation, but here they are in a nutshell:

  • Transform is accessed as transform
  • Rigid Body is accessed as rigidbody
  • Renderer is accessed as renderer
  • Camera is accessed as camera
  • Light is accessed as light
  • Animation is accessed as animation
  • Collider is accessed as collider
Script Example
Accessing the Mesh Renderer Component attached to this script's Game Object when the object is created at run-time.

In order to access another script on the current object, you’ll have to refer to the name of the script directly by passing it to the GetComponent method. For example, if I want to access the “CharacterController” script but I’m currently in the “Main” script, I would use GetComponent(CharacterController).propertyName.

Accessing Other Scripts
Use the other script's name in order to access it.

In the example above, you can see references to several components and properties within the thisOre GameObject. Its x- and y-coordinates can be found within the Transform Component attached to the object. Those properties are set to variables that have been determined in other locations, one of which is the height variable that is only accessible by retrieving it from thisOre’s “ICOre” script.

Scripts can access not only the Components within the Game Object to which they are attached, but also any Game Object in the scene. This essentially allows the developer full control over any aspect of their game, through code. There are many ways to access other objects. So far I’ve found that GameObject.Find and FindObjectOfType have been reliable for accessing specific objects and scripts, respectively.

Accessing Other Objects
Any object or script can be referenced easily when needed.

Being able to reference the properties and methods of Components within a script’s corresponding Game Object, as well as the properties and methods within other objects’ Components is vital for maintaining full control over your project. Luckily, Unity makes such things very easy to do, with clear instructions right on their site.

Finally, one of the best things about Unity’s scripting is that it allows any of three languages: JavaScript, C#, or Boo (a dialect of Python). As I come from primarily an ActionScript 3.0 background, it was a great surprise to find that writing in JavaScript is almost identical to the way I do things in AS3. I would imagine that other programmers who are interested in Unity but could be wary of having to learn an entirely new language may breathe a similar sigh of relief.