Dev Log 3: Weeks 11-13

Dev Log 3: Weeks 11-13

For the final weeks of creating this prototype we focused on polish. The polish we wanted to add to our prototype included fixing bugs within the code, modifying puzzle design, modifying level design, implementing art assets, and sound design so that our prototype felt complete and looked good.

 During the course of the final weeks I was tasked with modifying puzzles, adjusting the level design, sound design, and art implementation. 

Figure 1- Test Puzzle No.1

Vivek and I were the lead puzzle designers for our prototype. As the puzzle designers for the group we wanted to gate the player appropriately and made sure that we built puzzles that followed the principle of teach, test, challenge. Entering week 11 we had the majority of the puzzles thought through and implemented into the game. However, we had to modify some of the puzzles because we felt like they could be better with some more work. We also had to create and add in two more for the level. The puzzles that we modified for our game were the TEST puzzles. The original puzzles were sound but they didn't prove to be difficult enough to be considered a test. We went through the levels multiple times and made many iterations of the puzzles and then chose the best one. I found this to be a useful method on making better puzzles because it allowed us to explore as many possible variations of one puzzle. From those variations we then showed the top three to the other group members to play and then implemented the level that played the best.

Figure 2- Challenge Puzzle No.1

Moving on from modifying existing puzzles we then started to create the last puzzles of our level. These puzzles would be considered the CHALLENGE puzzles for level. For these puzzles we incorporated all the main mechanics into solving these puzzles as well as out of the box thinking. Just a recap on what the main mechanics are for Gravity Switch, the mechanics are switching gravity of the player, switching the gravity of objects (enemies and boxes), and switches. So how do you differentiate a challenge from a test, vice versa? For the challenge puzzles we want the player to use all the knowledge they have learnt up to that point and put it into motion with a puzzle that doesn't have a clear goal/set path for the player to follow. This will require some trial and error on the player part because at this stage of the game we want the player to have a difficult time. Through this trial and error they will then come to realize how to solve the puzzle and will have the sense of. "Ohhh I get it" or  "Why didn't I notice this before?" With this thought process they will look at the following puzzles in a new light and will attempt them with better knowledge and skill.

Level design was another prominent challenge I faced during these week. The puzzles and the level design turned out to go hand in hand. What I mean by this is that if we changed the puzzle in any sort of way , more than likely the level would have to change as well. With this being a factor, we made sure that we had all our puzzles completed and then adjusted the level as we saw fit in order to best accommodate the puzzle(s). The reason we went this route was because its easy to modify the level but it not easy to re-modify a puzzle. If we were to fit the puzzle to the room this would make for poor puzzles and it would also ;look very cluttered in those specific rooms.

Once the level modifications were complete I then began to polish off the level by adding in the art. The art that I added in consisted of the background art and the asset art (platforms, switches, doors, etc.) . This proved to be very troublesome because I was not the one who had created the art for the level. Our group member who was in charge of the art and its implementation  did not show up for the last two weeks so I took up the role of implementing it. Unfortunately, the art wasn't made into individual sprites that I could simply just drag and drop. This made implementing difficult and time consuming where my efforts could have been focused elsewhere. With that being said I made certain adjustments to the art so that I could put it into the level to make it look nice and complete.

Figure 3- EQ Mixer (Reaper)

I was also was in charge of the sound design for our prototype. This was one of the things I really wanted to take on because I had never actually made sound effects for a game. So I thought I would give it a try because I couldn't have made anything worse than the placeholder sounds we had... Or could I have? Anyways, the sounds that I created for the prototype were the gravity switch, box inversion, box thud, doors opening and closing, player shooting, elevators, and enemy dialogue. For the gravity switch sound I had to match the effect that Vivek had implemented which looked somewhat like a blast of power. So I found a sound that kind of matched the effect and then modified it within Reaper. I modified the original sound by changing the EQ to give it a lower tone and heavier base sound to get across a powerful blast. I did this for the majority of the sounds. But the sound effect that I am most proud of was the door. I had to get very creative in terms of mixing different sounds in order to get the juicy door sound we have now in our prototype. Vivek wanted a door that sounded heavy which had some sort of latch mechanism involved as well to sell the frigate theme. So What I ended up doing was mixing an airlock sound with a garage door. I took the blast of from the airlock sound and mixed it with garage. In order to make the garage door sound heavy I changed up the EQ of the sound to give it a lower tone, added a bit more bass, and I also added in some reverb to make it sound like the door is really old and heavy by making have some screechy vibrations incorporated into this.

