Last post!

2016 is close to end and the same is happening to this blog ;)

Lately I have been working a lot but I haven't had a lot of time to write here, so I decided to move into a different format, I'm going to start sharing more content using YouTube. Also I'm moving to a new web page format, with a better structure for sharing my projects. The URL is the same: forestindiegames.com.

What I am going to share in my YouTube Channel? well, I will be uploading my current projects' progress. I'm about to publish the library I created for using your smartphone for 3D input suitable for VR, which I'm calling Muvslide. After that I plan to focus on Jumpjutsu. I'm still not clear how much I am going to share about the development as real game development is not always doing visually appealing things, and I really want to avoid spending too much time talking and making videos about making games, instead of... well, making the games.

Besides that I just started to record Let's Plays for indie games, the game I selected to start is Evoland 2. I must say I'm recording those videos in Spanish because it is just more natural. Also, indie games have some good coverage in English spoken Let's Plays, but Spanish videos are rare.

Thank you to all that followed this blog, let's see how 2017 goes in this new format!

Working in a VR tool!

If you check this blog once in a while, you may have noticed that I have not shared a lot of work about being progressing in my games, so yeah, I have a good reason ;). Besides my full time job I'm studying a Master in Computer Science, and as part of it I have been working in a tool for VR for my thesis.

The tool was conceived about one year ago, I did investigation and improved the prototype for a while. I must admit that the bureaucracy behind writing a thesis have delayed the process, but anyway it also helped to define some limits and dates, which is sometimes the hardest part when creating things on your own.

What I'm working on is an input method for VR, it is ready as a prototype but still not for the market, specially I need to write a nice API documentation so people can use it easily. I don't want to explain it in detail, there is a lot to say and probably it would better to do it with a video, so let's do that later, for now I will talk about the motivation behind it.

As you can read in my previous post, after analyzing the VR market I see that basically we are in the middle of a war, everybody wants to be the one that made the VR history, and that means that the big companies are really pushing to lead the VR scenario. However from my point of view, the market is still not that big to start focusing on particular visors as it is in the consoles market for example. So what I'm trying to do here is to push in a direction that could make more people to know and get interest in VR content, and I'm trying to do it with this input method focused on accessibility.

I still have a lot of work to do in my thesis, but hopefully I will complete it soon and will be able to concentrate in creating a good API documentation and sharing the tool with some developers. Stay tuned!

Where is VR going?

Lately there are a lot of us talking about VR or working with VR (I know, I haven't tell anything about what I'm doing with it yet :P).

I just want to share some thoughts about my point of view regarding how I see the market right now and trying to foresee what could come in the following years. To talk about this I need to talk about Google, Oculus (and similar), and some development tools.

I see there are two main branches on the VR big players. Those creating each time more powerful visors, with better sound and more natural interfaces. And those trying to use smartphones as visors, trading off a lot of power in exchange of portability.

