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.
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.