Once I created all the sound for the game I then sent them over to Vivek to have them implemented into the game so that we had nice juicy sounds to compliment our game play.

  

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 .           

Critical Analysis: Tower Defense

Tower Defense

For this proof of concept we chose to create a futuristic tower defense that incorporated event systems. The event systems would control the use of turrets and when you could unlock them. Rather than using a 2D setting we decided to use a 2.5D setting to show off our towers and enemies. We wanted to go with a more futuristic theme for this game because it felt like that medieval had been used up. The enemies followed a set path to come and kill your base. There are 3 waves all with different enemies and turrets that can be used to kill these enemies in order to protect your base. 

Our original idea for this game was making the tower defense game into a multiplayer. So how would this work? Well at first we wanted to make it so that one player was the defending team and the other was the attacking. Using fog of war to mask the players intentions and strategies, we would have rounds where the player place the attck and defenses. The attcking player would declare which lane and how many troops and the defensive player would place the turrets where he/she saw most fit. after about thirty seconds the round would commence like a normal tower defense. 

This seemed like a great idea but we decided that we were biting off more than we could chew. Reason being is that we would have to create strategies for each and balance out each side so that there was a reason to play both sides and so that they were both fun. We also didn't know how we would implement event systems for each of the player simultaneously. 

We then discussed creating a tower defense game like plants vs. zombies. We weren't too satisfied with this idea because it didn't seem fun and not all that challenging at the time. So we decided to scrap that idea all together.

With some further thought and brainstorming we came up with just doing a regular tower defense game with a futuristic twist. The reason why we went with this idea was due to the fact that we believed that we could make more out of simpler game than we could out of a complex one. So we stuck with a more traditional based TD game.

Some of the thing s that we changed during implementation were drag and drop from a spawn point; Unlocking system based off currency, and having a boss level. 

The reason why we change the drag and drop was because or main coder, Vivek, knew of a better and more efficient way of doing this type of code. I stead of dragging from a spawn we decided to make it so that when we pressed a UI button the prefab would be instantiated onto the mouse coordinates and would follow the mouse until it was placed. This proved to be more effective as well as impressive/slick.

The other thing we changed during building/implementation was the unlocking system. Spenser was tasked with creating an unlock system which was based off the currency the player earned. So initially we wanted it so that when the player had collected 30 coins from killing the enemies they would be able to unlock the next tier of towers for them to use. However, with lack of time we were not able to implement this mechanic even though it was really cool and used event systems. So instead we made it so that when the player completes the wave the player unlocks the next tier. 

The other notable change that we made during building/implementing our game was having a boss level at wave three to show the capabilities of the turrets. Do to lack of time we just scratched that idea due to it not being that important in the grand scheme of things. 

With all this said there were some real strong points within our proof of concept. One of the major strong points was the implementation of waves and giving the player the ability to start the next wave at their own leisure. This was done by Vivek. It was great addition to our game to really give it the feel of a tower defense game.

I also believe that the turret tracking was another one of the strong points. Reason being is that its not all that easy to code and if it doesn't work then the game will suck and no one would want to play. It alos makes the game feel more complete even though its just a proof of concept. It shows that we have most of the main mechanics down that can be elaborated on.

Lastly I think the main strong point was the point and click to drop the turrets. This was some really hard coding that Vivek and I attempted together. We were able to complete it to give the player that sense of control and strategy you get from playing TD games. Because its based solely upon where a player places their towers. This mechanic really made the proof of concept feel accomplished and makes me want to come back to it and work on it again. 

I am really happy with how our proof of concept turned out. It was hard work but we got it done due to the work ethic of our group and the drive to want to make it better and fun. We had a lot of success in terms of implementing the main mechanics of what makes  a TD game such as the waves, drag and drop of the towers, the unlocking of the towers, etc. I feel like this is the most complete proof of concept due to all the major mechanics we completed for our game. This is definitely a game i would like top come back work on because it seems very promising.  

   

Proof of Concept: Tower Defense

Tower Defense

For our fourth and final proof of concept we were given the options of creating a proof of concept that incorporated the following archetypes:

- Tower Defense

- Sports Game 

- Management/Simulation

