Postmortem: Jumpy Rope is born

MWU_Banner.1920x750
Standard

Jumpy Rope is an endless arcade jumper game for iOS, and on Android platforms, featuring low poly graphic style, customizable characters and simple gameplay mechanics.

Jumpy Rope was inspired from Final Fantasy IX mini jump rope game, which has Vivi play jump the rope. I thought it could be fun to have a small game that would bring back these memories. So from the beginning, this is what I wanted to game to play like.

pmjr_3

Art Style orientation

As for visual style, Crossy Road, Monument Valley where all people talked about, and for good reason, they look very good, and they play very well. I decided to go for the same direction and aim for low poly flat shading. I was really fond of the idea to have a small, contained environment. After browsing for inspiration, I found a mix of floating islands like Captain Toad Treasure Tracker. By now, I had gameplay and art orientation, so I started to work on it.

I started to work as I always do, gameplay first, so I focused on the jumping mechanism, which is the most important part of the game, making a tutorial at the same time for thatย ( which as evolved from the tutorial, and is was not implemented in the game ).

A week later I had a prototype which ugly models, art, and no polish, as prototypes should be. With a couple of polish here and there, and a couple of assets from Unity’s asset store, I tough I could make it, and release it. It wouldn’t be the best thing in the world, but having no team to work with, it was all I had. Luckily, I stumble upon this:

When I saw this, I immediately knew this was the style and islands I was looking for. After contacting @fifsilva and explaining the project, she jumped along to make a couple of floating islands for Jumpy Rope.

The game went from mediocre looking to awesome! I really love those tiny floating islands she made. This pushed the overall game quality, and I had no more programmer art anymore. All I needed now was characters. I met some people and then was references to others. I was lucky enough to get concept art and models from them.

Characters Concept

Concept art by Jenny Harder

At some point the game looked this this:

And then came the environments:

Couple of months later I was working on two player mode, while waiting for characters and animation ( by Guilherme Martins ), to be finished to be integrated in the game.

While waiting for assets from the team, I had made UI, a Replay System to save people’s games and replay them as ghosts ( never made it ), local two player mode ( was removed because people didn’t play it ), changed leaderboard system to be cross-platform and integrated with facebook, changed gameplay input based on player feedback ( twice ), and of course the api to handle all that stuff online. The UI took several iterations, I really think that at each step it got better, but at some point I had to close on a final version.

In the later stages of development, Pedroย Costa came in to make the game stand out with audio, sound effects and music. Now the game is freely available on the AppStore, and on GooglePlay.

Here’s the trailer for the final version:

In conclusion.
The bad: No planning whatsoever. I didn’t think ahead and plan the game through. I also probably should have got in contact with the community sooner, to ask for help or get feedback for the game. The lack of planning, made is easy to make ‘just one more feature’, that in the end, either didn’t make it to the final build or took way too much effort for what its worth.

The good: You always learn something, some new technology, new and better code practices, and most importantly, you ship a game! Jumpy Rope made me value planning, and careful consideration of features, what to kill and what to invest in. Get feedback early, get it out to the community as soon as possible.

That’s it for now.
Cheers.

Data Serialization on iOS with Unity and AOT Problems

Standard

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

Standard

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

Standard

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

Standard

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

Standard

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

Standard

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.

Enjoy

Super Stems Post Mortem

work-environment-superstems
Standard

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.

B4NwB0yCYAA60AN

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.

B4S5hSqCYAEo2QU

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.

B7bShESIEAEFEi6

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.

B9Hq3-fIgAA0Kj-

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.