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!

I'm still alive

Hey, it has been a long time since my last update. I have been working a lot in a project I can't share at this time, it is related with 3D stuff but it is not a game. I think I can write a lot of programming topics about that once I have a little time, maybe about multi-threading, network sockets, Android, or maybe about Unity shaders. In fact, I just understood I don't know anything about shaders and I need to learn lot, so I could share some things while I'm learning.

I won't have any updates for like another month because I'm traveling to Japan :D, they say traveling broadens one's mind so I hope to come back full of energy and new perspectives to continue working on my projects.

This is just a small update so you don't think I'm dead or something. Aaand... maybe it's too soon but, merry Christmas and happy new year!

Game progress: Ninja climbing and jumping

I shared this in Twitter but I forgot to put it here as well :)

I improved a little the animations since I uploaded this, and I also had some good progress in programming the missing parts.

I will share later more progress, now I need to tweak some actions to help the player don't lose much speed when moving from a corridor to the next one. I have some ideas but better to go back to work and test them!

Ninja Game progress and Twitter account

I have been working on this -still unnamed- small game, let's call it Ninja Game for now.
I created this simple minimalist red ninja in 3D, its animations, and worked on the wall-jump programming. Everything going good so far.

Now I need to program some of the most difficult (and bug prone) parts of this game. Based on the section of the level you are, the gravity will change and controllers will change with it. Let's say the gravity is going from right to left (instead of going down), the controllers must now change so the player needs to use up and down directions for wall jumping (instead of left and right). If it was not clear don't worry, I will upload a video as soon as I get it working :).

Going to other breaking news, now I have Twitter account @ForestGameDev!
I know what you are thinking, but let me clarify that I had a personal Twitter account I never used (I just didn't find it interesting). But now that I'm being a little more "social" about my games and projects, this account has a little more purpose and it's interesting to follow some other indie game developers and projects as well.

Also I'm working on some changes for this site, but there's no point in talk about that, better continue working on them and eventually you will see ;).

I will share soon a little more of Ninja Game!

New (mini) game in process

First, I'm not abandoning Ascendam, I've been programming a little of its main mechanics and I thought I will need a lot of feedback to make them feel as good as I want, so I decided to make a small game based entirely in Ascendam's wall-jump mechanic.

Besides I think it is kind of simple game I have had a though time explaining it to a couple friends, that sounds kind of a warning signal so I'll make sure my prototype is very clear about what the game is about. All what I'm going to say for now is that it will be local multiplayer game based on wall-jump mechanics.

I'm really exited about start prototyping it, I already have some code from Ascendam and I decided to use very simplistic art style... I haven't had very much time for game dev lately, however will do my best.

I drew this characters in Pixly... then I noticed I could make them directly with Unity basic objects haha, so probably I will use this only as a guide to make the 3D ones:

