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!

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!

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.

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!

Looking for feedback: How-to-play for Defender Blender

Defender Blender v0.3 is finally here :), I made this looking for feedback about the How-to-Play level. I also tweaked some stuff and fixed a few bugs.

Please take a look, I really appreciate your feedback!.

You can play it here!

Edit:
Lesson learned: Seems like Friday is the "official" date for look for feedback in Unity forums and Reddit, so I posted here:
Unity feedback Friday post
Reddit feedback Friday thread

I really got inspired when writing the Reddit one and wrote this, a little dramatic but I hope it will grab some attention:
Defend the secret Laser Cannon while it traverses the land to protect you people from an imminent attack!! Your willpower and hope to survive this challenge have converted you in a immortal killing machine, were you be able to use all your power to defend your people?! Don't be afraid, you are not alone! With your help, the Laser Cannon can gather power and destroy all the enemies in screen with a single powerful laser beam!!

Will it work? We will see :P

Game progress: Defender Blender - How to Play level

This week I had a little time to design my How to Play level.

The idea behind make a How to Play level is to make the player to understand the basics of the game, in this case these are the basics I wanted to cover:

1. Attack and jump. A very Mario starting I would say.

2. Get down of thin platforms. Additionally I put another enemy in order to remind the player how to attack the enemies.

3. Recover energy. This is a weird one, you basically make a suicidal jump. The idea is to teach the player that you actually don't die when your run out of health.

4. Items and health behavior. After attacking a bunch of enemies, hopefully the player will notice that the health points are also lost when attacking. Here I put an item to recover health and provide a little more explanation.

5. Jump attack. In this one I decided to not put any explanatory text, I believe it would be kind of obvious for the player that the jump attack exists.

Hopefully next week I will have a playable version and share it in Reddit looking for feedback.

Thank you for reading, see you next week!

Game progress: Defender Blender - Making walls

I started to write this telling how busy my week was and the problems I was having to make the walls work, then I thought that it would be much better to spend a little time trying to fix them rather than write a big post here, so I did it and I managed to make my walls work :)

I'm not going to go into many details this time. As I said in my previous entry the difficulty in make my walls was that I'm doing all my characters movement kinematic, i.e. not affected by the physics engine, instead I write how all the collisions should work, it gives me more control as developer but more headaches too.

Well, this is my results for this week:

1. The walls stop my character if touched from the sides (i.e. it can't go through the walls)
2. The character interrupts its jumping if hit a wall from below
3. The character can walk on the wall as with other platforms

1. 

2.

 3.

Next week will work on the how-to-play level design using this walls. Maybe I will need some other new elements but I'm not sure yet.

Thanks for reading, see you next week!

Game progress: Defender Blender

This was a really busy week, however I managed to have a little progress with Defender Blender.
Defender Blender is a game I made for learning Unity, I'm still learning from it and experimenting playability, difficulty, and a some game design. I will talk more about it once I upload it here, for now I'm sharing the progress I had this week.

First lesson learned, after update Unity 3.2.something to 3.6.2 I found that my game was not working anymore, most of the collisions where working just sometimes so I was not able to hit the enemies, the player was not pushed to stay in the screen (it is pushed by an object at the left of the screen), and things like that, so I started to investigate and found that there where two reasons for these problems:

    1. Rigidbodies sleep. Seems like this is an old Unity feature (before 3.2 version), so I'm not sure how my game was working before :). In order to optimize the physics in Unity, the engine does not check for collisions unless they are required, i.e. only if any object's property that could affect the physics changes. Why my objects were not detecting some collisions? Let me explain.

• You can have a Collider with Rigidbody, or without Rigidbody. A Collider without Rigidbody can actually collide with other Rigidbodies but only if they are awaken. A Rigidbody won't wake up when touched by a Collider. Some people use a kind of workaround for this (however, note that this is not a bug, it's a feature), they change the Rigidbody's position in the Update method in order to wake it up, something like: "rigidbody.transform = rigidbody.transform". The problem with this is that it is a kind of dirty trick that won't help your game's performance. So what is the correct solution?
• When a Rigidbody touch another Rigidbody, it wakes up. So put a Rigidbody component in whatever objects you're going to move constantly (like the player, the enemies, the projectiles). Adding a Rigidbody to some objects fixed my issues with some collisions.

    2. Methods in animations. After adding the Rigidbodies to some of my components I was still having problems to attack my enemies, it was like there was a kind of random factor that could make it work, or sometimes delay the collision. Actually I was able to see the collision happening in OnTriggerEnter method, however it was still not working. Then I found out that the issue was because the logic I used to activate the collision of the player's weapon. I used a method call from an Animation as you can see in the screenshot:

StartAttack() method activates a boolean variable that decides whether the sword collision is going to happen or not, this was needed because even when the Collider was really small when not attacking, sometimes the enemies just died because they touched the Collider inside the character.

So the plan was: when the animation starts, call StartAttack(), so the collisions are processed...

Well that is how it worked before, however animations seem to not have a lot of priority for Unity in processing, they are visual components, it's not a really good plan to depend on their accuracy to fire events in the right moment. Instead I called StartAttack() from the method which starts the animation. That fixed my problem.

What is I was really planning to do

After solving these bugs I started what I actually was trying to do, I added a new component to my game: Walls. I'm planning to use them mainly to teach the player how to jump because I noticed some people struggled to notice that keep the jump-key pressed make the character to jump higher. Also I want to use the walls to teach some other movements in the game, I will use them in a new How-to-play level.
Since my game uses physic objects as Kinematic objects, it does not use the physics engine to affect the objects movement, it only detects the collisions, so add a wall is not as easy as drop a rectangular Collider in there.

The Kinematic Rigidbodies/Colliders know they are touching each other, however they don't know the direction of the touch, so I can't just program my character to stop moving when touching a wall, because then it will stop as well when walking above the wall (it must be able to work above the walls). I was planning to use a different Collider on the top of wall but it was going to be messy. My plan so far is to do it by comparing the wall's position and the character position. When the player is above the wall, the wall will behave as a platform, and when the player is in any side of the wall, it will act as, well... a wall.

Well this is work in progress, after complete the programming of these walls, I hope to make a post about my how-to-play level design. See you next week!