In the first branch you find Oculus, HTC Vive, and similar. Visors with better resolution, better sound, better input devices, etc. They bet is to push the state of the art in VR technology, their market is the people with enough money to pay for "immersive" experiences looking to have the most realistic experience. We know Oculus is already taking some steps to have some exclusive content for their visor, and probably their competition will try to do the same (if they haven't already). For me, it looks like they are imitating the consoles war.

In the latest I/O (i.e. 2016) Google presented Daydream, and they told us exactly what they are trying to do: they are trying to make Android the VR platform. You don't need to be a genious to notice that if this works, Google has enough money to become the VR leader in the world, if they have the right platform with enough content and users, then it wouldn't be a problem to make a great powerful visor if they want. However, Google isn't trying to reach the niche market of the current Visors, they know it is not enough for them, they are actually pushing the market to actually have something to become the size they want, this needs more and better content, better smartphones (Daydream ready), and more people that have tried good VR so they know they want it.

Finally, the development tools. Unity and Unreal are happy to be tools that need just a little tunning to be the main development tool for the relative new and not so overcrowded as the indie games market.

So, there is a lot of people making (or considering to make) VR, development tools for it, hardware and platforms... are we missing something? yes! customers. Again, Google knows it, maybe others too, but Google is the one doing something about it, in my opinion, they were doing it in the "nice" way with Cardboard, and now in the "business" way with Daydream. And this is the point I was trying to reach.

The current market is a niche, many people talks about the "one time experience" of VR, i.e. for many people it's OK to use a visor to check a cool app, but for them it is not in any way the next big thing we think it is, and the reason is that so far the market seems to be following very simple ways of using VR: video games (yay), movies, videos, pictures... I'm not saying it's not good, but there is a lot of innovation that can be done with this technology, but we may need more people to play the "nice" way if we want the people to have enough reasons to want VR.

Let's see how things go, probably many big players still have some nice things to show, just let's hope we don't end up in a ill patent war, but with something that could help all of us to make some other nice things, because we still have a lot to do in order to make VR attractive for more people.

Analyzing Bomberman 64 multiplayer

I recently went to a Unity User Group in my city (Guadalajara), and in this particular meeting we were going to be able to show our games to the others, so I took Jumpjutsu with me and presented it. I haven't had a chance to update here my progress, but well, this entry is not about that exactly.

As you might know, Jumpjutsu is going to be mainly a multiplayer game. Currently if the player that killed other players is killed, the players he killed revive. Say Tom kills Jerry, and Itchy kills Tom, Jerry would revive. So only the player that kills all the others would win. It certainly could lead to infinite matches, but that could be solved by making the game more hostile (e.g. stronger items) or putting a timer.

Anyway, when I explained this, and explained the purpose of it: "keeping the players interested in the game, even if they died", multiple people said - "ah! like Bomberman!" - and well, even if it's not the same, I could certainly learn some things from Bomberman and improve my design. So I will make a quick analysis about Bomberman 64 multiplayer mode, writing it here will help my analysis, and may help you to notice some of the different elements of this game:

I played a lot this with my brothers and cousins when I was a kid, and I really enjoyed it, it was very fun and just remember playing it makes me want to play it again (it would be great to make a game that evokes that, right?).

Rules:

1. The main goal is to blow up the other players. The last player standing in a match gets a point, or if the 3 minutes timer ends, whoever is still alive gets a point. The player that gets 3 points wins.
2. The one that bring us here: when you die, you become a ghost. Ghosts can possess for a few seconds other players that are still alive, so they can posses the others and do things like dropping bombs close or run towards bombs close to explode. You are not able to win, but you can affect the results, and with a bit of lucky produce a draw. So, in some ways, losing is kind of cool because you don't have to fear dead, and can continue playing. Nobody stops playing!
3. Players can get power ups, the ones I can remember are bigger explosions, speedup, and red bombs. They were also some curses, for example make you bigger and slower so you are more likely to be in the range of explosions, another kind-of-curse is to catch fire, you would kill others when touching them, but blow up if you touch any bomb. When you die your power ups spawn from you and others can get them.
4. About the movements, you can place bombs, kick them, stop them while sliding, grab and throw them, and make them bigger.

In other Bomberman games, instead of having the "Ghost mode", you become a cannon that throws bombs from the margin of the map, however I haven't play that so I'm not sure how good it feels compared to the Ghost mode. The reason to have a different dynamic could be that those games are similar to the original Bomberman, i.e. 2D gameplay in a grid map... I don't know why people preferred that, I really liked the N64 version.

Making decisions

I'm not going to go very deep into game theory, but a fundamental piece of a game to be fun is to be able to make decisions. What decisions you can make in this game? well, some of them are:

Who should I attack now? Should I select just one? Throw some random bombs? Should I attack the strongest opponent? Should I throw a big bomb? Where should I go (which of these bombs is closer to explode)? What power ups I should take? What power ups I should not take? Should I look for power ups instead of attacking? What power ups I should try to take from others?

Many of these decisions are taken constantly and quickly in any point of a match.

Ending the game

There are multiple features to make sure the matches are short and fun:

1. The powerups play an important role in this game, the more power you have the easier is to kill others or to die, it is a balancing factor and helps to make the game more dangerous with the time. In Bomberman it is not rare to die because of your own bombs.
2. Also, there is a timer, so if you are being too coward, you know the others will get a point as well, you don't want that. The timer not only ends the game after 3 minutes, it is a trigger that injects sense of urgency to the players so they focus on winning the match.
3. Not enough? well, when there is only 1 minute left the arena enters in "sudden death mode", so the players can die by wall pressing, meteorites, or drawn, it varies depending on the map you are playing.

Variety

In this game you can customize the characters, selecting different heads, arms, body, and legs. They don't make any difference in the game, they only look cool :)... well also when you win a point you can here "yay!" if you are using custom parts.
There are different scenarios as well, I think there are 6 of them, each one has some particular features that make them different to the others, so the decisions you take are affected by them. This is important because otherwise you could easily feel all matches are the same.

Rewarding the winner

When a match ends you see this screen where the winner receives a medal, and you character does a small victory animation. When you get three points and win the game, you see a bigger animation, with music, etc. As a game designer it's easy to overlook this detail, but I believe it has an important psychological effect in the players, it helps to conclude the game, to accept who won and get ready for the next round, and specially to reward the player that won! Without this, win would not feel that good.

Conclusions

This analysis has helped me to notice some important elements I could miss in Jumpjutsu, so let me take note:

1. Decisions. Make sure the players have multiple decisions to take simultaneously.
2. Speed. The game must feel quick and exciting.
3. Rewards. I need to reward the winner! Also, reward the losers with a little fun.
4. Maps. I need to have multiple maps, and if possible, that affect the players' decisions.
5. Items or powerups. They don't just balance the game, they help to end it quickly!
6. Ending the game. Make sure the game ends, and don't fear to use multiple techniques for that.
7. Keep playing. Why just give the losers the hope of continue playing... can I make an interesting mechanic to keep the losers playing and having fun?

Well, I may be able to find some more interesting things in this game, but let's just stop here for now :), hope you find this useful!

Can VR replace reality?

Let me get a little philosophical today.

Besides my game projects, I have been working in one project which is related to VR and AR (Virtual Reality and Augmented Reality), even when such project is not ready to speak publicly about it, it has make me think a lot about the VR and the future.

An emerging philosophy

The other day I read a tweet of someone asking Stephen Hawking why to look for other worlds if we can create ours (#VR, of course). If you have been around some VR discussions, it's very easy to perceive a very common "philosophy" about how virtual reality is not different than actual reality. There's a popular quote: "Perception is reality" (Lee Atwater as per Google), and even when it was not said thinking in VR, it summarizes quite well this philosophy. It is a common believing in that, if we can make a Matrix-like immersive experience we would be pretty much making a different reality which should not be considered inferior to the actual reality.

Since we are still far to get into the Matrix, most of the people just think superficially about this, and it's comprehensible since it's very complicated even describe what reality is, even when we live in it. However VR is making people to reconsider the value of actual reality against the virtual one. This is not that new if you consider real guys getting in love with virtual girls, the difference is that VR is getting (and will continue getting) so convincing that people won't be able to continue just rolling their eyes with disapproval when judging these situations. Since the obvious fact that the girl is not real and that she is "inside" the video games console is going away, I think it's a good time to start conversations about this.

The problem with discussing about VR, is that you need to end up talking about actual reality, and the problem with talking about reality, is that you will end up talking about infinity and the inherent value of things... well, at least that is true for me.

At the end of the day we are talking about humanity

Let's imagine these 3 scenarios:

1. You and 3 friends go into a VR space adventure, you can interact with each other as in real life but you are inside this awesome immersive experience. You spend there about 2 hours a day and start to gather some resources and building a nice Neptunian cabana with video game consoles and an area for super-gravity volley ball.
2. You go alone into a similar VR space adventure, you are having progress and feel quite motivated to continue building your Neptunian house, feeding your virtual Neptunian cows and going for a walk on the planet. You don't feel the need of having a real pet because keeping your cows healthy is enough for you.
3. You go alone into this VR space adventure, but this time your 3 friends are virtual friends, you selected and customized them. You are basically having the same experience as in scenario 1, to the extent your virtual friends act as actual humans. You don't feel the need of having any friends in reality, actually you spend most of your time with your virtual friends.

I think most of the people would agree with having the virtual experience in scenario 1 (some would prefer to spend there a little less time though). Maybe a little smaller amount of people would also agree with scenario 2, it is pretty much the current scenario for those playing any one-player game. However, probably most of the people would not agree with scenario 3, specially if you tell them that the one playing that game will be their brother, friend, son, daughter, husband, etc. Many of us probably will just think of it as a very sad scenario. Living that scenario would be pretty much the same as imagining your life instead of actually living it, or live watching movies because you like the world in the movies more than the actual world.

So, when we did that big jump between amazing experience and sad scenario?

Replacing your goods with virtual goods is not that bad, actually it is ecological :). Taking care of virtual pets, don't feel that bad either, as long as you don't forget to food your real pet because of that. On the other hand, replacing people feels just wrong, but why?

Well, because it reduces the existence of the other people to whatever you perceive from it, and means that you could just use people as objects to satisfy your personal needs, which is pretty much what the worst tyrants in human history did (and do). I know some of you are thinking that we actually do that very often, but I think we do it only to some extent and in a kind of subconscious way, and we actually believe that other people is important... Okay, at this point I will be positive and think none of you is thinking that humans are not more than a bunch of chemical reactions, with no significant difference to a match burning, and human rights don't have a reason to exist at all, please don't burst my happiness bubble, OK?

But, perception is reality... isn't it?

I may perceive something about you, and you may be perceiving something about me, but whatever my perception about you is, you are certainly more than that, reducing your entire existence to what I can perceive of it, is a very simplistic way to understand the reality. We cannot know if anything is real besides what we perceive, but using logic we can understand that the reality is more than us and our perception of it, we can understand that the world is not being back-face culled and that the whole place we are in, is being "fully rendered", not matter if you are looking to just a part of it.

At this point we should be able to start to descry a fundamental difference between VR and actual reality. VR is all about perception, the very purpose of anything created in VR is to be perceived (and understood) by people. On the other hand the actual reality is there and is happening even if nobody perceives it, it is much more than what we can perceive and understand about it, and its very purpose could make us to start discussing about religion. From a mathematical point of view, as per Gödel Incompleteness Theorems and surely some others, we know we are limited to understand the universe completely, because our main tool, Math, is incomplete and can't be completed. VR is created by human intelligence, so it will never reach a point where something in there is not understandable by human minds.

Finding a place for VR

We can see at this as a Set Theory case. VR is a subset of actual reality, even when the amount of possible virtual worlds is infinite, actual reality is a bigger infinite that contains all those infinities (google "bigger infinite" if that sounded too weird). So if the virtual universe gets bigger and bigger, it won't ever absorb the actual universe, it will only make the actual universe larger because it contains the virtual universe.

So it will be good to start thinking of VR as part of actual reality, just as Internet is part of it. Let's don't get confused because of the convincing graphics and the stereoscopic vision (and whatever comes next). VR is great and we don't have to make it to compete with actual reality to make awesome things with it.

So my proposal is to don't bother Mr. Hawking with all this, let's physicists do their job and let's make ours, we are doing really different things.

An exciting journey awaits

I'm very excited to see what the future will be and how VR and AR will transform our lives, and even more excited of thinking on contributing to it. I feel we are still very far of having a VR convincing enough to make people start wondering about all this. But, if you are thinking in contributing to the VR "state of the art", you need to start thinking in the final goal, we are making a powerful tool here!

Will it transform the entire entertainment industry? will it disrupt the capitalism itself? will it be useful for medicine? will it help to give people hope? will it help us to enhance education? [hype intensifies] will it enable us to feel we are Super Saiyans?!! Man I hope so!

I feel something big is coming, and certainly it could be dangerous, but humanity drama is surviving its own excess of power, there's nothing wrong with that, it is in the very core of humanity, so let's push harder and see how far we can go, surely we can make incredible things!

Unity: Load image in sprite, from resource and from file

I cannot waste the opportunity to post something in Feb 29th :), so I will go a little technical and share something I did recently in a Unity project.

