Part 5
With many of the game mechanics settled, now we are focusing on level design. The game will start out with a tutorial level telling player about the controls of the game. Once they exit the tutorial, they will go into a crossroads room. From here, there will be 3 branching paths. For progression through the game, we were deciding to either go for a branching path, which is a game which has optional routes which you can take to get additional items or rewards with another path that progresses the level and story, or a linear game where everything is in one line and more mechanics or levels are given out as you progress through the levels. Both have their pros and cons. Branching games give players more choices which may engage them more but backtracking may turn them away from it. Linear games are good for players who dislike backtracking but players who want more choice may find it confining. Overall, we decided to go for a branching game. We want to have branching paths to allow the user to choose how to play the game. Users can go for each extra item or challenge themselves and try to finish with only the starting item. This is in hopes of introducing replay ability to the game so that the player will have reason to come back and try different things with the game. If we are able to create more levels at a future date, we will be able to use this to create an extensive experience for the player. On the paths, we will also put indicators that symbolize the contents of each room, but the players will not know what they mean. We did this so that later on the player can learn for themselves what each indicator symbolizes and choose how to play the game accordingly. Two paths will lead to optional helping items like another gun or a health pack while the last one progresses the game. Once the player finishes the room that progresses the game, they will have another crossroads with similar branching paths. Now the game progressing room will lead to a boss which upon defeating it will finish the game. For the guns, we decided to have some obstacles like laser traps or dart traps blocking the way of the player from getting the gun. The laser traps had laser coming out in a cross pattern while rotating while the dart traps would shoot darts that dealt damage as well as slowing the player while taking some damage over time. The two puzzles both involve getting the timing right to get past them but we felt we could use them both to design different types of puzzles. We decided to put a puzzle to make the gameplay vary from the usual combat of the other rooms. We also wanted to make the player feel like they earned the weapon. For the actual design of the puzzle, we also tried to make it so that the player would be able to see the obstacle coming and not have something appear from off screen. This is because we wanted the players to not feel like the obstacle was unfair. Another thing we tried to avoid while creating the puzzle was sections where the player would get hit no matter what. I believe that players should have their skill at the game matter so having unavoidable damage from a puzzle was something I tried to avoid. For example, I designed the dart trap room and while I placed the traps around, I realized that there was certain sections where I found that players would get caught between traps and get sandwiched. From there, I learnt that I should try avoid unfair situations while designing the puzzles. As for the combat rooms, they were laid out in a way that there was an initial burst of enemies and “dens” which periodically spawned enemies the longer you stay in the room. At first, we were afraid that players could not clear the enemies fast enough and would get bogged down by the constantly spawning enemies. However, I felt that putting spawners was a good way to make players moving quickly and efficiently through the room and try to progress. Additional effects added included sound effects for walking, firing the gun in its different modes, as well as background music for the boss fights. Ryan was the one who mainly found them and we decided to add them to create a better atmosphere and set a tone for the game. We also wanted to give the game an extra ‘oomph’ feeling which is why we added certain sound effects. Notably, I want to highlight that we didn’t put any overworld music as we wanted to convey a feeling of loneliness and being trapped on a desolate planet. Other things we missed out for the final game was sound effects for reloading, trying to shoot an empty clip and start menu music. Conclusion Overall, I feel that designing my first video game was a good experience. However, I do feel that I would have like to design more interesting mechanics so I hope that in the future I will be able to think of some cool gameplay mechanics that will be able to catch other people’s attention
0 Comments
Part 4
We have decided to scrap the sniper as a weapon as we felt that the good qualities of it for overshadowed by the other weapon types. Our main goal when it came to designing the sniper was low fire rate, high range and high damage. However, the laser ended up fulfilling what the sniper was supposed to do. We were also running out of time to code puzzles for the sniper pickup so in a sense, removing the sniper was also to cut down our workload. Furthermore, we also wanted to buff the laser’s damage as it felt like it was doing too little for what you have to give up in order to use it. In terms of user interface, we switched the ammo count to the bottom of the player so that the player will be able to better keep track of the amount of ammo that was in the clip. Other mechanics that we added is a dash and a shield. Ryan coded the shield while I coded the dash. We decided to have a dash to help the play avoided certain obstacles. This also opens more options for us to design different types of levels as having a dash will allow us to increase the distance between safe zones for example. Also, just moving around felt a bit clunky so we wanted to make movement feel more fluid for the user. The dash will also work off a charge system. Player has three dash charges and use one charge per dash. Charges come back over time. We decided to implement this as without a charge system, we realized that players could dash all the time to the end of a room, especially those that contained just enemies rather than traps. We also felt that this was a good way to make the player use their dashes in a smart way rather than whenever. We also decided to add a shield to the game. How the shield would work is a resource bar just like health. Upon activation, the shield would take damage instead of health and upon the shield’s health depleting or the shield’s time limit finishing, the player’s health would take damage instead. The shield would then regenerate up to capacity after which it is ready for activation again. Initially, we set the shield’s capacity to 100. However, we found that we could not get the full value of the shield within the time limit so we put the shield’s capacity to 50. Therefore, instead of a longer wait time between use and less value on use, the lower capacity made it so the wait between uses was shorter and uses had more value. I also added a death animation for the player to better transition between the game over and live state of the game. I also added a proper start menu as well as a game over screen. We made it so that when players die and restart, they will spawn at the start of the room. This is to avoid frustration that players will experience if we were to make it so that they must complete the whole game from the start if they die, which is personally a major turn off for any games I would play. Part 3 To not make losing health feel as punishing for the player, we decided to implement health packs which the player can pick up around the map. On pressing the health button, the player will gain back 30 health and reduces the amount of health packs they have by one. They will start off with 3 to start and can pick up more as the player goes along. As for level design, currently we are deciding for a combat room and a puzzle room for each gun we have in the first level. Going for each gun is entirely optional as we wanted to give the player some choice and reduce any feelings of linearity. From the last entry, we have also changed the guns. The first gun is the default and given from the start, which will be a rifle which fires a standard rate in a straight line and is medium range. The second gun is a shotgun which shoots bullets in a cone in front of the player. This gun will be mainly used for short range engagements. The third gun is a laser mode. As you hold the trigger, it fires up and does more damage over time until it overheats which is shown by a meter. This gun is for a strong burst of damage over a relatively short period of time and will have quite a long range. To balance out its high range, the player will be slowed done while firing the laser and cannot dash. The final gun is a sniper which does high damage over long distances but has a low fire rate. We wanted to give each gun their own strong qualities that amplifies different player’s play style. As such, they are also free to go to whatever gun’s puzzle and try and get the pickup so that they can use it. Initially, one of the guns we wanted to have was a charged shot which exploded on impact. However, we were not sure how to code the gun so we decided to scrap for something more simple. We also plan to have an objective to complete for the first level and once that objective is complete, the player can face the final boss which will have 2 phases. We have also decided how the two phases for the boss will behave. The first phases will involve the boss keeping their distance and spawning enemies and shooting projectiles. The second phase will have the boss start dashing towards the player and will deal damage on contact. We decided to have multiple phases so that the player will have to change up how they play against each different phase. It also helps to vary the gameplay and the variety of what the boss does. For normal enemies, we currently have 2 variants. The first enemy will rush the player upon getting a line of sight on the plan and will deal damage if the player is within range of the enemy. Initially, I wanted the melee attack to be a projectile in a right in front of the enemy object that would hit the player. That way, there could be a hit box which players could avoid which encourages more skillful play. However, I was unable to code it in time, so I had to settle for doing damage to the player if the player is in range. The second enemy will be static and fire projectiles that deal damage to the player. We decided to have at least a melee and range enemy to make the player have to come up with different way to avoid their attacks and destroy the enemies. If we have the time, we will also try and think of new enemy types to keep gameplay varied. Some examples that Ryan came up with include a tanky enemy which has a shield at the front or ranged enemies with different projectile patterns. As for user interface, I coded an inventory bar with a slot for each of the four guns that we have as well as a slot containing health packs and the amount of health packs remaining. There is also a health and shield bar as well as a mini map which highlights which room you are in relative to the other rooms. Currently, the level’s objective was initially to find fuel so that the player can escape. However, we have changed the level to the player finding his way to a safe location so that he can find a way to escape later on. For the story, if we create more levels, we will be able to expand on the story more and create a more comprehensive story. I am also encountering more bugs such as projectiles firing in the wrong direction or the player not moving over to the next room. Currently, Ryan and I are still trying to fix any bugs that pop out in our own sections so that we can get a complete version of the game. This way, since we know our own sections best, we can be more efficient in solving our own bugs. Part 2
We have solidified the idea for the game being a top down shooter with 3 different weapons, each with a different gimmick. A laser which slows you as it charges up, a charged shot which explodes on impact, and a spread shot that can bounce off walls. The story is that the player has crash landed on a planet with hostiles and must find ways to refuel. The fuel is being guarded by enemies as well as there being enemies roaming about. We will also have a boss with different phases and attacks. Currently, the plan is the first phase will have the boss rushing towards you and will deal damage on contact. He can also charge a laser that the player must avoid. The boss will go into the second phase once enough damage is done, after which it will start dashing to deal damage. The laser will also charge up faster while in this state. Also, some ideas for enemies guarding the fuel could be an alien village that attacks you if you enter their area with 3 minions and a stronger minion and you must get through them to get the fuel that is hidden in their village. The sprites for the enemies and bosses will be taken online and we will be adding some obstacles like rocks on the map. Part 1
Currently, for our game, we have decided to do a top-down shooter. We plan to do 3 levels with bosses on each level, with a final boss on the last level. In terms of gameplay, we will be go through different levels with different attacks. For example, I have tried designing an attack that bounces of walls that disappear after a certain amount of bounces and a regular projectile attack. Hopefully, we can think of more attacks to increase the variety for players. In terms of enemies, we plan to have enemies that rush you and use melee attacks as well as ranged enemies that may be able to go invulnerable for a time. Some other concepts we thought of as well include a spawning enemy that produces minions that rush you and you have to fight your way through to clear the room. For boss fights, we haven’t really thought of anything yet, but I was thinking I want to make use of weak point mechanics were you expose a weak point in the boss and attack it in a certain way. Currently, I am trying to think of player attacks while Ryan is trying to think of levels as well as how the enemies will behave in the game. This game will mainly be targeted at gamers who are action oriented as the game play we want to have will be fast paced and required good reflexes so we will be trying to design the game towards that direction Overall, everything is still in the process of being designed and how to program this in GameMaker hopefully, we will be able to add more content in the game as time goes on. Working on the orphan character from the previous workshop, having had to fend for himself from a young age, this character is still bitter towards his parents as he feels that they left him alone in this world. As a result, he is very cynical. However, he still has his group of childhood friends, which is what he fights to protect as they are the last people he cares for. Therefore, he also does not trust strangers and is very protective towards his friends.
His appearance is that he has messy hair and weathered clothes from long times on the move in the wastelands. He also has multiple scars on his body from fighting off other people or wildlife that have adapted to the wasteland. You could say that he has a veteran's appearance. Part 1
A role playing game that I enjoyed playing was Fire Emblem: The Sacred Stones. This game's story follows a 5-part hero's journey. Summary: The game follows twins Ephraim and Eirika, who are royalty in the country of Renais. One day, Renais is suddenly invaded by their neighboring nation, Grado, who takes over Renais and destroys the country's Sacred Stone, which each country in the continent has and binds the Demon King. The twins are separated during the attack but later meet up in a allied nation after which they set out to gather all of the Sacred Stones so that they can protect it in a central location. As the story progresses, it is revealed that it is their childhood friend, Lyon who is the prince of Grado, that is behind everything as he was possessed by the Demon King while trying to use Grado's sacred stone to revive his dead father. Lyon manages to destroy all the Sacred Stones and the Demon King is released. The twins then fight the Demon King and defeat him. Afterwards, they go back to Renais and rebuild the nation as co-rulers. Part 2 Set in a alternate universe where the Cuban Missile Crisis resulted in a global nuclear war, you were orphaned after the initial missile strikes while your parents were away on a business trip. As a result, you are left only with a group of friends which you were with at the time and you have been trying to survive ever since. 5 years on, Survival is hard as radiation from the nukes still remain which leaves North America a desolate wasteland. However, you find out from a group of survivors that there is a large refugee settlement set up in the southernmost point of South America. However, there are limited places so you and your group must race to get to the settlement as quickly as possible. After many struggles and losses, you and your company eventually reach the shelter and can finally try to settle down and create a new life. Concept 5
In the light of all of this, we made a decision to scrap all progress we made in create a game. I believe this was a good decision and our previous concepts had a lot of baggage and all of us just did not want anything to do with them any longer. To help in the brainstorming process, we decided to list out why we felt that previous board game that we played felt like they were so much fun. We also agreed to stay away from the previous mechanics we used like simultaneous selection and player elimination. We used Carcasonne, King of Tokyo and others as examples and found four reasons why we thought that these games were fun. First, there was always a way to win. Second, there was strategy involved. Third, taking risks had equal rewards and lastly, we always had decisions to make. Checking back with our previous game concepts, we realized that none of them fulfilled any of our requirements. Hence, we decided to scrap the game concepts we made before and started anew. So, after a fresh start, Ryan suggested we look through a list of board game mechanics and pick up one each and see if we could make some core gameplay functions out of it. We discussed back and forth and I suggested a game involving a student vs teacher setting. Based of the setting, we sat down and discussed what core gameplay mechanics we wanted to implement. Eventually, we decided to use a card game to simulate a ‘cheating in a test’ situation. The cards were all inspired by what all of us would imagine someone cheating would try and do so we decided to create cards to simulate this. We also balanced the points based on how risky a plan would be in real life. The game would run for 6 rounds. The first 4 would be pre-test and the last 2 would be test rounds. The points gained from flipping cards would differ based on the phase. We got inspiration to implement this mechanic as some things you do before a test may not be acceptable during a test. On the Student phase, they would work together to create conditions to cheat. They would then place 3 cards face down and the Teacher would flip them. For flipping cards, Ryan and I decided to create a energy for teachers to use their cards,So, when they flipped cards, the teacher would gain suspicion, which could be used to use his own power cards. This was to give the teachers some strategic choice instead of just flipping cards. This concept also faced some problems. For our initial version, the Teacher only had one flip per turn and if he had a flip that did not give him much information in the first few rounds, he would not have enough information to be able to deduce the plans of the students. So, to counteract this, we decided to have two flips in the first round followed by two flips only if the Teacher gained points from the first flip. Other problems we faced included the Teacher winning by points even if the Student managed to get a condition or the Student being unable to set a condition by the time the test phase started. Conversely, the Students could somehow win even without any conditions just because the Teacher flipped too many safe cards. I encountered this while play-testing as the Teacher, so I gave some suggestions to try to make both parties satisfied. Eventually, to counteract both of these, we made it so if cards such as Phone or Notes made it through undetected by the Teacher during the test phase, the Student would gain points. If not, the Teacher would gain points. The point of this feature was to make it so that there would also be a way to win, which was one of our criteria for what made a game feel fun. We also had to balance some of the Teacher cards as the Confiscate cards were initially only 2 suspicion to play as I found while playing as the Teacher that as certain cards are of higher quantity, this naturally makes it more worth it to use it on that. So, we decided to change the cost based on the number of cards in the deck to make it a larger commitment to remove the higher quantity cards in the deck. Conclusion Using our 4 requirements as a guideline to conceptualize and balance the game was a great help towards creating the game. Admittedly, improvements still can be made to the game such as making the early game more complex as currently it is just a matter of flipping the card and getting the information to make the actual strategic decisions. As time goes on, hopefully I will remember all the concepts I learned and implemented in this assignment for future projects. Concept 4
Therefore, we decided to change the game into a 1v1 card game. How this game ran was that players would draw 4 cards at the start of the round and you could choose to attack, defend or support with your cards. Attacking still used the simultaneous selection and type effectiveness to deal damage. Having a card on defense allowed you to swap out with the attacking cards in case you did not like the match up. Support allowed you to use the card for more utility, such as drawing cards and damage mitigation. For this concept, I mainly tried to balance the various effects as well as give my input while play-testing and an issues that me and the rest of my team found was hand management. We soon found that to be a big problem as there was not much way to refill your hand unless you found one of the draw cards. Basically, the game was just a race to see who would lose first by exhausting their hand. We tried various measures to counteract this such as the defender of an attack would take their card back while the attacker would discard or variants of this such as the defender and attacker would discard their initial cards and draw a new card. However, these solutions also opened up new problems. In the case of the defender keeping their card after getting attacked, if the defense was an Elder Dragon, the strongest card in the game, the defender would just keep spamming that card in defense. Other options we explored included creating a tier system of dragons (lesser, normal, greater). The different tiers of dragons would also have stronger support effects while having stronger attacks. However, I feel that the problem with this option was that the lesser dragons felt really bad to draw which also brought about balancing problems and it also did not change the problem with the hand running out. We also tried an evolution system where elements could be combined to created stronger elements but we ran into problems with type effectiveness and it also did not really feel like it could be used in the game while play-testing. We also faced problems with the defense system. During play-testing, players would just keep their cards in their hand for the defense against an attack and not place it down for defense. When asked why, they said if the defense card was going to die, it was more worth it to play it from your hand and get it back after defense rather than use the place down defense and lose the card entirely. Eventually, we even had to scrap the defense feature all together. Similar to all of us our previous concepts, the game felt like it was extremely hard to make it feel fun and strategy as well as balance it so that nothing felt overpowered. To slow down the game, Ryan also suggested that we try to use a charge mana system where you can spend a card to charge a mana which allowed you to play a card so you had to balance between charging your mana and attacking/using utility. At first, we had element specific mana, so if you charged mana with a lightning card, you had one lightning mana to play a lightning card. Later on, we changed it to all-purpose mana as the elemental mana felt restricting. However, in the end, the mana system did not bring much strategic elements to the game as there was no reason not to charge at least one mana a turn. Overall, one big problem we also faced was that the game just did not feel fun. There was already not much strategy involved as it felt like just putting down cards to fill out the turn instead of thinking of cool ways to outsmart the opponent. The main reason we felt like this while play-testing was that the dragons did not really feel differentiated from each other so it just felt like you were doing the same thing over and over again which made the game not feel fun and instead made it feel like a boring game. At the end of it all, the game just felt like putting down cards till your hand was empty and then if your opponent somehow manages to draw a card draw, it gave a feeling of 'I guess I lose' and that you could not really do much to stop it. Concept 3
Our 3rd concept was to still use the dragon pick up system but instead try to create different effects for different dragons so there was incentive to go to different dragons. Ryan, Austin and I thought of the concept and we decided to go for elemental dragons as a theme and we implemented a type effectiveness system similar to rock, paper, scissors. In a challenge, both players would reveal a card simultaneously and if your card was effective against the enemy dragon's type you would deal more damage. For movement, The two action points still applied as we wanted to create meaningful decisions. Now you could play certain dragons, which cost one action point to play. The elemental dragons would be the 'combat' dragons and we also had support dragons that were more utility based, of which we placed some effects on them. For example, we had a dragon were players could have a extra movement point on use and another that could heal the player's health. For this version, my main contributions were brainstorming the elemental dragon idea with my teammates as well as thinking of the various elemental and support dragons that would fill the game. During our playtests for this version, we were given feedback that a board did not really feel necessary as it did not add much strategic elements. Also, we had a retaliation mechanic, so if you got attacked, you would hit back for a certain amount of damage based on how effective your type was. However, this caused a problem where it did not feel worth it to attack another player as at certain times you would take equal amounts of damage. So, we decided to adapt the game into a card game while keeping a lot of the concepts that we were able to think of initially while brainstorming for this concept. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
August 2018
Categories |