Critical Analysis: Pirate Racing

Pirate Racing

Our proof of concept is a pirate racing game. The player is in control of the their prate ship racing against opposing player which are AI controlled. They have to manuever through the map dodging hazards and obstacles that stand in their way. To make things more interesting, the player has to be aware of the wind. The wind plays a key factor in our game. The winds blow from the north and from the south. So we have mechanic where you as the player control your sails. Using UI and particle effects to indicate the change in direction the player must drop their sails if the wind is coming at them and put them up if the wind is coming from behind. If the player does't put down the sails there will be a speed penalty allowing other player to surpass them. During the race they will come across cannon pickups which will give them projectiles to shoot at opposing players. The projectiles do not harm or kill the opposing players, they slow the opposing player(s) to slow down allowing the player to pull ahead. At the end of the of the map they will reach the finish line and will placed accordingly. 

I think the strong points of this game were the wind/sails mechanic as well fluidity of the boat in the water. 

The wind and the sails mechanic was a really innovative idea that our group came up with. because its a very realistic aspect of sailing that determines your speed and direction. I think we tweaked it so that it was fun and brought a timing aspect into our game to keep players engaged so that they do not fall behind. I think its also another take on racing games which is a breath of fresh air because I find racing games to be repetitive and boring because of just holding down one button. Now with this timing aspect of putting up and down the sails to maximise speed keeps players engaged and wanting to make sure they are hit every wind change to give them the edge on the other player. 

The other strong point of our game is fluidity of the water and how the boat moves within the water. Vivek did a helluva job on the water and the boat movement. He used some really complex coding that involved the meshes of the objects to simulate the water and how objects interact with the water. It really sets the feel of the game and makes you feel like you are controlling a boat in a sense. The motion of the water and the boat is very pleasing to the eye. Very well done.  

So our original idea for our racing game was to create a maze racing game. It required the player to race to the end of the maze before the "beast" could catch up with you and kill you. With a lot of talk and brainstorming we put this idea aside because although it seemed like fun the team felt like it was lacking in mechanic and novelty. We then eventually came up with the idea of a boat racing game that used real physics such as wind, water current, sails, rudder, etc. This seemed like a sound idea because it incorporated all different mechanics that we thought would be cool to explore and utilise.

As we began to talk more and more we realised that we biting off more than we could chew. So we decided to only incorporate the wind, water, and sails. From there we wanted to make it so that it was a multiplayer game. We were all for our game being multiplayer. Then we got onto the the pirate subject and then a whole lot of what if's started to come about. So from this we wanted to incorporate cannons into our game to get the pirate aesthetic. 

From there we divided up the the roles and went our own ways. The next meeting we completely revised our idea from using real physics to a user friendly game that only required the player to change their sails from up and down when the wind changed. The reason why we did this was it was way too janky and realistic which made the game not at all. We were all for this because it made for a better racing game. So we focused on the the main movement of the player and the how we would incorporate the camera to fit for the multiplayer gameplay. 

This also was changed. We found it too complicated to do split-screen and change the camera at the same time for 2 players. So we then decided to just use basic AI for our proof of concept and to focus on just one player. 

So we ended up with a single player pirate racing game which proved to be a lot of fun and balanced. 

I'm very happy with how our final proof of concept turned out. It is a lot of fun and i feel like its a novel racing game which incorporates a type of timing mini game within the racing aspect. This in turn forces the player to focus on the gameplay so that they perfectly time the sail switch so they can get the edge on their opponents. Like I stated before, I also think the fluidity of the water and the boat really gives the game a great feel which immerses the player further giving the game a better feel and gives the player a better playing experience. 

I think our game was a success. We do what we initially set out to do accomplish. Which in hind sight was a rally good thing because we kept revising our initial idea and questioning it and we were able to come up with this great racing game.    

     

Proof of Concept: Pirate Racing

Pirate Racing

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

- Match 3

- Racing 

- Visual Novel

As a group we were pretty decisive on what we wanted to make. We chose to create a racing proof of concept due to the fact most of the group was against the other archetypes and also really wanted to attempt to create a racing game concept. 

My responsibilities for this proof of concept was team manager, UI implementation, and coding. However compared to the last proof of concept the work was broken down more evenly. This is due to us growing as a group and learning what everyone brings to the table. We also wanted to make sure no one got burnt out during this proof of concept either.