If you want to load an image in a sprite programmatically, one way is to have your image file in a folder called Resources. This is to load an image file (i.e. PNG, JPEG, etc), not a prefab or anything like that.

If not already there, create Resources folder inside your Assets folder, Unity knows it is an special folder. So let's say you imported you image AwesomeImage.png into that folder. Now in your scene create a sprite: GameObject > 2D Object > Sprite (in Unity 5.2). Then you can create a C# script like this and add it to your sprite.

public class YourSpriteScript : MonoBehaviour {

    void Start()
    {
        ShowIcon("AwesomeImage");
    }

    void ShowIcon(string imageName)
    {
        TextAsset asset = Resources.Load(imageName) as TextAsset;
        byte[] data = asset.bytes;
        Texture2D texture = new Texture2D(128, 128, TextureFormat.ARGB32, false);
        texture.LoadImage(data);
        texture.name = imageName;
        Sprite icon = Sprite.Create(texture, new Rect(0.0f, 0.0f, texture.width, texture.height), new Vector2(0.5f, 0.5f));

        SpriteRenderer iconRenderer = GetComponent<SpriteRenderer>();
        iconRenderer.sprite = icon;
    }
}

In some special cases you may want to load an image which is outside your Unity project, you normally would want this if you want the final user to change set any image she wants into your game. There are of course other ways to do it, this is only one of them that could work for cases like those when you want to allow others to make mods of your game by replacing some images.