We decided to go ahead and attempt to create a fun and functional tower defense game. The reason that we chose the tower defense archetype was because we had to implement event systems into our code. We thought that the tower defense game would present more opportunity to use them more and use them effectively. We also really wanted to do this archetype because it seemed more fun and achievable in the time frame that we were given.

For this proof of concept my responsibilities were team manager and coding. The responsibilities were a little bit slimmer for this proof of concept because a lot of the code tied in with each other which made for large pieces of work per team mate. As the team manger I made sure that another trello board was created to ensure that everyone knew what they had to accomplish for the proof of concept. I also stressed to my group that it needed to be used more because during our previous proof of concept it was used very little. Consequently, it made things difficult in terms of figuring out what was done and what needed to be done. I also created another google drive folder for our group so that we had place to put our new work for our new proof of concept. Over the course of these proof of concepts, the google drive and the trello boards have made such an positive impact on our organisation and time management. It has kept us on track as well as organized which is key for success in any group environment. 

I also held two group meeting during the course of the proof of concept. The first one was the day after we were assigned the proof of concept. During that meeting we started with our usual brainstorming exercises to come up with a lot of ideas so we left no stones unturned. During this meeting we were able to come up with what kind of archetype we wanted to do as well as where we wanted to head with it. For our second meeting we made a lot of changes to the initial idea that we had. This was crucial because looking back on what we had previously I do not think that we would of had something to present with the time frame that we had. After finalizing what we wanted to go forth with we then divided up the tasks equally. 

Some challenges I faced this week was the lack of communication between myself and another one my group members. It has been a very busy week in terms of assignments and I have no doubt that this person was very busy. I did try to reach out to make sure that things were being done and that this person was in track. However, I got very minimal responses. For future projects with this individual or with any individual that is lacking communication I think will approach the matter differently. Perhaps having a separate meeting with the individual so that I can express my concern and hopefully get across that communication is key in group.

My other responsibility for this proof of concept  was coding. The coding that I did for this concept was the enemy movement and the spawning of the enemy. So in a typical tower defense game you have the enemies that follow a path towards "YOUR" base. So what i had to do was create the path on which the enemies would follow as well as where they would spawn. 

For the movement of the enemies I wanted to make them move more organically in terms of turning corners  and making them seem like they were on a path. So to do this I used some code from the boxy assets package as well as my own to create movement of the enemies. Using waypoints and speed I was able to create the organic movement that I wanted. I used multiple waypoints in a consecutive fashion to create the smooth organic path.

I did not have any troubles with this code due to act that i have done this type of code numerous time so I recycled and reiterated most of it.

The next part of the coding was the spawning of the enemies. So we had two paths that merged into one, so I had to create two spawns that would spawn the enemies. Using arrays and for loops i created a spawn script that allowed you to create a set amount of enemies that you wanted to spawn and then then delayed the time between them so that they didn't spawn all at the same time. I used an Ienumerator to do that. When the enemies spawned they would then follow their set path. 

The trouble that I had with this part was the delaying of the spawn. They just all spawned at one time which was a pain. So I looked up on the unity forums to figure out to best solve this problem and i wound up learning how to use ienumerators. This turned out to be very helpful because before this I did not know how to use this type of code or know what it was used for. So now that i have a pretty decent idea of what it is and does i would like to implement it more into my code seeing how useful it turned out to be.

I am very happy on how this proof of concept turned out. It was a lot of fun to work and I think we have made the most progress on this proof of concept than we have on the past ones. If I were to visit this project again there would be quite of changes that I would make to this game to make it a fun and playable tower defense game. 

the first change/implementation of this game would be adding in upgrades for our turrets. Yes we have the upgrade of turrets from light, medium, heavy. But what I would like to implement is an upgrade hierarchy to each individual turret. So I would like to emulate the type of system that Bloons 5 implements. In terms of having different upgrades/abilities/versions of each weapon they have. It makes the game more fun a makes the player strive for the better upgrade to get a better score. 

The other thing I would like to implement into our game would be different levels for our game. I find it to be boring just having one set path that never changes. A possible idea for a map would be having a moving map so in some instances the path would change and the enemies would travel to a different location based on how the map moved. 

Another thing that I would like to implement would be a more complex currency/economy into our game. Having this would allow us to dictate the unlocks a player gets to the amount of coinage an enemy drops. This would give us a more balanced game would make it a more complete tower defense game. 

