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:

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.

Simple Achievement System in C#


Achievements are becoming more and more usual in games. They provide the player a sense of accomplishment and progress by rewarding them with badges that proves their skill and experience. Some achievements are simple and other require a combination of particular actions to unlock. In this article I show you how to make a simple Achievement System using C# and will demonstrate it using Unity3D, but this should be easy enough for you to port it to whatever language you’re more familiar with for your games.

Continue reading

Memtiles Development Status


We are on the final stretch!

The last art assets are being made. The 3D models are being updated and polished. The sound is being adjusted, and the game is being play tested on many different devices by many different people to make sure everything works fine when launching.

So right now is the most crucial part, the last tiny bits of detail that need to be polished. By the end of the week, the game will be in its final form, ready to launch. But first, I’m going to have to make some promotional stuff, like videos, image headers and icons, set up a website, and write a “press release” to send to blogs for possible reviews in order to advertise the game.

It’s been a long ride and hopefully all continues well as I have more games in mind to make πŸ™‚

The game is going to be released for Android devices first, then maybe iOS and WP8, for both mobile phones and tablets. Maybe later on I’ll release a web build but for now, this is the plan.

Cheers πŸ™‚

October Challenge.. Again!


Last year I posted quite enthusiastly that I was going to participate in Ludum Dare’s october challenge, which is “Finish a game β€” Take it to market β€” Earn $1”.

Back when I posted that, I had just found was Unity3D was and was amazed of how quickly I could do game prototypes. As you may know, I’m developing Memtiles and although I would love to say that I’m really in this year, it might be complicated. Anyway, Ludum Dare’s October Challenge is up again, so go for it!

I’ve aimed the end of the month to release the game. If everything goes according to plan, I’m going to have all the artwork ready, music, and gameplay. Then I release it, and make a marketing plan to advertise it. So I might not be making my first $1 this month, but hey, at least I’ll be finishing my first game πŸ™‚

PS: As soon as I have the final artwork, I’ll post some more screenshots. πŸ™‚ I can already say that the games looks nothing like the Beta version. πŸ™‚ Its much, much better πŸ™‚