To do it, use the following code, it will load the image from disk. So, again, this is the C# script you could add to an specific sprite:

public class YourSpriteScript : MonoBehaviour {

    public void ShowIcon(string iconPath)
    {
        byte[] data = File.ReadAllBytes(iconPath);
        Texture2D texture = new Texture2D(128, 128, TextureFormat.ARGB32, false);
        texture.LoadImage(data);
        texture.name = Path.GetFileNameWithoutExtension(iconPath);
        Sprite icon = Sprite.Create(texture, new Rect(0.0f, 0.0f, texture.width, texture.height), new Vector2(0.5f, 0.5f));

        SpriteRenderer iconRenderer = GetComponent<SpriteRenderer>();
        iconRenderer.sprite = icon;
    }
}

As you may see, the code is very similar, once you get the bytes from the image you create a Texture2D from it and use it to create a Sprite object which is set as the sprite of your Unity sprite (actually, a SpriteRenderer).

Consider that better than set this script in each sprite you could modify it to make a more generic version that receives a reference to the sprite and the name of the file to load, and have one single script that is called to load multiple sprites. Also you will need to investigate how to use relative paths so the game works in any computer.

Hope this helps in whatever you are tying to create! Let me know if you need additional help.

GGJ 2016 - The full story

It has been about 2 weeks since the Global Game Jam 2016. I must say it was really cool and very different to GGJ 2015. Here's the full story.

