Dev Log 2: Weeks 9-11

Dev Log 2: Weeks 9-11 

Weeks 9 to 11 we have been focusing on implementation of code so that we have a functional game as well as reiterating on the level following the principle of teach, test, challenge. We also got into creating puzzles for the level during these weeks.

These few weeks have been the most tricky and tedious seeing as that they have been spent implementing and creating the first level of our prototype. So just a recap from the last weeks. The things that we worked on during the prior weeks were coding and and getting the base design for the levels. 

At the start of week 9 we met for a group meeting to go over what had been done as well as what needed to be fixed/modified in terms of code and level design. We also divided up the work that needed to be done for the weeks to come.

The tasks that I was given were reiterating on the level design, particle effects, puzzle creation, and team management. 

For the reiteration on the level, I went over the path that I had for my first sketch and took into consideration my group members critiques. I also took into account on how we wanted to break down the level which was teach, test, challenge. This is a key level design rule. So what is teach, test, challenge? Its quite straightforward, A a level designer you want the first part of the level to be about teaching the player about the game and mechanics. Then you want to test them by giving them small challenges that require them to use the fundamental mechanics and knowledge to solve them. And then the last part of the of the level should challenge them. The last part of the level should make the player think outside of box in terms of using their abilities and how they can manipulate the environment around them in order to progress further on in the game. When making the level I also made sure there was an adequate amount of rooms/hallways to make sure we follow the teach, test, challenge principle. However with this in  mind I also had to change some of the rooms in order to fit the puzzles into the room rather than the other way around. Reason being is that if we were to of had made the puzzles to fit the level then the puzzles would not have been nearly as good nor would have they been successful.

Figure 1- Beat Map for the Level 

Puzzle creation was also another fun but hard task that I was given. To have a good puzzle you need it to have sequential events that keep the player engaged an wanting more. So what is a sequential puzzle? I short terms it is a puzzle that has multiple steps. For example one of puzzles in our prototype requires you to open a door by moving a box into place to activate a switch  then drops a box onto another a switch which then finally opens the door to the next room. Puzzles also have to need to be tricky, but not too tricky. You want it so that it makes the player thinks a good amount about the puzzle so once they solve it they feel accomplished. This will give them a small sense of confidence going into the next puzzle.

The puzzles that I created followed my explanation above. I created puzzles that were fun yet tricky and followed the level design principle teach, test, challenge. The first few puzzles were to teach the main mechanics to the player which were gravity switching and inverting gravity of other objects (enemies and boxes) . This is teaching stage plants ideas in the players mind on what the character can do and what they are limited to. The middle puzzles were dedicated to testing the player and how well they use the player abilities, their timing skills, how well they use the environment, and the sequential use of abilities. The last two puzzles are dedicated to challenging the player. These puzzles requires the player to use their full range of knowledge of not only the player but also the environment. They will have to think outside of the box for these puzzles because they are difficult.

Figure 2- Particle Noise Option

Creating particles effects for our prototype was interesting and a lot of fun, seeing as that I have only touched here and there with Unity's particle system. I had to create effects for the player death, enemy death, gravity switch, and an effect for the slingshot in our level. The reason why we wanted to have particle effects was to create more juice in the game. You can never have too much juice in a game... Well maybe you can? Anyways we added in particle systems so that we had some cool effects that immersed our player. While creating these particles I learned a lot in terms of how certain options affected the particles and the emission of them. For example I learnt that there is an option in the particle editor called "noise". I thought I would play around with this option when creating the particles because I wanted to see what it could do. I found that it changed how the particles moved and change the emission. It made the particles more organic almost liquid like depending on the way you modified the setting. If you look above at figure 2 It shows you a noise map. You can modify that noise map by playing with the octave level and the strength. What I found was that the more noise the map is the more organic the particle looks. I utilized the  noise option to create a liquid like particle effect for the slingshot. Reason being is that for one it looked really cool, and two, it made the slingshot stand out in the game and really drew in the player to see what the hell its is. Drawing the player in with the cool effect it also taught them that area in the level give you a speed burst in a certain direction. So not only can a particle effect be used for juicy explosions but it can also be a tool to draw your player into a certain area or to get your player to realize a certain object in game and make them explore further.     

The last task that I was given was team management. I made sure that there were scheduled meetings during the course of the few weeks. I also made sure the trello was up to date and made sure that changes were implemented for the team so that they knew what had to be done and what was being worked on. I have found that having a well structured group leads to better and more efficient work. And organization is key to that. That is why I have been using trello and the google drive, so I can keep track of my group members and not only make myself aware of whats being done in the project but allowing everyone that luxury.

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 .