All-in-all I am very happy with how our last proof of concept turned out. My team has done a great job and has done a lot of great work over the past 4 weeks and i can honestly say I would pick this group over any group due to the work ethic and the drive of wanting to do and help more. Its a blessing to have such diligent workers.         

Critical Analysis: Endless Runner

Critical Analysis

So our game is an endless runner that incorporates boosts, coins, and different terrains. The player has all the essentials of an endless runner which is having the ability to jump, dodge obstacles as well as manuever the map by moving from side to side using the "WASD" keys. Our endless runner incorporates different terrains such as land and water. You are a the basilisk lizard, which has the ability to run on land and water, running and manuevering the randomly generated terrain trying to survive as long as possible while collecting points and picking up speed boosts.   

Our first brainstorm of our game began with us wanting to make an endless runner that incorporated multiple levels for the runner to be able to interact with. We then discussed different terrains which led us to land and water. We liked where this was going. So Ian and I pitched the idea of using a frog for the player because they are amphibious which fit our game perfectly. We also pitched another creature call the basilisk lizard which has the ability to run across large bodies of water on it hind legs. We discussed the pros and cons of both creatures and decided on the lizard rather than the frog due to having more mechanic and player benefits. 

We then discussed how we were going to incorporate the lizard with the water and land. So for the land it was pretty easy we just wanted it to be able to move from side to side and be able to jump. However we were very split about the water. We wanted it so that the player had the option to run on top of the water or through it. But we did not know how incorporate it game wise. At first we discussed on having a pick up that allowed the player to walk across the water. Basically just skip it. If they didn't pick it up then the player would drop down into the water. So why drop into the water. Well this is where the risk and reward system comes into play. If they dropped down into the water there would be a lot of coins for the layer to pick up however there would be hazards for the player to dodge. We then changed this to have just a speed up that check whether or not you are over water. if the player is then the player ignores gravity for the time the boost lasts. So if the player loses the boost while over top of the water then they would fall into the water. 

We decided to go with the speed boost that lasted a certain period of time. This turned out to be a very good decision because it allowed us to use the boost in many places rather than just for the water. 

We also discussed having the ability to jump on platforms to incorporate the air terrain. It was instantly vetoed because it did not make any sense to have and it seemed out of place. So to satisfy the "air" kind of terrain we added elevations to the chucks such as bridges and protruding environment to give the player a sense of elevation. 

Another thing that we changed was having large obstacles such as turtles in the water and having a bird swoop down and kill you. Reason being is that the proved to be too hard for the player to manuever around and dodge so we took them out completely and stuck with the static objects that take off half of your health.

With all these changes and testing our game turned out really great and had a lot of strong points. One the major strong points was the random generation of the level chunks. This made our game. Without the random generation for the game our endless runner would not be nearly as "endless" as it is now. Huge shout out to Vivek for solving and coding that portion of the code. 

Another strong point of our concept was the speed boost and water mechanic. Its really slick. Ian coded it in a way that it checks to see whether or not the speed boost is on or not. If it it the gravity is off and will not fall into the water. If it is not on then it will fall into the water. It also really gets across our main idea of wanting different terrains and to get across which kind of lizard we initially wanted to use. 

 Overall I am very happy on how this concept turned out. It is a fun, full fledged endless runner that would like to work on further in the future. One of the major success of this concept was getting the random generation of the level chunks to work so that it would actually be endless. Another big success is that we were able to create our initial idea which was having a an endless runner with different terrains. I think with a little work on the terrains I think it would become a fun, novel game mechanic that I think it could be added into other endless runners like Temple Run. But to highlight the major success was the group and the work ethic. Everybody in my group is working at such a high caliber and getting work done left, right and center. I am so happy with my group. They are hard workers and they make these great concepts happen. Well done team.  

         

Proof of Concept: Endless Runner

 the Endless Runner

For our third Proof of Concept our team was tasked with creating a concept that incorporated one of the following archetypes:

- Endless Runner

- Brawler 

- Turn Based Strategy 

The catch for this proof of concept is that we had to incorporate interfaces into our code. A interface is basically a contract within the code which makes the code more modular. The reason why we chose this archetype is because we thought it would be the most fun and we thought it would test our skills the most. 

My responsibilities for this proof of concept was team manager, UI implementation, and coding. Like our last concept we split the tasks evenly based upon our skills and what we wanted to tackle. I enjoyed doing the implementation of the UI as well coding the implementation of it.