As the team manager I scheduled all of our meetings for the week so that we could get together to ask question, implement, solve/answer problem, and to make sure everyone is on track. Having these meetings is very beneficial for our group because it keeps us on track and doesn't allow us to fall behind with the work we have to do. Another task as a team manager is conducting group brainstorm sessions. This allows us to view all routes we can go with our game, code, design, etc. During the barnstorming sessions I used different techniques and methods such as mind maps, group discussions, diagrams, lists, and some different creative problem solving tools. These techniques prove very useful during our sessions because, as a group, we generate many novel and fun ideas. As the team manager I made sure that new trello board was created for our new proof of concept. The trello board proves very useful and helps the group with organisation, I think organisation is one of the keys to an effective group.

Some challenges that I was faced with as the team manager was meeting up for all the meeting that I had scheduled. This was due to personal matters, but i made sure that the meeting continued without me so that group could talk, implement and brainstorm together. The steps I took so that i wasn't left out of any details or decisions was having one of my group members relay back to me what had been said during the group meetings I was not able to attend. 

UI implementation was another one of my responsibilities for our proof of concept. The UI was pretty straight forward. The first part of the UI was the wind indicator. The wind indicator tells the player what way the wind is coming and whether or not they should put their "sails up" or "sails down". The indicators were as simple as two arrows. The green arrow represented "sails up" and the red arrow "sails down". In order to get across the up and down indicators was enabling the one arrow and disabling the other based upon the direction of the wind. I also had to create and implement the projectile count. So I did basically the same thing. All I did was disable the images when the the projectiles were fired and then enabled when the player picked them up indicating to the player how many cannonballs they had at their disposal. The last the UI element I had to create for our proof of concept was countdown phase before the race began. This was a tedious task and proved to be quite challenging. At first I tried to manipulate the GUI text in order to create a countdown but that didn't work. 

To solve my problem, I went through a few tutorials which helped me out quite a bit. Rather than manipulating the GUI text. It taught me how to use sprites and animations to get a across the countdown. It required a little coding that just checked to see if the countdown was in progress. If it was in progress, then all controls would be disabled until the countdown was done.

Coding was another one of my responsibility. All the coding was split amongst all of us so that not just one of us was bogged down doing all of it. This proved to be very helpful and time efficient for our group. My tasks within for the coding was the UI and projectiles. I enjoyed doing the projectile code because it was a lot more than instantiating an object. I had to incorporate count of the projectiles which proved to be a little difficult but with a little tweaking and playing around with code i was able to get it done and working well. The other part of the projectiles was the pick up that came with it. So basically what I did was give the player a max amount of 3 projectiles. If the player shot a projectile the count would decrease. Then if the player collected one of the pickups it would add to the projectile count and destroy the object. However if the player had 3 projectiles and decided to pick up another projectile nothing would happen and the pick up would stay in its original place for another player/AI to pick up and use if they did not have maximum projectiles. 

I did not have any serious challenges with this code. It was just a matter and tweaking certain variables and adding in constraints so that the count didn't get to high or low. 

Again, I am very happy with the turnout of the proof of concept. I think with some more work and fine tuning this game could be a popular racing game. It think it has some novel mechanics that make the game fresh. As wells as the genre of racing. Pirate ship racing is pretty cool. I know for sure if we were to continue with this game our group would make it work and create an outstanding game. 

Some changes that I would make to our concept would be to add in more wind directions. At this point in time we only have wind in the north and south direction. I think it would be worth while adding in east and west winds and seeing how it would play out and affect the overall feel of the game. 

Another change/modification to the concept is not being restricted to using mouse and keyboard. This really affected our overall design and how we went about creating this game. We wanted to have multiplayer very much. Which required us to take into account two players using a keyboard which is a bitch. This also put more restrictions on what keys we could use. And funny enough we ended up not incorporating multiplayer due to time and complications. But adding controllers would definitely be a thing we would add in to our game because it gives us more buttons to work with which means more things we can add into our game to make it more fun. 

I also believe adding in WAY more pickups would be beneficial for our game. Since its just a proof of concept and with the amount of time we had we just went with projectile because it was most fun and incorporated the slowing affect against opposing players/AI. Some of the pick ups that i would add in would be a speed up, immunity to wind, boarding (steal another persons boost/projectile), etc.

I am very happy with how our game turned out. My team did an awesome job as usual at getting work done and coming up with novel ideas for our game. Its a pleasure to work with them.  

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.

      

Critical Analysis: Gravity Switch

Critical Analysis

