Data Serialization on iOS with Unity and AOT Problems


Super quick tip!
I’ve come up with a problem when making a generic data serialization method in which I write my data to a binary file, which is an error that only occurs on iOS because it can’t run JIT ( Just-in-time ) compilation and/or AOT ( Ahead-of-time ) compilation because it doesn’t allow runtime code generation.

There are some answers on Unity Ansers, but this forum post had the same problem as I was, and there is a fix that did it for me, that’s on Unity Answers here with a pretty good explanation.

So, yup, my solution was to add that same piece of code on the file where I am invoking the code.

So just in case, I’ll leave this here for future reference. 😉

Variable Jump Height in Unity


In numerous games, characters have variable jump height. What this means is that the more your press the jump button, the more the character will remain in the air, or even jump a little higher ( think super mario games ). In this tutorial, I’ll show you a simple way to implement this kind of jumping in your games.

You can begin by making a new project, or create a new scene from a project you have in Unity. Add a cube to the scene to act as the ground, so you might want to scale it forward (z) and sideways (x), and finally add another cube to act as our player. By default, both of these will have BoxCollider Components attached to them, which is good, but our player will also need a Rigidbody Component, so we can use Unity’s physics engine. Note that if you add a Rigidbody component to the ground, make sure you have IsKinematic enabled and Gravity disabled, so it does not fall. On the contrary, make sure the player has Gravity enabled and IsKinematic disabled ( those should be set by default ). You should now have something pretty simple such as:
Screen Shot 2015-07-23 at 21.29.55

So, using Unity’s physics engine, how can we make our player jump? By looking at the Rigidbody’s documentation, we can see that we have many methods to add force, and we’ll use the normal AddForce, which takes a directional vector and a force mode. As far as direction goes, we’ll want the player to jump up, so we can use the local up vector from the player’s transform. For the ForceMode, we have Force, Acceleration, Impulse, and VelocityChange, and I will use VelocityChange for now.

In order to control how much I want my player to jump I need to setup some variables first, namely, I will need a jumpVelocityChange and isJumping variable. I will also store the reference to the rigidbody, that I will get in the Awake method.

Quick Tip: [SerializeField] is used in unity, not only but also, to expose private variables in the Inspector. Why don’t I just make it public you ask? Because I don’t want other classes to access those variables, they are meant to be private.

So now that I have those setup, I’ll set them on the Inspector. I chose to set _jumpVelocityChange to 50 to begin with and _isJumping variable to false. Now since we’re using the physics engine, we should apply our changes in the FixedUpdate and not in the Update method by default. Meaning that we will not need to multiply our force values by Time.deltaTime, since FixedUpdate always ticks at the same rate.

Now, to make the actual jump. In our Update function, I’m going to check if I click the left mouse button. If the left mouse button is pressed and I am not currently jumping, I’ll set the _isJumping variable to true, and add a vertical force to the player’s rigidbody.

This only will make the player jump when you click the left mouse button. But now when it falls down, you can’t jump again. Care to guess why? Because we haven’t set our _isJumping variable to false. So when should we do that? I’m going to go pretty simple with this, since both the ground and the player have colliders and rigidbodies, I can call the OnCollisionEnter method from my player, and when it’s called, switch the variable to false. I’m not going to add anything else now, and leave it like this, but ideally, you’ll want to check with whom the collision was made, if indeed it was the floor, for instance.

Now everything seems to work fine. You can jump, fall down, and then jump again. But what about the SuperMario style jump? You know, the more you press, the longer you remain in the air? For this, I need to setup three new variables, _startJumpTime, _maxJumpTime and _jumpAcceleration, so I can control air time and the acceleration force added during the jump.

I’ve changed the update method to include the “hold-to-jump-higher-and-for-more-time” behaviour, and updated the first impulse to add the start jump time. So your FixedUpdate method should look something like this:

This checks for a different Input method, GetMouseButton instead of GetMouseButtonDown. The first one is called whenever the button is down, and the later is called once, when the button was pressed. So we capture the long button press, check if we are indeed already jumping, and check the amount of time we have to allow this long jump. If all those conditions are met, we keep on jumping, giving a continuous acceleration. This time we use an acceleration instead of velocity change, so the effects is a lot smaller.

So now you should be able to have your awesome “Super Mario style Jump”:

Quick Tip: Notice the [RequireComponent (typeof(RigidBody))] on the top of the class. What this does is automatically add the RigidBody component to the object you are adding this class to. So if there is no rigidbody, it will automatically add it. This makes sure that whenever I call the component in the Awake method, I always get a rigidbody, thus avoiding future errors.

Here’s the final result for my game:

Simple UIImage Caching in Swift


This is a snippet of code that will cache images downloaded from an online source, and provide them when needed. I still have some work to do on it, but right now it works pretty fine.

I’m using a dictionary to keep track of the images, with their Base64 encoded urls as keys.

Example usage goes like:

PS: Also, that UIImage().loadAsync is an UIImage Extension method I have lying around :)

Change font weight by code in Swift


This snippet changes the current font of a label to a Light version of it ( in case it exists ). Font names are ( in this case, it was ‘.HelveticaNeue-Regular’ ) appended with their weight. So I get the font name, split it by ‘-‘, and take the first part of the split, ending with ‘.HelveticaNeue’. Now I just create a new font with the light appended to it, with the same size.

Lastly, I switch the font, and there you go.

SuperStems is out for iOS


SuperStems is finally released on the AppStore for iOS! After 14 long days waiting for approval, it finally passed and it up for grabs for free! There are already over 400 downloads and counting, and players are rocking the leaderboard!

I’ve setup a new website for SkyBelow, my new gaming studio.

Edit: I’ve been updating SuperStems since Unity5 was released, and all I can say is that it runs smoother and better looking with the new IL2CPP – converts C# to Cpp to increase performance -, which is awesome! So far I’m testing it on my device, but you should get the update in a couple of weeks. Just enough time to send the new build and get it approved again by Apple.

How to create a recursive call with Unity’s Coroutines


During the development of Super Stems I’ve had to deal with chain reaction. I started a battle with one tile, and if they win, the captured tile would start a battle, and this would happen recursively. For some reason, I have this battle method call on a different thread, in Unity’s terms, a Coroutine.

Now comes the question. How do I handle recursion with Coroutines? After looking around the doc and experimenting, I found a solution.

Here’s a sample code on how to make it work.

After calling the entry point to your recursive method StartBattle, inside, you have yield return a new Coroutine call to the recursive method. This way, the execution order will be correct. Try it out and see for yourself.

Output should be.


Super Stems Post Mortem


B4L4pozCYAAHAwj Super Stems, originally called Stems, started on a gamejam weekend, Ludum Dare 31. The theme was “Entire Game on One Screen”, which many people complained about, me included, since a lot of people were expecting the snowman theme to be chosen. Aside from that, once the theme was announced, I started to make Stems.

So what is Super Stems? Super Stems is a board domination strategy game. You have tiles and board slots. Each tile has three sides, a number attached, and adjacent sides on the board will battle. Upon battle, the higher number will win, and the losing tile will be captured. This is a simple concept that I stripped down from another game I’m planning, which has this basic gameplay with more gameplay mechanics, inventory and multiplayer in it. B4M3HkVCAAAjR2a But since I had only 48 hours to make it happen, I stripped it down to this. A few hours in, I had the tiles and placeholder models and ready to be used in Unity.

I don’t usually take much time in planning during gamejams, I usually go all in with a minimum planning and knowing what I must do and sort and solve problems as they arrive. But since Indies vs Pew Die Pie gamejam went really bad because from the lack of planning, this time around, I took some time to plan ahead and think of what I wanted to make.


So with my plan written down and my idea right fixed in my head, I started developing the game until I had basic gameplay done. If you asked me by then, how much more time would I take me to finish a minimum viable product, I would’ve said a week, maybe less, but oh boy was I wrong. First things first, the gamejam atitude of coding this and that without taking much care, because time is of the essence, is bad. I don’t use magic numbers, nor hardcode anything. I usually take care in writing beautiful and maintainable code. So for that end, I was good. On the other hand, I manually placed the grid and linked neighbors, one by one. Since the original grid had only 9 pieces, it was fast and did the job. Finding after a few days that some of those links were broken/switched, was bad tho.. Mistake #1.


