Dev Log 1: Weeks 7-9

Dev Log 1: Weeks 7-9

The is the first of three development logs that will go through the process of creating the prototype Gravity Switch. They will also summarize the tasks, successes, challenges, and how we overcame the challenges in order to create this prototype .

Gravity Switch is a Puzzle Logic game that focuses its main mechanic around inverting the players gravity. We chose to make this the core mechanic of the game because it presented novel ideas and paths that we could explore when creating our prototype. Being able to invert the gravity of the player allowed them to explore the level in a fun new way. This in turn enabled us to create puzzles and levels that utilized this mechanic. The reason why we chose to go with this proof of concept was due to its replay value, the ease of building on the original idea, and it was our favourite concept out of the four that we created.

Before starting on any part of the game we first reworked the schedule as a group that we had created for our pitch. The schedule that we had previously was much too difficult to get done in the time frame that we were given. We stripped our game down to its fundamentals in order to create an organized schedule that focused on the core mechanics of our game. We wanted to build on top of what made our game fun and novel and then add the secondary stuff if and when we would have time. 

Once we narrowed down what we were going to work on for the weeks leading up to week 11, we then divided up the work amongst ourselves. 

My tasks for weeks 7 to 9 were to work on enemy AI, level design, and team management. I had to create two different types of enemy AI to fit each enemy. We haveregular enemies and shooting enemies. The regular enemies patrol a certain area of the level and when the player enters the vision radius they accelerate towards the player. Whereas the shooting enemies are stationary and shoot projectiles at the player when they enter the vision radius.

We thought that having more than one type of enemy would make for good game play and would keep things fresh for the player  rather than bore them with the same enemy over and over. Adding both types of enemies proved to be very useful in terms of adding them in as obstacles for the player to dodge or use the as tools to solve the puzzles that they are faced with. The regular enemy had a few versions. The first version was the enemy lerping at a certain part of the map between two nodes that were specifically placed. When the player entered the vision radius the enemy would cancel the patrol code and then accelerate to the players current position. If the player left the vision radius it would then go back to the starting point and then start its patrol again. It was quite glitchy at first. One of the errors that this version had was when the player exited the vision radius of the enemy the code that told enemy to go back to patrolling would teleport it back to the starting point where the lerp began. I didn't really like this version nor did the group. So we decided rather than having the enemy go back to its original position and patrol again we decided that it would be best if we had the enemy continuously follow the player. This was much simpler code and proved to be much more effective. 

The shooting enemy was quite easy to implement. For our previous proof of concept we created a tower defense game and we used turrets that shot projectiles at the enemy position when they entered the radius of the turrets. For the shooting enemy I took the code from the turrets and modified it bit to fit the purpose of the enemy. This worked well. For good game play I added in some code, with the help of Vivek, that allowed us to adjust the speed of the projectile and the rate at which it was fired at. This allowed us to tweak the shooting enemy so that it didn't feel too hard to kill due the rate of fire it was shooting projectiles. But we also didn't want it to be to easy to kill either because it was the next tier enemy. Having these public variables that we could adjust on the fly proved to be useful and allowed us to create a challenging enemy for the player.

Figure 1 -1st Level Sketch

After listening to the critiques of our proof of concept map I started to iterate on new maps for our prototype. We as group wanted to use the gravity switch to its fullest extent because we felt that we were cheaply using it and not really exploiting the mechanics full potential. We wanted it to be our centre of game play. As one of the level designers, I created a few level iterations that required the player to use the gravity switch so that it felt like the player had to use the mechanic in certain areas and also make give them a sense that they could experiment with it. I made the map more vertical in order for the player to utilize the gravity switch more. I also made lots of sequential puzzles which needed the use of the gravity switch to complete them.

I am team manager for this group. So I have been making sure that everyone is on task and know what they're doing for the present week and the upcoming weeks. To keep my group organized and on track I created a slack group, facebook group, and private google drive for our group.  I have been avidly updating slack, google drive, and the schedule so that my group members are up to date and are not lost when they are trying to find what to do next when they are done their task(s). I also have have made a huge effort to make sure that we meet up once to twice a week in order for group members to collaborate and discuss where we are at with the prototype and what needs to be done and/or modified. These weeks have been really hard since we have just finished reading week and sprint week. Everybody has been quite busy. But since then we have been sticking to the meeting schedules that I have put into place and they have turned out to very helpful in generating new ideas for the .