Version 2.0 of Jestermen’s first mobile app, “Witch Way?”, has just been approved by Apple, and is now available for $0.99 on the App Store. This version allows the user to create custom responses for the witch — a marked improvement over the free Android version.
Feedback is always welcome. Feel free to post comments here, send an email, or leave a review on either app’s page.
Stay tuned for more updates as Jestermen continues to grow in 2013!
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.
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.
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 (veryinteresting 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.