Pixly did something weird with the original colors (eyes should be black, and the sword doesn't change), but it's fine, it looks kind of cool anyway haha.

Song: Ascendam Theme

Around one week ago (or two?) I was working on some sprites for Ascendam when I realized I still needed to define a little more the "look and feel" I want this game to have, so I decided to give another try to compose a song that would reflect the dynamic gameplay I want to create.

I did a little search and found this awesome music app for Android called Caustic 3 (I think it also exists for iOS). It is not free but it really worth its price (actually I didn't find any good free music app). Anyway, maybe I could write about the app later, today I want to share this song that I composed for Ascendam's title screen. It took a little more time than normal because I was still learning the app, and I had little idea of what kind of song I wanted to compose, but after some tries it started to emerge by itself.

I was thinking in a style similar to the music in Mega Man X3. However as I have said, I'm not a born musician so I'm still pretty far to compose something that awesome. Anyway I believe it's good enough and now I can imagine a little more how dynamic the gameplay should be, as well as the movements I want Anz (the main character) to perform.

I uploaded two versions, one is just the song, the other is the looped version. I uploaded both because the loop is not expected to start at the beginning of the song, so I pasted the song 3 times as I want to make the loop to sound in game. I'm sharing here the looped version, the original one can be found in my soundcloud profile.

I hope you like it!

Doing some sprites with Pixly

Lately I have been very busy and it has been a little difficult to spend time in Ascendam, however I have a few new Anz sprites and have been tuning (in my mind) the game mechanics.

The first sprites I created for Ascendam (the ones in my previous post) I drew them using an Android app called IsoPix. It is a nice not too basic pixel art app and I thought it was quite good actually. I was planning to purchase the Pro version but the problem was that it doesn't support animations. Is that big deal? well, yes. If you want to make the different facing directions of a character, they will probably look weird if you don't test how the transition between the main frames looks (I will try to write a post about that in the future).

So when I was really close to purchase IsoPix Pro y found this great free app called Pixly, and believe me, nobody told me to write this, but Pixly is far FAR superior than any other apps I found in the Play Store, I don't know why it is not the first app that shows up when you search for "pixel art".

What is so good about Pixly? well, if I would need to say it in once sentence it would be: it satisfies a game developer's needs. I'm not planning to make a full review because I actually haven't used all its features yet, but you can take a look to its website, there are short and concrete examples of its features.

The things I like most of this app are:

1. It supports layers, so you can draw the movable parts of your sprite in individual layers, and later animate them easily.
2. It supports frames, so you can make animations and export them as animated GIFs (or as a PNG sprite sheet).
• This is really useful because instead of make a huge sprite sheet that contain all your frames, you create a single frame, let's say 128×128 px, and you can navigate between frames using the timeline menu, and reorder, copy, delete them if you need.
• It still can improve in this side, being able to select the frames and save multiple animations would be really useful for complex characters. Also the animated GIF I exported didn't display the colors correctly, but maybe I did something wrong (I have only tried a couple times). Anyway you should check if the latest version coincide with what I said.
3. It supports configurable grids.
4. It supports to load and save color palettes.
5. It supports two techniques for rotation which is very useful.
6. It can export your work to a sprite sheet, and it will only export the layers you have selected as visible, so if I want a sprite sheet with only the heads of Anz, I can export it easily.
7. Zoom in/out is smooth and not limited (other apps support some specific zoom levels only)
8. It has a lot of undo/redo steps (I'm not sure how many, but they have been enough so far)
9. It has mini view window, i.e. when you are working with zoom in a specific part of you sprite you can see in real time how it looks in another zoom level.
10. It has have mirror transformations, magic wand, color replacement, and so on...

Oh, and almost forgot, one thing Pixly does NOT have:

1. Annoying ads ;) ... it only shows an ad when you save.

I don't want to insist too much in how good this app is, but I feel really happy with it because I can have some progress in my game while going on the bus, or waiting for any reason, and for free! If you are looking to make sprites for a game I highly recommend this app.

Here is a side view of Anz I drew in Pixly. You can see the layers at the right side, that menu can be hidden so you have most of the screen available to draw.

About the sprite, maybe I will change a little its legs but I'm still not sure, I prefer to make some other positions required to start programming and experimenting the gameplay.)

I will be working on sprites for a while, I hope to have time to update my progress here.

See you!

Ascendam - Characters concept art

Last entry I was talking about making games that fit your personal style, so after a little more than a week rethinking my "mysterious" game, I finally got to the point I think I really like it :), I decided to call this game "Ascendam".

I have been working mainly in the conceptual art for the characters (back to the pixel art :D), the game story, and a little of game mechanics.

This is Anz, the main character:

I want this character to be an avatar for the player, I mean, I want Anz to be a representation of the player in the game in a personal level. Because of that I don't want to create a deep detailed description of Anz's personality. Later if I have time I will make a female version, but for now the male character should be enough.

Anz will use a spear as its main weapon, later in the game you will get bombs as well. Those are his weapons so far, but I'm not sure if I will add any other in the future.

Well maybe it would be good to explain briefly the gameplay now so the enemies make sense to you.

The main idea is to "fall" through tunnels in a labyrinth, Anz will be hanging of a kind of rope so you will be able to control how much you want to go up or down, you will be able to grasp the walls and climb faster than climbing by using the rope only. Also you will be able to move down faster by running down on the wall (ninja style!).

I'm planning to have 4 enemy types. Probably I'm going to add different difficulty levels for each of them, but that's not yet clearly defined.

First the basic enemies, you will find this little guys climbing on the walls of the labyrinths, they are harmless if you keep away from the wall. I call them Walldos.

The Guardians, you will find this guys flying through the tunnels. At the beginning they won't attack you if you grasp a wall, but in future levels they will use their flexible arms as whips.

Cloud Crowds, you will fear this creepy enemies. They will be flying through the tunnels as well, but you won't be able to attack them. They will be moving in a rhythmic way opening their eyes from time to time. You won't want them to see you.

Smiley Gear, this will be a fundamental enemy in the game mechanics, those will be static enemies that you will need to destroy in order to progress through the maze.

I hope they intrigue you a little :). I will be working on the scenarios (I need to experiment some ideas to have scenarios that I can realistically create) and programming the basic mechanics, so I can know how fun they actually are.

See you later!

Style checklist

After a very busy month I took a few weeks for relaxing, now I think it's time to return to game development!

