The Boss Core

With little time to spare we forged on this week in order to complete the game’s features and have them working to fulfill beta. We identified the missing parts as sprites, sounds, background and the final boss. Since powerups and changes to shooting has been made from the beginning of the project, the boss has been on the backburner for a long time. Now that we have them where we want them, it’s was well overdue to complete the design for the boss and have the teams programmer start working on it. You may say that it’s madness to begin work on a boss with such limited time, and you’re right! But we all felt that a boss was the only right way to explain the narrative and have a satisfying ending.

On monday me and the programmer sat down and started to discuss the mechanics of the final boss and in what way he would challenge the player on everything that had been taught up until this point. Our game is heavily focused on keeping two characters safe and positioning them strategically to deal damage is the key to stay alive. So we decided to place the boss in the center of the screen which was the ideal way for the rest of the boss to fully function with our core mechanics. Because the player would have to position themselves and the Teddy on opposite sides of the boss we to deal damage decided that challenging the player on each side could lead to interesting choices. Within the red square of the picture, the boss is able to move, selecting a point and moving towards it, when reached it repeats the cycle, thus not creating a stale boss that is not pleasant to look at. It also makes the player chase after the boss at times.

Teddy(T), Boss(B), Player(P)

So how would we do that? First we figured out why the player would want to stay on a certain side of the boss. A popular concept of boss design is that the boss has some sort of weakness, usually a part where they have a chink in their armor or the like. Since our boss has four sides we decided to utilize them as some being more vulnerable than others. Some sides we decided would be “half weak” and “full weak” meaning that the fully vulnerable sides take the most damage and also is a safe spot. It’s the only spot on the boss that currently has no attacks that could harm the player. Placing the player at this side would mean that they can no damage until the sides changes but placing Teddy here would mean that you would have the highest damage output.

However, why would you not want to stay at one particular side? Well, we decided that each half weak side would have access to one of three weapons, each equipped differently. One would be a shotgun blast of projectiles, where one of the slugs would create a gap where the it’s safe. This pattern is randomized and constantly paying attention to when the projectiles are moving forward is the key to adapt safely. Another one would be a rapid fire of projectiles each randomized on five potential spawn points. Maneuvering between these projectiles is the safest option to stay alive. Finally, we have a wild card of a weapon, a ricochet projectile that could lead to extreme danger or potentially be a secure option, depending on the position of the boss. Bouncing off of walls, it’s less predictable than the other weapons but is a gamble. Remember, perhaps the fully weak side is on the opposite side, meaning that you can make the choice to either be likely to lose less health, but deal less damage or risk losing health but deal more damage. You could also go the absolute opposite way and choose the two half weak sides, sure they are both dangerous, but if you are having trouble with one particular weapon, it’s a compromise that can be made. There are more things planned for the boss, but the core of the boss is what I think would be the most intriguing to discuss.

Offering Choices to the Player

Following up on last week in which we improved parts of the game based on the playtest feedback we received, we now have made several changes in order to once again make our game interesting, not only to us but also to the audience.

What do I mean by this? What does interesting mean? To start off, let me give you some background. When we decided upon the concept of “Revenge of Teddy” we were currently unsure if our one and only programmer would or would not still partake in the course. The situation was very unclear at the time, so we made the decision to pick a game that was not very code heavy and make a stronger effort on graphics and the like. Because of this, we designed the game to be rather stale in gameplay but attempt to make up for it in atmosphere.

However, in our current situation we are ahead in code but behind in graphics. It was here when I spoke to my programmer who shared his concerns and I agreed, the game in its current form was very boring. The powerup didn’t offer any interesting choices, the player didn’t feel powerful, the enemies were predictable and the list goes on. Aware that the changes made would lead to more work, we decided to take the bullet because in the end it would be worth it. So what did we do?

First of all, the powerup, we scrapped it. At first it was a pickup dropped by chance after defeating enemies that would give the player two options: either retrieve some lost health or make a explosion that destroys every projectile, every enemy and every health pickup. What we wanted to achieve was that the player had to make a choice, get some health back, but still be in a tough situation or destroy everything but risk playing a bit further with no health pickups certain to save you. We thought that this powerup would ultimately always lead to one option over the other and that we couldn’t achieve a balanced game level where the player on multiple attempts would make mixed choices, instead always going for a certain one. The change was that we incorporated a different type of choice, it still spawns the same way by defeating enemies but now when defeated the powerup splits into four. Each of these fragments has their own power up and when one is picked up, the others disappear. Immediately the player has to pick and choose which one is the best choice at the current situation but because enemies are still active the “best one” might not be the safest one to retrieve. This emphasizes positioning together with risk versus reward. Next we have the four separate power ups. To start off we have Richochet, this projectile travels past the set destination(the projectile is fired towards the player) and when it hits a wall, it starts to bounce around, increasing the chance to hit enemies several times. Then we have Split, which when hitting an enemy causes it to split in two at opposite directions and travel forward again for some time before sizzling out. But, if it hits an enemy before that, the split happens again and with smart positioning can cause a chain reaction that could be devastating. Next up we have No-go Zones which is a field that hurts anything inside it and no projectiles can enter it. The idea is that the player lays this down in order to for some time create a space where they can take cover behind and damage enemies that travel through it. Finally we have Shield which is a reflective shield around Teddy(the players aim/reticle), with this we hope the player can blend defense with offense when faced with large amounts of projectiles and charging enemies. All in all we hope that with these changes we can make the player feel more powerful and instead of just using a simple projectile from beginning to end.