The design of Gravity Switch started off as a concept of being able to manipulate all sorts of elements such as water, fire, air, etc. We then came up with the idea of gravity and being to manipulate it. From there we decided that we would allow the player to manipulate the gravity of themselves and the objects around them to solve puzzles and manuever around the level in a new and fun way. The main mechanics of the game that we wanted to incorporate were gravity inversion, which allows the player invert their own gravity. And wall walk which allows the player to walk up vertical walls. Another part to our game was being able to shoot a gravity pulse to invert an objects gravity. 

In order to manipulate gravity, the player would have to collect gravity orbs to fill the gravity bar in order to use the gravity inversion and gravity shot. Each of these mechanics use up the gravity orbs which in turn gives the player motive to collect more orbs so that they can continue to move through the level.   

As group we wanted to make sure that the main mechanic(s) were solidified and worked nicely before we moved onto secondary mechanics. 

The definite strong points to our proof of concept would be the main mechanics which were the gravity inversion and the wall walk. These two mechanics make our game. The gravity inversion allows us to switch our gravity so that we can move around the map appropriately. It allows the player to progress through the map, avoid enemies and hazards, and solve puzzles. Same thing applies to the wall walk mechanic. It gives our game more depth into gravity manipulation. So rather than just being able to walk on the top part of the level we are also enabling the player to walk on a vertical wall. This opened up many new puzzles and level designs for us because it gave us a whole other dimension to work with. We created new puzzles and areas that you couldn't do with the gravity inversion solely which kept our concept fresh and kept the players who played wanting more. 

In previous versions we wanted to create a mechanic that allow the player to swing from one point to another. Kind of like a spider-man mechanic. We scrapped this idea because it really didn't fit into the the whole idea of gravity manipulation. It also was way too hard to implement properly with the time we were given plus the mechanics we had already decided on and started to create. However if we had more time I would've like to have implemented this sort of idea which gravity manipulation in mind because I think that we as a group would've came up with a really cool mechanic for a really cool game. 

Another change that we made to our game was not having two different types of objects. We stuck with the one object which was the invert-able box. The object that we scrapped was the regular one. The reason for this was because it felt like it was just there and doing nothing much of anything. The only thing that it was useful for was pushing it, using the players force, over top of the door switch. We also felt like we could just use the invert-able objects more and more effectively rather than having two types of objects. 

We had a really cool design for the gravity bar that we unfortunately had to change. The gravity bar had really cool mask that made the bar look very mech. However it ended disrupting the players view of how much gravity they had in the bar so we removed the mask.

Map size was another thing that we changed quite a bit. At first we thought that the level was too small. But once we allowed other students to play our proof of concept they thought that the level was too long. So we ended up cutting our original level in half so that it wasn't too long but also had enough content to showcase our full concept. This was harder than expected because we had the level all planned out to gate the player and showcase our full concept. However, getting the feedback from the the other students really helped us. It made us think on how we could condense and scrap certain areas to make concept short and sweet.    

I am very pleased with how our proof of concept turned out. We were able to implement all of the mechanics we wanted into our game cleanly and effectively which made our proof of concept so much more appealing and fun to play. The art assets also were done exceptionally well which gives the overall concept a nice feel and look.

But the mechanics and how we used the mechanics really sold this game to me. Being able to solve the puzzles and manuever the map using the gravity manipulation is very clever. And as the game designer it really makes us think how we can incorporate the gravity manipulation into a new puzzle or vice versa. I think we made a fun and novel concept that could be turned into a really fun game. I know that I would certainly love to work on this concept further and publish it either on itchio or steam.        

     

Mini Game V

Mini Game V

For our last mini game we were given no restrictions or set mechanics that we had to incorporate into it. We had the freedom to crate our own game. We were also given then option to choose our groups for this game. The partners that I chose to work with were 

• Matt Murchinson
• Maddi McDougall
• Connor Gillihuy  

Process

We started off by meeting up and clarifying that we were in a group together. We then got right down to it and started mind mapping and writing out ideas for the game that we wanted to create. Our thoughts were really scattered since we had the freedom of creating our own min game with no restrictions. So after a good half hour we finally came to an agreement due to the absurdness and fun that we thought would come of the game. The game that we decided on was a chicken shoot'em up game. We also decided on that the chicken should be protecting something so that the player felt a sense of objective. We decided that the chicken would be defending it coup from rabid raccoons. We loved this idea the moment we started talking about it. Ideas started to flow and our game became more clear. 

Our second meeting consisted of dividing the roles up and what everyone was doing. So we divided the roles which consisted of myself and Maddi were the lead programmers of the group. Connor and Matt were given the role of artists.from there we then created a trello board so that we had some organization of what needed to be done for the game because I believe in organization and we had some very big scopes for our game that I thought needed to be organized. 