GGJ?

Really quick and incomplete explanation for those not familiar with GGJ. It is a world wide event where people create games about a specific theme that is revealed at the beginning of the jam (Friday), and in 48 hours you must have completed and uploaded your game.

It's not a contest, it's just for fun, it forces people to complete at least a quick a simple game instead of spending years improving a single one that will never be released (ok, that was for me), and because you know other game developers (a.k.a. networking).

An interesting part of it is that in order to enter the jam you need to go to a registered site (yeah, physically), which is just a place that can provide what is required for the event, i.e. electricity, Internet, desks, enough space, bathrooms, and in some cases some other vital nice-to-have things like coffee or pizza.

Going alone?

Compared with the previous GGJ for this one I was going alone, even if any of my friends would have gone, from GGJ 2015 I learnt that I didn't make any networking because I was really busy completing BARKH, so if was going to go to GGJ 2016 I was going to join a random team.

So yeah, I was a bit nervous because I didn't know in what kind of team I was going to end up! To make matters worse, there were 6 sites in my city... is that bad? well, the amount of developers here is not THAT big to require 6 sites, so instead of having 2 or 3 big sites, we had 6! This is not good because you have a smaller probability to find a good team, or to move to another team if you don't manage to fit in your first team. So yeah, somehow people here lost the point about the networking thing and decided to make a bunch of smaller groups :\, in my city were 6 of the 20 sites in Mexico.

