The beggining of the end

This is my fifth blog post, the first one some days after the presentation of the beta. Since the game passed the beta state and is now moving towards the finish line, the implementation of new features is not possible, so I spend most of the time fixing bugs and balancing the game. In this blog I won’t talk about something specific but mostly of the before and after the beta.

After the beta playtest, we immediately started working, with the feedback we got. The weekend came. We had got a new map with more features and better lightning (credit to our amazing artists) but something was wrong, some mechanics didn’t work. Apparently the map was on the x,z axis and not the x,y. We couldn’t further implement stuff because we just couldn’t test it, so we had to fix it so we didn’t have to change everything. The implementation of the enemies, boss and obstacles on the new map had to wait.

Final Hours.

When the map issue was fixed the beta deadline was even closer and time was running short. Some features like the teleport silhouette (which I covered in the last blog) had not been tested nor implemented in the new map. I wanted to have most of the things done for the beta presentation, so I decided to stay up until I had most of the bugs fixed. The long night begun, with me, 470ml of redbull.

I managed to fix everything until the boss fight, I added the teleport silhouette but since it was late and I didn’t want to bother our artist, I managed to do a placeholder for it. When reaching 4 am, our other coder woke up to add some missing animation that our artist had just finished, so I went to bed for some rest.

The Presentation.

I showcased the gameplay and showed the new stuff added to the game. I got very satisfied with how it turned out after all the work that we put on it for the last couple of hours.

After this event, I started thinking in how this issue could have been avoided and not rush the last hours. I concluded that working individually is not the way to go, having the team members close while working is so important, we are mostly online and have good communication but a lot of issues are caused by misunderstandings, and working on something for several hours to later have little to no use is a bit frustrating.

Where am I?

Hi, this is my fourth blog post, in which I’ll be mostly talking about fixes that we are working on, provided by the beta playtesters feedback. I’ll focus mainly on the teleport, a game mechanic in our game that allows the player to move to a certain position.

At first, the teleport that we had in our game was very simple, the player pressed the right mouse button and main character gillis would instantly move to that position. Since the camera is always following the main character, the player felt lost when teleporting. So after the first playtest, we implemented so that the camera would smoothly move towards the player after the teleport.

During the beta playtest we noticed that the player still felt lost and was not comfortable using that game mechanic.

This week I have been working on polishing and fixing the game for the best user experience, one of the tasks was to change of the teleport mechanic so it was easier to use and to know the location before and after the teleportation better. We still wanted to keep the possibility to teleport wherever the player wanted in the boundaries that the game allowed. Instead of changing how the teleport works, I decided to give more information to the player, where the teleport was allowed and where the main characters position would be. To fit this accordingly, I implemented so while the player hold the right mouse a silhouette of the player would appear at the position after the teleport, and when the button is released the player would move to that exact location. I think that this is a good solution for this problem, but this could create some conflict with the boundaries, since we want the player to follow a certain path.

Right now, I’m thinking of implementing different types of silhouette, diving them into two, a grey one, that tells the player that it is ok to teleport and nothing interfere with the new position, such as objects or boundaries, and a red one that tells the player that is not ok to teleport. This idea comes with some flaws such as the restrictive feeling that it gives to the game, that would lower the quality of the player experience. This is something yet to be playtested and could not be implemented at all.

The matter of life

Hi, this is my third blog post, in which I’ll be talking about in-game feedback, more specifically, the collision feedback when the player gets hit by an entity that harms the player.

One of the reasons that made me work on this for the beta was all the feedback from everyone that play-tested the game during the alpha playtesting. The playtesters pointed out that there was no way to tell if they were getting hit by something, the health decreased but nothing informed the player that it got hit by something, other than the sound that our main character does.

This week I worked on the main characters health and feedback. First I implemented the hit animation, so each time the player gets hit by an enemy weapon, the hit animation plays. It may seem a simple task but after implementing it, I noticed that it always got overwritten by the other animations since the animation change based on which key you press or release. I changed the hierarchy so the first animation to be played is the hit animation and if it’s not playing the hit animation, the other animations can be played. It worked! I implemented the death animation that our graphic team members did. I played the game a bit and it instantly felt better.