We had a quick third meeting that consisted of us making sure that we knew what we were doing and when we should have it done by so that we were not bogged down with implementing and the last minute.

The last meeting consisted of us working on the game and implementing everything. This was a much longer meeting since there were some issues implementing and making sure everything worked all together. But everything came together and we made a kick ass game.

Postmortem

Our game turned out really good due to our awesome group. They were amazing! They put everything they had into this last project even though they were dead ass tired. Yet this some of the best work I've seen all year. I would definitely work with this group again. 

The game that we created turned out great. I loved the animations that Maddi and Matt did. They really sewed together the whole project. I also like the concept and how much more we can exand of the game. For example we can add more players, different enemies, weapon choice, more levels, etc. 

A few changes that I would like for our game would be a animated title screen. We were not able to get to that due lack of time and energy. As well as rather than using the keyboard and mouse i would prefer to have the button layout for the game mapped to the xbox 360 controller for a better game feel.  

Mini Game IV

Mini Game IV

For this mini game we were tasked with  creating a game that was focused around resource management and game economy. The game also had to be multiplayer and could be either cooperative or competitive. The game also had to have an element of chance to give incorporated into it.  I was placed in a group of three. My group members consisted of:

• Maddi McDougall
• Chanel Marino    

Process:

On the day that we were assigned the mini game Maddi and I got together after class to brainstorm some ideas that we could use for our game. We mind mapped some ideas of what makes a good resource management/economy game. So we looked at some games that required the player to manage their resources accordingly. Some the games that we looked at were monopoly and risk  and few others. This gave us a base and ideas to work with to start fleshing out new ideas for our game. We came up with three ideas which included a resource management tower defense type game, an island survival game, and  spaceship game that reminded me of Lovers in a Dangerous Space. With all these ideas we concluded our first meeting. 

Our second meeting we had all group members. We got together and sat down to flesh out our whole game and what we were all going to do to contribute to our game. So Maddi had this idea that we stick with the space theme but switch it up a bit to being so much like Lovers in a Dangerous Space. She had the idea of having an arcade type space game. The objective of the game at this point was having a head-to-head space shooter where the players would have to manage their shields, weapons and special weapons. We all like this type of game and idea so we started to elaborate on it more. 

We started to discuss and we decided that it would be more fun to have 2-4 players rather than just having 2 players trying to kill each other. It brought an element of skill and focus but most of all managing the resources. So we then moved onto the resources. At first we had it so that you could only your abilities when your energy bar reach a certain amount. We discussed and decided that this would not get across resource management effectively nor would it be fun. We decided rather than having an energy bar that determined when you can use your resources (shield, guns) that we would make them each their own separate resource. This seemed and felt better to do it this way. So then we thought how can we make so that the players ave to manage their shields and guns? We decided to make it so that each of them had cool-down timer. So if a player was to shoot their weapon they would lose a counter. The player would have a total of three or four counters. If they fired one bullet it would regenerate after a certain period of time. However we wanted to make it so that when a player used up all their resources, whether it be their shield or weapons, they would have to wait an extended period of time to get back their resources as apposed to a relatively short cool-down to get back one. This would make conserve their resources so that they are not completely vulnerable to be attacked. After all this brainstorming and fleshing out a workable idea we decided to conclude the meeting and meet up again to work the actual game itself. 

The third meeting we got down to it. Maddi was the lead programmer, I was the transnational group member doing both programming and art, and Chanel was in charge of art assets and UI. For the project i set up the controllers and mapped the code to work with controls. Once I had completed that, I  then gave it to Maddi so that we could implement. From there i then worked on the shields for the players. I had to make it so that when the player presses the left bumper of the xbox controller a shield would instantiate and follow the player, since each player is moving. After we got everything implemented into the master copy we concluded the meeting. 

Our fourth meeting was the finalization of the game. and the implementation of Chanel's UI. We fixed up some of the code and made it feel and play better. When the code and UI was being implemented I was creating the start menu for our game so that our game wasn't just a playable but actually had layers. It was a long night but we got it all done.

Postmortem:  

I was very happy on how our game turned out. It was fun and it demonstrated resource management. Some things that I would change or add would be:

• Special weapon
• Free movement rather than fixed
• A game over menu 
• Meteor showers

It think that these elements would make the game more fun and interesting and give it more depth. I think our game was fun but it needed more. With that being said for the time that we had I think we did an amazing job both on programming and art. 