But OK, I decided to be positive and go to the site closer to my house.

Joining a team

So there were I, very early as usual, this was not that new for me. You arrive, register, and put a sticker with your name and with your skills (using a color code), I labeled myself as "game designer" and "programmer". There were a few people, I took an empty table and played a while with my Jumpjustu music theme waiting for the event to start. After a while there were about 6 tables full of people, some guys joined my table too and the organizer asked us to make a "quick" group bounding dynamic. The guys in my table were a team already, I was the new guy there and I was not totally sure if I was automatically in their team or not... it was a little weird.

After that, the organizer asked who had no team, so I raised my hand... (I think, but I'm not sure, someone made some weird noise indicating I was betraying the guys in my table). So the organizer asked "who needs a programmer?", after about 5 seconds that felt like 60, a guy in another team raised his hand and I joined his team.

When the Jam ended I found out the guys I "betrayed" were from One Simple Idea @1simpleidea, creators of Mucho Taco a fairly successful game for iOS and Android, that got quite good rankings in Apple Store.

So, did I miss my opportunity to join a great team?

The answer is no.

I moved my backpack and sit with the other guys. They were going to be my team for the following 48 hours so it was time to know who they are. I must say I ended up having a quite nice team!

• Programmer: Marlon, works in Cosmogonia @CosmogoniaGames a known game development company in Mexico (for those related to game development), and previously worked at Gameloft. He has some years of experience in Unity.
• Conceptual designer: Mónica @moni_red, she is a Marlon's friend. She didn't know about making games but is very good drawing.
• Music and sound: Ricardo @inkeyesmusic, he is a musician and works in KaraOkulta another known game development company in Mexico.
• Pixel artist: Luis Zuno @ansimuz, he is the creator of Elliot Quest, a known indie game that was released in Ouya, Steam, and WiiU! He is an awesome pixel artist.
• Another guy: He left on Saturday, I hope he never read this haha.
• Me :), another programmer.

Marlon, Monica, and Ricardo went together to the jam, all the others had never worked together before.

I'm going to be honest, being creating a game together with Luis Zuno was really awesome for me. Other guys in the team didn't know about Elliot Quest, but I had already heard of it, and saw it in a Nintendo Direct. I'm not sure how to explain why this was so awesome for me, but let's say that if I could have a game I created to show up in a Nintendo Direct I could just die in peace haha. So I was just eager to talk with him about how it was to release a game in Nintendo and ask for any advice he could give me in general.

Working with the theme: RITUAL

They revealed the theme before I had my team, so when I heard "Ritual" I honestly didn't start to think anything, I was more interested in finding a team and work with them. So once I was with my team we started to throw some random ideas and write them down in a whiteboard.

After some minutes we were kind of close to make a game about a witch that summoned ghosts with OCD... it sounded fun but something didn't feel right about it. Also the playable part was not quite clear so we continued exploring some other ideas.

I don't remember many of the other ideas we analyzed, but somehow we ended up talking about an African shaman defending his village, we all in the team were happy with the idea. It was a little inspired in Patapon but the core gameplay was actually quite different. It was going to be a tower defense, were the tower is you village at the center of the screen, and enemies come from different predefined paths to attack it. The player must use combinations (shaman dances) to summon magical attacks on the roads and stop the enemies.

There were still some things that were not very clear about the idea, but we agreed in create a prototype and then we would decide what was right and what wrong.

TIP: In a game jam you can waste a lot of time planning, but a quick prototype will help to understand how much you can actually achieve in the remaining time you have.

Let's work

We were divided in 3 groups, graphics, music, and programming.

Monica created some concept art that later Luis converted into pixel art:

Ricardo pretty much worked by himself :), once in a while Marlon explained him what sounds we needed, and others in the team gave some ideas of how the music should be.

I don't have much detail about how the music and graphics side happened, so let's talk about the programming side.

Organizing the programming side