As the team manager i made sure to schedule all of our meetings for the week. We had two scheduled meetings for this concept to discuss what everyone was doing for the concept. The second one was to make sure everyone was on track and to sort out any problems we were having with our tasks or with the game itself. Meeting have become a mandatory practice that I have implemented due to all the benefits that comes with the meetings. As the team leader I also created the trello board for the team and created all the cards that need to be completed. The trello board was not used as much as I would have like last week for our 2nd proof of concept due to the fact of people just doing their own thing. So this week I made sure to let my group know that we have to use it more efficiently and frequently because we were having problems with keeping track of who did what, and what was done or not. I also created, for organisation sake, was a another google drive for our third concept so that everyone could drop the done work into the drive for everyone to access. Like all of the concepts I also conducted a brainstorming session once we got our idea so that we could get a firm grasp on what we wanted to attempt. I also had incorporated smaller sessions within our meetings for problems we had or for things that e wanted to add to the game. I really love incorporating these to our meetings because our group is full of critical and creative thinkers which makes them that much more effective. We have come up with some awesome ideas if were not for the help of the brainstorming sessions.

The other task that I was given for this concept was UI implementation for the score as well as coding. When we distributed the work load I really wanted to do this part because I had enjoyed working with the UI from our previous concept. So what we wanted for our scoring system was to have coins that they could collect like the endless runner: Temple Run. Instead of having three different we just wanted to have two sets of coins, so for instance we have a big and small coin. The big coin counts for 10 points and the small coin counts for 1 points. The way I coded the score was adding collision detection onto the player script. so how it work is that when the player collided with the coin it would compare tags with the object. So if the player collided with a small coin it would then add 1 to the score based on the tag it had. The same thing happens with the big coin. So whatever the tag of the coin was dictated the amount of points. Which was helpful because we could then add that into the interfaces and have multiple tags and essentially have numerous coins with different score amounts. Now the more trickier part of this code was manipulating the canvas text to show the score. So some challenges that I had with this code was not understanding how to go about it. so at first I wanted to type in the text and then add to the text. Which made sense in my head but did't work in the least. So I went on the unity forums to figure out a much easier to go about this. The funny thing was, was that i wasn't too far off with my initial idea. So basically within the code you had to manipulate the score text directly by printing score and then adding in the count. From there you made the text a public variable that you dragged into the script. other than that I did not have any other trouble with the code.

I did however try to work with interfaces. I was unsuccessful at trying to make them work. I went through many tutorials and forums to try and figure out how to implement them properly. Unfortunately I could not get a grasp on how to implement them. So I had to hand that part off to our lead coder Vivek, who was able to explain to me how to go about it next time.

The other thing that we had problems with was the shadows. As dumb as this sounds the shadows were not working what so ever. Fro some reason they were being turned off once the scene was being played. So Ian and I spent a good half hour trying to figure why this thing was happening. We fiddled with a bunch of stuff and did a few google searches but nothing was seeming to work. So we just started playing with a bunch of options and setting. Finally we went into the quality setting and played with the matrices and surely enough it worked.

We then tried to implement this on the master copy and sure as hell it was a different problem. So we went into the material shaders and noticed on top of playing with the matrices the shaders were set to transparent for some reason.

I am very satisfied on how this concept came about. It turned out really good. However if i were to visit this project again to turn it into a full fledged or prototype then there would be a few changes that I would like to implement.

One of the changes I would like to make to the game is the animations to the lizard and the moving objects. It would give the game a overall better feel and would make it more polished.

Another change that I would like to make to our game would be adding in more paths as well as different chunk shapes. Like temple run they have where you can turn and switch direction so that its not so linear. I think if we added that depth to our game it would make it a lot more fun and complete. because it gives player choice along with the endless runner feel. I would also like to edit the chunks themselves. What do I mean by this? Well basically we only have 2 chunks which are the regular path and the water path. I would at least like to add three more to give our runner some variety and more scenery.

A must change would be our player model. right now it is a dinosaur and we wanted to base our lizard off the "Jesus Lizard" or the basilisk lizard in proper terms. So myself and Ian would definitely model and animate the player model so that when it picks up a speed boost then it would look like the model is running faster and when it hits an obstacle then it would look like its slowing down. Also adding a jump animation would make it look more crisp.

Overall I am very happy on how this concept has turned out. Our team did an excellent job once again with getting their tasks done and implementing them on time so that we are not pulling an all nighter the night before the presentation.