With a complete dark scene, were the player hasto make is way through the village, lighting up the way casting fireballs, it felt a bit unbalanced to have only 5 health. I worked on implementing a health
pick up that would give back some health to the player, so the game wouldn’t feel so punishing. This task was directly related to the hit animation and I wanted to code it in a way that each script did the work it was designed for. For example, the collision would tell the animation to change and the player controller to decrease health. I accomplished this by inheritance, in unity is very simple to use and it worked. Now the collision tells if the player is colliding with a hearth that gives health points back or a harmful entity that decrease the health.

Now that I have it all set up, I tweaking and thinking of how the health pick ups would appear. If they would be spawned after defeating an enemy (rewarding the player for the encounter) or just have it spread out over the map (so the player would try to collect them and still be careful to not encounter any enemy). I have not fund the solution to this issue, the team should playtest it and see what feels better and fairer in for the beta play test.

Our enemies

Hi, this is one my second blog post, the first one after the alpha presentation and playtesting. I’m gonna talk about one of our base mechanics, the enemies.

In the concept that we are currently working on (Burn witch burn) the main character gets chased by the “mob” an unkillable horde of angry farmers that hunts yo through out the first level. While trying to run away from this unkillable mob, the player will encounter other obstacles and enemies. This enemies will be farmers. We have divided them into two groups: Melee Farmers and Ranged Farmers.

Melee Farmers: this are a enemy that when getting in range will follow the player and try to stab him with their pitchfork.

Ranged Farmers: this enemy is a static enemy that throws a torch at the player. Right now throwing torches at a fire witch may seem a bit silly but it will change for the Beta.
.

    The images show the ranged farmer in idle and throw states. In the throwing image he throws a arrow (placeholder for torch).

This week I have been working on the enemies. Mostly the ranged farmer since I had the sprites and animations ready. In my opinion the melee ones are the easiest one to implement since they are constanly moving towards the player and the ranged ones just throw stuff.

Right now the enemies have health and deal damage to the player. When the enemies health reaches 0 they just dissapear. We don’t have any feedback on if they are hit and it is something that we will have implemented for the beta. One cool way to do this is after the enemy takes a certain amout of damage and it’s health reaches 0, it starts burning (since you are shooting fireballs). In my opinion it would enhance the aesthetics of our game.

I managed to implement the basics and have the animations switching between each other. The farmer instantiate a object (the torch) and this one flies towards the players position in the moment of throwing animation. I’ve encountered some issues, such as the lightning we are using for our game since the torch should illuminate where it goes, but right now it doesn’t. It may seem that it not that big of a deal right now but in our game we decided to use the light as a guide for the player since the scene is completly dark. Another issue that will appear during the playtesting will be the balancing of our melee farmers, since the player won’t be able to see it because of it not having a emmiting light source.

The first Blog

Hi! I’m Gabriel Ringmar, Lead coder of Team Nazgul and I’ll be discusing some issues I got when Implementing the movement for the main character in our game that is now in development, Burn Witch Burn.

                                         “gilli animation”

In Burn witch burn you play as the main character Gilli a fire witch the flies on her broom. This was my first time working on unity but I tried an played around a bit. I implemented a arrow that could move with some basic ”if ”statements and it worked. The day after I saw some tutorials of how others implemented it and got quite different feedbacks, so I decided to do everything again. It didn’t take long to do and it used some unique variables in unity, such as (GetAxis”horizontal” or ”vertical”) that checks the usual inputs for moving a charater in a game (for example; wasd or the arrow keys).

It worked and it looked good so I kept it that way. The issue came after, when I added the sprites and the animations, because I needed something to tell the game to change the animations, so I did the ”if” statement implementation again. Now I had two different scripts that check for inputs and does something related to the movement of the player. I kept it like that for the pre-alpha but I have to do something about it, to have it all more optimized and better implemented. I want to keep the second implementation, because gave aditional inputs such as the arrow keys in less code. I’ll have to figure something out.

Another issue with the implementation of the animations and movement, was that sometimes it didn’t change at all. I couldn’t figure out why it behaved like that. It happened only when spamming opposite dircetion keys like up and down. Our other coder Oscar had something similar to my code but instead of checking for the name of the animation, he checked for a number that corredspond to a certain animation. At first thought it was a bit confusing since you couldn’t now which number it corresponded to. But he didn’t the same animation issue I got, so after some thinking I realized that his method was more optimized than mine and it could change the animation better and faster since it only checked for a number instead for a name that would take longer.