2D Group Game Boss Concept

The boss went through many different iterations before we chose the ball design you can see below. I even took a design all the way to pixel art before changing my mind. The idea behind the first set of designs was a swarm of hive mind based enemies. The second set was an idea for several separate parts of a boss with a central piece. The third set was for many turrets which would be part of a boss. The fourth was just some random designs I was playing with that were partially based on cameras and Glados from Portal. The last was the initial idea I had but rejected due to the immense task of animating and coding it.

2D Group Game Sprites

I made the boss sprites for our game. The design of the boss we ended up using was spherical. I found this incredibly hard to animate as I needed segments of the ball to rotate around itself to give the illusion of movement. It took me a long time to get something I liked and I really think it works.

To distinguish between the boss drones, shield drones, and the main boss I used different sizes and colours. To add a bit of extra effect I made the shield have a lightning effect surround it. Here are all of the sprites for the boss.

2D Group Game Overview

So this project is creating a 2D non-sidescroller game in a group. Our group decided to make a singleplayer 2D pixel art platform shooter. We looked at different inspirations like Duck Game, Dungeon of the Endless, Binding of Isaac, Risk of Rain, and many other existing games. 

We spent a long time trying to figure out a style of pixel art for the game. We ended up all having different ideas for a long time before finding a mid ground between them all. 

The name for our game is WIP. It came out of an initial joke that our game was a constant work in progress. We toyed with other names like frostbite but WIP always kept coming back. It might make players feel like the game is unfinished but we like the name so decided to use it.

To start with in this project we used a Google document to throw ideas about between each other easily. However, the communication in our team slowly began to get bad. We weren't communicating enough and because of this our ideas began to conflict. Eventually we started communicating better again and the ideas all came back together but it was an interesting experience and I have learnt much about working on a game in a team.

2D Group Game Coding

I was in charge of the main bulk of coding and putting the game together. I also did the designs for the boss. This was a long process as my initial designs did not work out and proved too hard to code in the time we had.  

I found making a 2D game in Unity interesting. I have made 2D games before so I have had some experience. However, I did meet several challenges. Such as having to figure out how to do things in C# that I have done in other languages. 
The most challenging bit of code for me to create was the boss code. I initially made one script for 2 Boss Parts. The idea came from a hive mind concept that I came up with and I was just experimenting with code in Unity. I took a video of the initial prototype for the boss. It was pretty static and wouldn't have worked for the final boss fight. Also the small drones flew up if they were next to each other. This turned out to be because of a collision check recognising the drones as the ground. 
I made the AI using a state machine which I derived from the enemy behaviour script I had written previously. There are several states, IDLE, PURSUE, SHOOT, DEATH, SPAWN, FLEE, SHEILD, DETONATE. The detonate and sheild states are not used by the central piece of the boss. The spawn state is only for the central boss part. It spawns new drones and shields if there are less than 3 drones remaining and if it can see the player. It will not spawn new shields until there are no shields left. 
The boss in the prototype was very motionless. In the end the boss became much more agile and jumpy. I lowered the effect of gravity on it so that it could reach the higher platforms. It has a shield of small drones that circle around it which it cannot shoot through until the player destroys them. The separate drones that chase the player initially were just to get in the player's way. Now they explode after they hit the player. They also explode on death and take damage from the explosions which creates a chain reaction. This is because the drones only have 1 health. This caused me a problem to start because the boss spawns new drones when there are less than 3 remaining, and when they exploded as new ones spawn it creates a huge chain reaction of constant explosions above the boss. If the player enters this area they die instantly. I fixed this by making sure the drones take no damage from explosions for 0.2 seconds after they spawn. Now the problematic chain reaction no longer happens. 

I mentioned I made the enemy behaviour before the boss and derived the boss from that. My team wanted enemies that did were not fast and agile. However, we did want movement. So I made a script that made the enemy shoot when the player was seen, pursue in the direction the player was last seen and stop after a bit of time, and die when shot too many times. It was fun to figure out how I would do this and it took a little bit of looking up state machines and rigidbody velocity and addforce stuff. In the end I used a lot of what I already knew about code to make it. Unlike the boss I used a different script for each of the 3 enemies.

Here is a clip of the prototype of the boss.