This is what we did and worked very well. Consider this an advice on how to organize the programming work in a jam (some things are Unity specific):

1. Create a Github repository (Github has a nice helper to create the .ignore file required in Unity projects to avoid adding files not required).
2. Enumerate all the sections of the game you need to program: the screens, the input manager, the enemies, the different attacks, and so on.
3. Enumerate all the Unity prefabs you need to make. As a matter of fact, most of your game's components should be prefabs.
4. Create a scene per developer. Each scene is modified only by the developer assigned to it.
5. Create a main scene to put all the completed parts and see how it works, once in a while you can just copy all its content into your personal scene.
6. Have a lot of communication about modifying shared files, make sure to don't overwrite others' work.
7. Backup often. You don't know if something really bad is going to be pushed to the repository.
8. Sync up often. Waiting too much to pull others' work is a recipe for disaster.

A lot of this organization was Marlon's idea, probably because of the experience he has. I was learning everything I could!

First prototype

After one day, on Saturday evening we already had a first playable version.

It sucked.

It was totally unplayable, but it was fine, we had enough time and some of the flaws in the gameplay were quite clear for me. Personally I feel that my contribution was important for this. Let  me quickly discuss some of the problems with this first prototype.

The enemy rate

The enemies appeared in a constant rate, this was a huge problem, you need to give the player moments of excitement and moments of peace, so she can organize her ideas in the moments of peace and prepare for the next encounter. If you just throw enemies in a constant rate the player gets overwhelmed. This is used in almost any tower defense game, e.g. Plants VS Zombies, maybe you are always under attack, but there are some times that there are only a couple zombies, then they let you know a horde is coming and you get ready. Beating the horde is satisfactory to the player, so she gets more engaged and willing to confront the next horde.

The controls

In this first prototype the game was played with keys A, S, D, and F. They felt weird. To make matters worse, the combinations you needed to do for the different attacks were randomly generated every time you played.

Ricardo pointed out that ASDF didn't feel good when he played, so we changed them for the arrow keys, also we removed the random generator and made the combinations related with the position of the area to attack, so it was much easier for the people to get the idea of what they needed to do. For example to throw a Fire Attack at the top-left corner of the scenario the combination is Up + Left.

After that Marlon's wife (that was there at that moment) suggested that the last key to select the attack should be different to the arrows. I had the same feeling but somehow changing it sounded like a lot of work for the remaining time, anyway her opinion was the push I needed to go for it, I proposed to use keys 1 to 4, which is more intuitive in my opinion. So the combinations ended up being something like: Up + Left + 2.

To make it crystal clear for the players I suggested to make the Title Screen to use a combination to start. I got the idea from Depict1, a game that introduce the game mechanics in the very first screen. So we did so, and did the same for other screens.

Visual feedback

All of us were aware that there were still missing parts in the first prototype, but we underestimate how important was to clearly show the paths the enemies were going to follow. Also the enemies didn't show any reaction when they were attacked, so you couldn't know if what you were doing was working. After we added those effects it became much easier to play the game.

Initial design ideas

One of the initial ideas was that you were going to have 3 spells to cause damage, and one spell to recover health. The player was supposed to use the one to recover health when the village looked sick, but if the player would use it against the enemies by mistake, the enemies were going to become more resistant.

At some point we dropped the idea of the village status, but we still had the spell to recover HP to the enemies. I needed to argue with some of the team members about removing it because it was extremely confusing. There was some idea of using it against undead enemies in order to kill them, but it was clear those enemies were not going to exist by the time the jam completes. So after some arguing we agreed to make it a different attack, one that makes no damage but makes the enemies really slow.

The final day

We had a lot to fix, and we actually rushed to complete all the changes we needed to make, but anyway we managed to have some time for polishing. Ricardo's music really fitted the art style, and it was very catchy as well. We fixed some bugs, added the final level (that you must see ( ͡° ͜ʖ ͡°) ), added the music and sounds, added the credits screen, added the drawings for the title screen and game over, and tested some times the whole game.

As always I asked people to play the game without telling them how to play, and it was very satisfying see they got the idea quite fast.