But nonetheless, everything was in place, I had the grid, the basic Turn-by-Turn gameplay, basic animation, tile capturing, teams, score. I was just missing an opponent.. better yet.. an Intelligent Opponent. Making the Artificial Intelligence was hard. It was hard because of mistake n# 1, not having a generic grid, in which I could make the calculations required to make it easier for me. Having a properly made grid system, I could have made methods to make my life so much easier, but nooo.. I might have written the battle, capture, AI play code at least 5 times! And by this I mean, really starting from scratch. Taking pen and paper, putting it all in a new perspective. And every time I did it, something good came out of it. Every time it god better. Obviously by now, the 48h period had long gone. I was more like two weeks after the deadline, mainly because I was working on it part time, after work, 3 or 4 hours a day, and you can only do so much.


But still after those AI changes, it wasn’t working properly yet. I wanted to make it smarter. After another brainstorming session with pen and paper, I finally tweaked the algorithm to make it the way I wanted to. You can now have decent battles with it. It will lose, but also win. So far, from online gameplay and local testing, my analytics say that the AI wins above 60% of the times, so I’m ok with that. During that time, while I was trying to get the AI right, I kept changing the UI, textures and models. The images speak for themselves.


Right now the game is ready to be published. Its maybe not as polished as I would like it to be, but I have to release it, get feedback, and then I’ll see what I’ll do with it. I’m already thinking of other games I want to make. This is my second ‘board’ game. This one has a new gameplay type, which is good, since I always try to make new gameplay on each game. So I’ll be releasing the game in the upcoming weeks, hopefully this will get some players. At least more than my previous one.

Indies vs PewDiePie Gamejam


I’ve entered this week’s 72 hour gamejam hosted by Gamejolt with PewDiePie in which the top 10 games would be played by the man himself and broadcasted to the internets and his endless number of fans. As if making games wasn’t reason enough, having the chance to have your game broadcast to millions of his fans sure was another great one.

tl;dr : Didn’t finish the game. Still had fun.

So I’ve put up some time to make a game this weekend, starting on friday night (16 hours late), I didn’t plan much, booted Unity, Maya and Photoshop, and started to make stuff. I’ve came up with a small idea based on Boson X, and wanted to make a fast paced game. I started to model tubes or portals and a spaceship, and laid the foundation of what could be a level.

Screenshot 2014-11-24 09.31.36

First of, I set it all so the level would fall down on you, making the camera look up, it would give the impression of moving forward. I then changed it to side to side, only changing gravity’s axis. Which, again, I changed by making the player move so I would have realistic jumps, instead of moving the world.

About physics. I didn’t plan much of the stuff I wanted to make, I just did it on a necessity basis. So first I made a custom gravity to pull the ship back in the center after a jump. I had the world rotate instead of the ship due to jump + turning issues that would dislocate the ship to places I didn’t wanted it to go. I’ve later removed the jump and animated it, so I would have more control on the behaviour, which turned out pretty nice actually.

Screenshot 2014-11-24 09.31.52

I had a level, level parts, obstacles and items. I soon ditched the obstacles and put bigger ones with doors, changing the game mechanics. Now you would have to jump above the empty space in the doors. Which worked quite nice. At a certain point you would get enough speed and get to the end level and be warped to another one.

Unfortunately, I didn’t finish the game, due to lack of skill, the theme being highly abstract “fun”, mindset maybe, or just because I went to see Interstellar (which was aweeesooomee!!). Overall I worked around 20h on the game, which is not enough to make it. Mistake number one was to not plan. Eager to make something new and something move on screen, I jumped in, thinking, “mehh, It’ll be a small game, I’ll just make this and that, and it will all work”.. but nooo.. I did had to doodle my thoughts into a piece of paper when I was stuck. Mistake number two, take time to fucking plan your game!! Do not start placing things around without knowing what you want to do. Ok, I got it. Mistake number 3, due to the lack of planning, changing scope delayed progress, making it harder to see the end of it, and ultimately missing the deadline.

Screenshot 2014-11-24 09.32.11

Overall, it was awesome! I’ve not been making these gamejams for some time and it felt great. I’m not sad I didn’t finish it, because I’ve learned awesome stuff while making it. Now I guess, I’ll enter the next competition, letting this game go, since it didn’t struck me as fun, so.. it was a great run :)
According to, The 96 Jam with rules is next, and there’s always the One game a month, so I’ll see you around 😉