I had a kind of weird (new) experience about game design in the previous weeks. I have been thinking in the "mysterious" game I'm planning to do (I swear I will decide soon a provisional name!), but while I started to think about the game and the universe where it unfolds I often ended up thinking on an old game I used to make; an adventure game, with heroes, magic, fights against monsters, and so on, a kind of classic game that really inspires me.

The plan for the game I'm working on right now is different, I was thinking on making a deep psychological game, with a kind of weak and vulnerable main character. If you read my previous post I had the main music theme for the game, and I was looking to make a sad and unpleasing song with just a little light of hope. The problem is that I was having a hard time to imagine the universe for this game because I just couldn't concentrate very much on it.

This days off helped me to realize the reason why I couldn't concentrate in my new game and why I often ended up dreaming about my previous game. It seems obvious for me now: depressing games are just not my style!
Don't get me wrong, I'm not saying I never will make a deep psychological game, and that I will always going to make games about magical heroes and adventures, I just need to find my way to make the games, if they are deep and psychological, or simple and funny, it doesn't matter, there should be a way to make them on my way.

It's cool, because some artists use to look for a style - their style, and I feel I'm starting to develop a better perception of what my style is. I have decided that, even if I'm looking to create some simple games to grind some game-dev exp. points, I won't start any games that don't match with my style, at the end of the day, that is the greatest thing of being an indie game developer!

I developed this small checklist to analyze before starting any projects, I put it here for my own reference, but maybe it could help you too if you are a gave developer. From now on, I will ask myself the following things about the game to make:

1. Do you like how the game would look in your personal portfolio? Would you feel proud of showing it to other people?
2. Does the game inspires you? Do you find yourself imagining some cool scenes about your game?
3. Is the game compatible with you? The idea could be cool, but maybe what you want for you as a game developer is not really going in that way.
4. Are you eager to play your game? (If you are not, then who?)
5. Would you find interesting the experience your game provides? (think that interesting could be the feeling you want to transmit, for example fun, suspense, etc)

Probably there are a lot of other points you could check, but for now I'm going to focus in these 5 points. Even when those 5 points seem to be very basic things, somehow I was just missing MOST OF THEM!

Let's see what I can think and create for this new game, hopefully my next post would show some results!

Title song - version 2.0

I continued working on my song "Opening Mystery" which I think I'm gonna rename because it is not a mysterious song, and it's not for an Opening either :P. The song now has 3 parts (forgive my lack of musical vocabulary).

The first part is an introduction with an arpeggio, a background chorus, and a bass, which is used in most of the song. The second part has a kind of darker/sadder style which I wanted to add because the game I'm planning to make with it is supposed to transmit a kind of uncomfortable feeling (but let's talk about that later). The third part has a different feeling, it is supposed to transmit a little more inspiring feeling, like raising from a moment of sadness. The final is a little abrupt because the song is supposed to work as a loop, however I think it is enough "final" to close the song when played once.

Based on the previous version, some of the changes I made are:

1. I modified most of the melody
2. Extended the song by adding the "second part" mentioned above
3. Added a chorus
4. Reinforced the arpeggio instrument
5. Added a "second voice" for the melody.
6. Modified some of the base instruments.

I think I'm gonna use this song as the main theme for the game I'm planning now, it is already helping me to define the look and feel that could work with it and with the game story. I want to reuse this song a lot in the game, I have noticed that some games do this very often, for example you can check Super Smash Bros. Brawl, it is obvious that they took the song from the opening scene and reused it in different ways, in the menus, in the one-player mode, and for some battle scenarios, actually they reuse it that much that I started to dislike it. However the good part of doing this is that you can make sure that all you music harmonizes with the game's general feeling.

I'm going to stop doing music for now, I need to start programming the game mechanics because I need to experiment with them, currently I don't know other games with similar mechanic so I need to figure out how to make it interesting, fun, playable, and engaging. But well, I think I won't have any free time the following month so I'm not sure how much progress I will be able to make.

For now, here is the song:

First composed song - Opening Mystery 1

Lately I started to think about create my own video game's music. I already do a little of everything when talking about video games, but music was not something I had done before. I know I don't have the natural talent for composing music, however I decided to give it a try due that I have some general idea about music and I think some acceptable songs can be created by following some tips and tricks anyone can find in YouTube.

So here is it, the song is called Opening Mystery 1, it is thought for a small game I have in mind now. It is version 1 because I haven't completed the PxTone guide I'm following :P. I was about to start the complex part (chapter 3) so I thought I would understand it better by doing a first song and then polish it by using all those "pro tips".

The song is thought to be the music for the title screen of a video game I'm planning to do with a kind of mysterious and mystical atmosphere. Let's see if I can actually make it better once I complete the PxTone guide :)

I hope you like it!