Monday, 16 January 2017

Proof of Concept: Gravity Switch

Gravity Switch

For this assignment we were tasked with creating a proof of concept for one of the following archetypes:

- Platformer
- Card Game
- Scrolling Shooter

Our group decided to create a platformer that would use the core mechanic of manipulating the gravity of the player and the objects.

My responsibilities within the group were team manager, UI implementation, coding, and level design. In any group that I am in, I tend to take the role of team manager because I want to make sure that everything is organised, everyone knows what they are working on, scheduling, etc. That's exactly what I did for our group. As the team manager I led discussions about what our game was going to be;  how we were going to attempt to create our game; and what needed to done in order to achieve our goals. Using mind maps, lists, and trello we came up with many good ideas which led to us going with the idea of gravity manipulation. During our time working on the proof of concept I made sure that we had scheduled meetings so that we all knew what exactly had to be done and for people to ask questions and share ideas with the group.

Another responsibility of mine was level design. Ian and I were our teams level designers. We went about designing our level so that it would gate the player, teaching them how to play the game and how each ability is used. We also designed it to show what kind of puzzles they would likely see in the game if it were made into a full fledged game. Before making the level in Unity we both sketched up level designs and shared them with the group.We had them pick which parts they liked and didn't like about each of our levels. Ian and I then combined our levels to the specifications of the group and then started creating the level within Unity. We created the level so it became progressively challenging and so that the player could experience and test the full extent of the gravity manipulation mechanic. Some challenges that we had with this level was implementing puzzles that used the abilities of the player. The reason why this was one our challenges was due to not knowing if we could implement "Wall Walking" into our game via code. So we made two different levels, one level had "Wall Walking" gating and puzzles and one level that did not. However our main coder, Vivek, was able to create the mechanic via code so we went with the level that had the "Wall Walking" puzzles. Another challenged that we faced was the actual scale of the level. At first our level was way too big  so we had to scale it down. After we scaled it down we then realised the level did not have enough depth, meaning it was small and lacked puzzles to showcase our core mechanic. Part one of this problem was getting the proper metrics for the level. We based the scale of the level on the scale of the player. Which we should have done in the first place. The second part was adding in some more puzzle areas to gate the player and to make the level showcase the main mechanic more thoroughly.

Coding was another responsibility that I was tasked with. I did some simple coding for the game which consisted enemy lerping and re-spawning/checkpoints for the player. For the enemy lerping I reused some old code that I had and then modified it slightly. The modification that I added was a sine functions so that the enemy would look like its accelerating rather than having its lerp movement so linear and boring. The player respawn was fun to learn. I had some troubles with it at first because I had it so when the player died it would respawn at a given place. However it wanted the the respawns/checkpoints to be progressive in terms of when the player reaches a certain checkpoint in the level they will respawn there when they die. However the problem that I was having was that when the player died, regardless of where the player was, the player would respawn at the beginning checkpoint. So i went on to the Unity the unity forums to get some help on how to make progressive checkpoints. It actually was much easier than I anticipated. In simplest of terms, I had to place a trigger on the the checkpoint and when the player enters the trigger it would keep track of which checkpoint the player passed. Once the player died, they would respawn at the checkpoint they were last at.

UI implementation was the other responsibility I was tasked with. Spencer created the UI for our proof of concept and I placed it within our game. I made sure everything worked such as lives, the gravity meter, and the orb count. I also added in some fonts to make it look more pleasing to the eye. One of the things that I had a challenge with was programming the gravity bar. The reason why I was having trouble programming the gravity bar was because I had to try to understand and figure out code that Vivek created. The gravity bar had to gain gravity when the player collected an orb and lose gravity when the player inverted gravity or shot an orb. I couldn't figure out where these things were in the code nor how to implement it correctly. So Vivek and I worked it out together since he was the one to create the code.

Overall, I am very pleased on how our proof of concept  turned out. I think it brings a novel idea that can be expanded upon and can be created into a very fun game.

However, some of the things that I would fix/change with our proof of concept would have to be the wall walk. It works well for the proof of concept but it's a bit glitchy when you reach the top of the "gravity wall". I would change it so that once the player reaches the top of the wall the player gets a small force added to it so that it does not get stuck on the corner of the collider.

Another thing that i would change with our proof of concept would be the enemies. I would like to give the enemies an AI script to seek out the player when they are in a certain vicinity. I think this would give the enemies more depth and would also pose a more difficult challenge for the player while manuevering through the level.

I would also like to incorporate different types of enemies. In our early designs for this proof of concept we did have different types of enemies but it got lost during the development of the concept. I would like the to have a boss as well as enemies that can only be killed a certain via gravity switch and what not.

All in all I am very happy with what we did as a group. I think made an awesome and novel proof of concept and would love to continue working on it.

      

No comments:

Post a Comment