Marlon exported it to WebGL and uploaded it. I uploaded it here too because in this way I can make sure that the game is up and running as long as my site is up and running too.

The Presentation

We presented our game to the other teams, it was quite satisfying because the game feels complete and fun. Latin America's Unity promoter actually recorded the presentation (it's in Spanish, I'm the guy using a blue shirt). Other teams made interesting games too, you can see here the other games created in the same site, however many of them are not playable via browser.

It was an amazing experience, definitely going alone and know new people was a good idea, I highly recommend it.

You can play Shaman Defender here, and drop me a comment if you want.

Epilogue

I saw my team again when we presented the game in our city's Unity User Group. I got some feedback from Ricardo about my song for Jumpjustu and I'm planning to continue going to the group meetings.

~ The end ~

Jumpjutsu music theme!

I need to sit down and write the great experience the Global Game Jam 2016 was, but I don't have much time now, so instead I want to show you the music theme for Jumpjutsu!

There is some chance I could make some changes to it, but I must say that considering I'm not a musician I'm very satisfied with the result. I tried to transmit some sense of action and fun, obviously with a Japanese-like style.

It loops nicely at about second 6, but you will need to wait to hear that in the game ;)

Selecting a name for my game!

I had been thinking A LOT about how should I call this little ninja game, it should be a catchy name, easy to pronounce, related to the game, that transmits multiplayer fun and the kind of cartoon style the game has.

One rule I decided to follow is that it must be short, one or two syllables, if it has more then it must be rhythmic or rhyme. The basic test I'm using is thinking in me asking some friend: "wanna play some <<name>>?" or "have you ever played <<name>>>?"

So I came up with some names, and applied a poll with some friends. I asked to vote for two in favor and for two against. These are the results I got:

1. One Lap Attack [+1][-3] = -2
2. Lap 'n Attack [0][0] = 0
3. Lap and Attack [+2][-1] = 1
4. Leap a Lap [+2][-3] = -1
5. Wall Jumpers [0][-1] = -1
6. Jumpaloop [+1][-2] = -1
7. Jumpjutsu [+7][0] = 7
8. Runnup [+5][0] = 5
9. Ninja Climbers [+2][-2] = 0
10. Round Around [0][-3] = -3

Proposed by voters:

1. Leap 'n Lap
2. Leap Attack

Some people just voted negatively for "all the others" but obviously I can't count that.
Advice: if you wanna know if your game's name sucks, just go ask people, at least my friends were incredibly fast to detect those names they hated :).

I must admit I was considering "Lap 'n Attack" seriously, but I cannot ignore that it was the one everyone was totally indifferent!

So obviously Jumpjutsu and Runnup won the poll. Jumpjutsu is good because it relates easily with ninjas, and I would say the game itself is about mastering the art of jumping. I think it's easy to remember as well. Even though, I must admit some times I struggled a little to pronounce it.

Runnup is good because is short and simple, but I'm not so sure how much it reflects the game style, and also it is used by native English speakers as per my Google searches, so it may sound very generic.

So, I won't spend more time going back and forth with this, so my little ninja game from now on will be called: Jumpjutsu!

Yay! :D

Ninja Game progress: Sword up / Gravity change / Temp graphics

OK, to after a good trip through Japan I'm back full of energy to keep up with this still untitled Ninja Game :D.

I created this gif to summarize the game progress so far:

Here you can see the gravity change between corridors, it was a little tricky to achieve but I hope to don't need to touch that code again for a while ;). Also I added a new technique to avoid losing speed when moving between corridors, basically the player can raise up the katana and redirect the ninja's speed to the next corridor.

You can see as well some new graphics, I reused a background I created once in Xololitos, I'm still trying to figure out what I should put as the corridors' backgrounds, but for now this should be enough.

What's next? Well in the gif above you can see how the ninja runs practically the whole upper wall, that's not supposed to be like that, I want the player to keep jumping constantly, so I need to make the phases of the wall-run dependent of the ninja's speed... maybe it's not clear now, so I will just make it and post it once done :)


Bonus picture, check out this cool fountain we saw in Fushimi-Inari!