We also found that the current enemy in the game had a stiff movement pattern. In the previous version it moved into position and started moving from side to side, which side it went to first was the variation between them. To make the game feel a bit more lively we altered the movement pattern so that he always moves upwards in an S shape. By making this change we hope to make the game less predictable.

However this also means that we have to once again go back to level design and start over with how we best structure our levels(see blog post 1). Although I quite happy to do so because with more interesting mechanics at my disposal I can once again do some problem solving and figure out how to challenge the player in a safe environment before ramping the pace up and make them utilize everything they’ve learned.

Feedback and Improvements 16/02-2017

This monday we had a pre-alpha playtest and my week has been based on the feedback we were given. Since there were many suggestions regarding improving the game, I have no large task to focus around but more and smaller ones.

What we could gather from the feedback was that controlling two characters was not confusing and people enjoyed it, a lack of instructions made it confusing, especially since the projectile fired travels from the “aim” to the player. Allow me to explain, in our game, you play as a girl trapped in a nightmare where the fear of going to school haunts her. In this nightmare, she seeks comfort from her teddy bear called Teddy. To emphasize that the teddy serves as her comfort, we made it so that Teddy fires a projectile towards the player and damages any enemy caught in between them, this also allows for more strategized play and positioning. We were asked if it would make more sense to just have it reversed, but we have our reasons and we take the criticism as that we have failed to communicate the bond that they share.

In order to resolve this issue, we added a tether between the player and Teddy. Our hope is that with additional effects communicate to the player how their bond works, perhaps with particles that travel along the tether from the point of fire, Teddy, towards the player. However we also got points of improvement with how we communicate damage taken by the player or enemies, which we currently had none. We knew that it was missing but hadn’t had the time to implement it yet, so we put it high on the priority list and fixed it. The effect is currently very simple, when hit by a unfriendly projectile, the player turns transparent for a moment where they are also invincible. This allows the player to safely reassess themselves and not take several points of damage in an instant. We also added a similar effect for the enemy, however they turn red and have no invincible state. The reason behind why we chose the color red was because we wanted to communicate that what you have done had an effect on the enemy that was detrimental to their cause, in affect positive for you.

Also, the playtesters thought that our health indicator was unclear and not precise in what amount of HP they currently have. In the game, we have a large bright light in the background, the brighter it is, the more health you have and when you take damage the light fades. When completely out, the player dies. The reason we went with this decision is because we wanted to get rid of  any HUD that would take the players attention away from the action, making the game more intuitive. Going back in attempt to solve this issue we found several bugs regarding how much health you have. We printed several variables to the console and playtested time and time again. What we found was that even when using a powerup to heal, you remained on the same amount of health anyway and you always had 30 less HP than intended. This looked like a serious fault somewhere in the code but was eventually resolved when we realised we had loaded the script twice on the player character, making it behave in very weird ways, like resetting the health gained by the powerup etc. That such a simple issue gave us such trouble made us feel quite silly, so we fixed it back, but that didn’t mean we were done.

For instance, when we played the game again we also found that the health indicator wasn’t really communicating well how much HP the player actually has. What is supposed to happen is that when damaged, the light starts to fade a certain amount. This amount was very noticeable the first time, but up to the fifth time, no significant change was made to the light’s brightness. We haven’t had the time to fix it just yet, but have come up with a solution that involves setting the brightness to a specific value based on the amount of HP left. Why this matters is because we can then manually compare what values we think not only has a change in brightness, but also communicates well how much HP the player currently has.

Overall, the feedback we got motivated us to take charge in implementing these small but significant improvements to the game. With them out of the way, we can continue focusing on larger tasks again, making the game involve more content that adds to the games value.

Game Production (08-02-2017)

During sprint 2 of game production (the week before this) I continued work on both programming and design decisions. While most of the process with SCRUM is iterative and assets can always be improved, I turned my attention to the first level we would create. I decided to start with level 2 as I thought it would be a good idea to use my knowledge from creating earlier levels before starting on what will be the most important one. First impressions is everything and I don’t want my first level to be the weakest one.

As I began sketching out possible enemy encounters I kept some decisions in mind but my goal was to have several version that I could then analyze and compare to each other. After a little while I put the pen down and tried to ask myself,  does my level have variety? Does it have a good learning curve? Does it offer any challenges?

While looking through my notes I started to realize that perhaps I was relying on certain enemies to make it more ”interesting” and not taking into consideration that it only becomes interesting when it’s a suprise. Just because enemy A and B gels well doesn’t mean it remains as interesting if enemy B appears with enemy C & D aswell. This was one of the hurdles I discovered I had to get over, come up with new ecounters that challenged the player in different ways.

However, it then comes down to the learning curve. Does it teach the player how to play and handle situations in a safe environment before throwing them to the wolves? Perhaps my overreliance on a certain enemy was because I had this in mind? In order to figure out if my suspicion was correct I started to count the amount of times a enemy type showed up. What I ended up with was a fairly balanced amount and going over some of the other versions I found one that in my mind accomplished what I was looking for, variety and learning curve.

The final challenge comes down to if my level perhaps is too short?  While I do love short and well paced levels that doesn’t drag on for too long, what good is my level if it can be completed in just about a minute. Unfortunately this is something that has to be iterated upon because as of this moment, I can’t possibly know. With only one enemy complete in the games current state, I can only make predictions. But it is here where my role as a designer comes into play, when I have more assets to play around with, I can start to make a final decision through testing the game over and over again. The level I have planned out right now might not even be as good as I had hoped for, but atleast I still have my handy notebook where the most important questions have been asked and answered.

(Perhaps not the most intuative sketches, but they serve their purpose.)