Some of the things that I thought went really well was:

• Game feel 
• art
• music 
• game play 

I thought our game was really fun to play and felt real good. I would love to take this game further because I feel like if we expanded on this game further and implemented our ideas that we left out the game would be so much fun and would be a great party game. 

I really enjoyed working with Maddi and Chanel. They are very talented and great team members and would really like to work with them in the future.     

Mini Game III

Mini Game III

For this mini game we were to create a game that focuses on either cooperative or competitive game play. The catch for this game is that the all the artists and programmers were split up and put into groups. So what i mean is groups only consisted of only artists or only programmers, no mix up. 

I was placed in artist group seeing as that I am stronger in art than I am programming. My group consisted of two others:

- Josh Garcia

- James Pratt

Who are also good artists.

Process:

Our first meeting consisted of us meeting up right after we were assigned the mini game. We decided that we wanted to create a game the focused on cooperative game play. We fleshed out some ideas of what makes a good cooperative game and what kind of mechanics we could use to make a successful cooperative game. We first fleshed out a game that required 2 players that have to make to the end of a level. However, each player a has a certain ability to help them overcome certain obstacles in their path. In which case one player cannot finish the level without the other because one challenge cannot be complete with the ability type the player is using. 

So then we came up with having a rock and a wind sprite and we started to base challenge we could throw at each character making it so that both players have to work together to overcome. However, seeing as that we didn't have a strong coder in the group we wanted to keep the coding difficulty down so we didn't run into major problems and time crunches.

Our second meeting brought us in a new direction. The problem that we had with our previous idea was that it would involve to adept coding for us and we wouldn't have made a playable game in the time frame that we had. So then, James, came up with an idea of a party game where you have to do specific actions almost kind of like a Heads Up game. So we elaborated more and came with an idea that we would change to competitive game where the whole class would be put into our game and then the game would randomly pick two names and they would have to go head to head.  Then on the screen prompts would show up telling the students what to do. For example, rap for 30 secs. The way we would the winner would be determined is by mob rules. So whoever gets the loudest cheer afterwards wins and gets a point. The students would sit down and then the next names would be chosen and the next prompt would posted.

We really liked this idea and we ran with it because it seemed like a lot of fun and we thought it was quite novel. 

Our third meeting I was not apart of due to pulling an all nighter. So Josh and James went ahead with trying to program and get the art done for the game while recuperated and got ready for the next to help.

The next morning I was informed that they had changed the idea completely from the party game that we had. The reason why it was changed was due to the fact it was just too hard to program. 

So they ran by the idea they had came up with during our fourth meeting. They had an idea where you were magnets and you had to use your polarities to move about to the level to reach the end. I thought this was a great and novel idea. So we ran with this because we literally had one more day to finish the game. So James took the role of being our main programmer. Josh did the background art and some minor programming. And my role was to create a level and do some minor programming as well (which was not implemented due bugs). 

So we finally made ends meet and had a playable prototype which we thought was good enough to play and get across our cooperative game play using polarity.  

                            

Postmortem:

Our game was not perfect by any sort of means due to lack of the programming knowledge and time that we had to create this game. Some things that we need to fix for this game are :

- player movement and physics

- polarity toggle

- platform distancing 

- catching and throwing mechanics 

- interaction with the environment

- 3D?

These are the key things that I think need to be fixed on this game. I believe us as a team could program this no problem given a little bit more time to create a fun, polished game. If we focus on these things and get them firing on all cylinders i think we could have a really great game.

Although there is a lot to be fixed and modified in this game. I like this game better then all the other game I have created in this class so far. The reason being is for these things:

- Game mechanic (polarity)

- Theme

- Level Design

I believe we had one of the more novel mechanics in our game than the other games that were presented. I thought that the polarity idea was very creative and could be taken to a whole new level. however we were not able to showcase the mechanic fully and to the caliber that I wanted. I also thought the theme of two magnets was a very novel idea as well. I have seen elements and and stuff interact with each other a bunch of times. But I cannot recall a game that uses two magnets while using the the physics of toggling polarity to reach the end of a level. And if we could make it 3D and be able to use polarity to manipulate objects and move around the map i think it would be such a fun a game. I feel like even though we didn't make an amazing prototype I think that this mechanic and idea could be brought so much further and feel like we could do do that as group. But we did our best and that is all I could hope for in a group. And a HUGE shout out to James Pratt for grabbing the bull by the horns and taking on the role of being the main programmer. He did a great job. I would love to work with this group again.