One more Game Boy Jam, one more small game made.
As I may have written before, I love joining Game Boy Jam because the limitations allow me to work alone and force myself to learn new stuff, with enough time to not go crazy. Just before this one (the fourth edition), I started learning how to use Unity to relaunch an old game, so this was a good chance to put Unity to the test.
Until then, I had only made games with cocos2d. I switched languages through time, but the base API is very similar, so, not much friction there. Because of that, I thought the transition would be rough, but I was wrong. Maybe the reason lies exactly in my previous experiences: the concepts were already with me, I just had to find my way around. Maybe that can encourage you if you’re afraid to try a new tool.
If you’re curious, check out the game I made, Roll FTW, on Game Jolt.
In this post, I’ll list some Unity advantages and also some pain points I had during the jam. It’s probably good noting that I’m not here to say one option is better than the other, I just want to share my experience.
Platform support
Cocos2d-x is popular for supporting many platforms. For me, doing just little hobby projects and experiments, its platform selection is more than enough. However, it’s not just about supporting a platform, it’s HOW you support it, and Unity kills it. Generating builds for Windows from OSX, and vice-versa, is a gigantic time saver. You can also automate all your build process, and then you’re in heaven.
Multi-scene
I used the ability to load scenes additively to separate the common game elements used during gameplay, so each level has a scene specifically to contain the scenery and to position the main game object (the ball). I have a scene just for the cameras, UI and some gameplay scripts. So, when starting a level, the “common” scene is loaded and the one with the level per-se is added.
I’m not sure if people tend to do this often. I liked it because a scene can’t “inherit” from another one, as I could normally do with cocos2d. The downside of this approach is that it’s harder to manage, having to constantly switch from scene to scene in the editor, and I can imagine how painful this could get with bigger scenes. However, multi-scene editing is planned and listed on Unity roadmap, and that will be awesome.
Level design and collisions
I had a hard time designing the levels, mainly for the colliders management. It took me some time to get a handle of the snapping commands/settings, and the current version of Unity doesn’t let you manually edit (by typing) values of some types of collider, so, custom script to the rescue.
I also ended up using Physics Editor, after modifying the integration script linked in the official website and then creating prefabs for the most used level parts. Honestly, using a third party app for this purpose left me a bit uncomfortable, as I expected Unity to offer some sprite tracing tools (AFAIK, this feature was removed, which is real bummer). Sure, the Asset Store must have something to fix this, but I didn’t want to spend more time.
Still about collisions, I didn’t figure out an easy way to prevent ocasional bumps when the main game object rolls on colliders intersections. It still happens in the game. I read about many solutions, but they didn’t suit the way I prepared the levels.
On this matter, I can’t compare Unity directly to cocos2d. The workflow I have with Tiled (after coding a routine to read the objects and generate the needed Box2d fixtures) is significantly smoother, but none of my previous games had levels with the shapes I needed for this game.
Simple animations
As I said before, the cocos2d framework family follows the same API base. One element of the API is what they call Actions. With these Actions, simple animations like a game title movement or a splash screen fading can be easily done through code, without the need for animations files, controllers, states, yada yada. Unity doesn’t have such a code-friendly animation tool/API, and iTween, one of the most referred options, is not simple as I expected it to be. When I learned about Coroutines (and had my mind blown a little bit), I could see some easier way to animate, but still, not so much friendly. I found some good implementations of cocos2d actions on GitHub (here and here), I just hope the repositories are maintained.
Game boy graphics and resolution control
For my game to have pixel perfect graphics, I used the package Pixel Perfect (such a creative name, huh?). It’s really simple to use, and I highly recommend it. Also from Pixelatto, Resolutioner helped me to offer palette selection in the game. However, the color swap was the only feature I used, because my problem with Unity’s resolution management may lie beyond the scope of this package.
Cocos2d-x (or cocos2d-js) has a feature called Resolution Policy. You can specify how your game “screen” will behave inside the window it’s being rendered. If you want your game to be letterboxed or pillarboxed, setting that up will be a breeze. Unity doesn’t have something like that natively, and I will miss this capability, a lot. From what I learned, the solution revolves around playing with the camera, but as many of the camera properties were being handled by the Pixel Perfect script, my hands were tied.
My workaround is allowing, through a nice little script, only resolutions with the exact Game Boy aspect ratio, and let the game be stretched in full screen.
Finishing up
Wow, this post turned out a lot longer than I expected! And I could still mention some other stuff (like the sometimes slow/buggy Mono Develop), but they’re already widely discussed, so let’s leave it to that.
I hope I can help someone willing to make the same transition. The Unity community is huge, and the Asset Store is full of tools and scripts to improve your workflow. Even with the obstacles I had to overcome, my next game will definitely be made with Unity.
And finally, if you happen to know a better solution for any of the problems I faced, feel free to drop me a comment!