Assignment 2 - Possible Improvements in the FutureIf I am given the opportunity to improve or fix the game in the future, I will:
0 Comments
Assignment 2 - Error Fix(es)One bug that I managed to find after submission includes the transition from the end page to the credits page. To solve this, I modified the check that is in the step event of obj_lastroom_controller. The new code:
if (!instance_exists(obj_textbox)) and (counter == false) { textCreate = false; } if (instance_exists(obj_textbox)) and (textCreate == false) { textCreate = true; counter = true; } if (!instance_exists(obj_textbox)) and (counter == true) { ///Start game audio_play_sound(snd_menu,10, 0); if (!instance_exists(obj_roomTransition)) { var tempRoomFade; tempRoomFade = instance_create(x,y, obj_roomTransition); tempRoomFade.tempTarget = rm_credits; } } Assignment 2 - Designer Diary (Part 4)For the second version of our game, after receiving the feedback from friends, I decided to scrap the idea of the RPG and decided to start from scratch. After much consideration, I decided that I would make this game a bullet hell instead. This was because a bullet hell game would fit the criteria of a game that I wanted to make: fast-paced, fun and memorable. Even though I felt very lost at first (after losing almost all progress of the development of my game), after some encouragement, I finally picked up the pace and managed to get back on track to continue making the game. Thankfully, the friend who made the bullet hell game had given me some tips on how to start the development of the game. After that, I finally programmed a simple boss that manages to shoot projectiles in a circle. Even though it was still in the first stage of development, I somehow felt happier and more engaged than when I was working on the RPG. When I went home that day, I contacted Gi Kei on this major change of the game. Fortunately, she approved of the change despite it being a drastic one.
Before focusing on the programming aspect, I had to think of the basic aspects of the game (again), including the story. I decided that the general story could be slightly modified to suit the theme better (after dying in a car accident, the player wakes up in a dungeon). Instead of a forest, I made a dungeon as the main setting of the game. In terms of combat, I kept the resources that the player had (health, ammo, ultimate) and the player will attack will a machine gun and can place mines that explode when coming into contact with a bullet or an enemy. Also, taking some inspiration from Enter the Gungeon, I decided to implement a dash that can enable the player to dodge attacks. While coding the basic boss attack, I noticed that the projectiles were created in each frame (in 1 second, 60 projectiles were created). This resulted in my computer slowing down for a short period of time. In order to solve this, I started to watch videos related to the creation of projectiles, and after following them, the problem was finally solved. Now that I managed to get the boss to shoot in a circle, I had to start and design some attack patterns of the boss. After playing around with the code, I managed to code some interesting attack patterns that involve a shotgun attack and a ‘360 degrees’ attack. In order to add variety to the game, I decided to let the boss object create other objects that will act as minions. These minions would attack the player in their own unique way (e.g. one type of minion runs at players and shoots at them once they are in range). I felt that by implementing these minions, there would be more variety of attacks and players would not be able to remain stationary while dodging all bullets. Later during the development of the game, I decided that the boss should have several phases which will activate different attacks in each phase. The following week, I showed Gi Kei a partially playable version in class to get her feedback. While I was coding the game, I would occasionally notice some things I could do/add to the game. Following that, I would ask her whether a change I wanted to implement would be beneficial to the game. Most of the time, she would agree that the change would benefit the game, but she would inform me when she felt that the change could be implemented differently. After we were done discussing some ideas, similar to the previous weeks, we asked Dr Oon to give us feedback on this new version of the game. When he first saw this version of the game, he was surprised that I had totally redone the game, which was what happened in the previous assignment. After seeing some gameplay of the game, he (yet again) gave us some useful feedback, including problems of the game. Firstly, he mentioned that he liked the implementation of the mine since the player is able to cause a chain effect with the mine’s explosion. This was because the mines did not have a cooldown so an unlimited number of mines could be created, which made it overpowered. Secondly, he mentioned that I could not make the game to be too difficult since I (the developer) have to beat the game myself. After this consultation, I was glad since I finally felt that I was on the right track for the development of my game. After a week (or two), the time came to present our game to our class. On the first day of presentations, I volunteered to present my game since I wanted to get useful feedback as soon as possible so that I could start on the modifications. Unsurprisingly, the playtester of my game could not beat the game since it was too difficult. After he lost the game, I thought that I could beat the game, but it turned out that the game was also too difficult for be to beat. During the feedback session, many useful comments were mentioned. One of the main feedback that was given by both judges (Dr Oon and Ms Lee) was that I should not have a “permanent health loss” system (since health potions were not implemented), but instead have a “permanent death” system since it was too punishing to not have the ability to heal. Another feedback by Dr Oon was that I had to ask Gi Kei to code some sections of the game since GPN is still a programming course. Recognising that as my fault, I started to ask her to code some basic functions like the menus (start menu, pause menu, etc.). After taking all the feedback I have received into consideration, I managed to polish the game sufficiently until the submission date. Looking back, I should have better planned what kind of game I wanted to make so that I do not have to waste time working on a version of a game that will be scrapped. Assignment 2 - Designer Diary (Part 3)Following the first idea, for the first (implemented) version of our game, we chose to keep most of the elements of the first idea (except the setting and the map) since we felt that they were still good enough to be used. Also, the game became an ARPG (Action Role-Playing Game) since this genre suits the current version of the game rather than a ‘horror’/exploration shooter. Despite this, I still felt that the game did not have a fun factor. Unfortunately, even after discussing with Gi Kei, we both still found it difficult to implement something that could make the game fun.
This was when I turned to Google for help. After a few searches on what makes an RPG fun, I finally learnt what makes an RPG fun. One suggestion was to include quests that the player can complete. This way, players will have an objective to work towards, and there can be a sense of accomplishment after completing a quest. Another suggestion was to allow the growth of the player. This means that over the course of the game, the player will be able to become stronger to be able to kill stronger monsters, also resulting in a sense of accomplishment. After reading up on these suggestions, I shared what I read with Gi Kei so that we could both plan on what to include in the game. Also, taking some inspiration and ideas from Path of Exile (POE), I tried to implement some elements that make POE fun (e.g. quest, levelling, abilities, etc.). For subsequent discussions (during the GPN lessons), both of us were adding new elements to the game while fixing or removing elements that were already in the game. Taking the online suggestions into consideration, we added some new elements.
We also modified some elements of our game.
For the maze room (as mentioned earlier), we also had to brainstorm on what the maze should contain. While thinking of ideas of what to include in the maze, I had a thought of a “bogus door”, which means that the supposed door that leads to the boss room will not lead to the boss room, but an unescapable trap room. After sharing this thought with Gi Kei, she seemed pleased with the suggestion and we decided that we should add it to the room. We also thought of implementing traps in the maze so that players cannot navigate through the maze recklessly. After we had completed sharing these ideas with one another and had a basic playable game with some sprites, we asked Dr Oon to give us feedback again for this version of the game. After sharing our plans/ideas for the game and after he looked at our “bare minimum” playable game, he gave us more feedback, including problems with this version of the game and some ideas for the game. Firstly, the same problem and question arose: What’s the fun factor of the game? As Dr Oon continued to explain some of the problems, I began to realise that I had been thinking was wrong. I thought that by adding new elements like an experience system and a quest system to the game, they would make the game fun. Dr Oon later explained that these elements are standard for an RPG game, and there was still no fun factor of the game (that can make it stand out of the crowd). Secondly, it was mentioned that the maze room was not very polished and there was a slight problem with the implementation of a “fake boss room door”. Dr Oon explained that the idea itself was not bad, but later asked: Would players find it fun to enter the fake door? After that, I started to think deeper into the implementation of the fake door. When I tried to put myself into the shoes of the player, I finally understood the problem. I realised that it would not be fun for the player to get tricked by the door, and it was actually rather frustrating. After the consultation, I began to rethink some of the ideas Gi Kei and I had talked about. Later the same week, some friends and I stayed in class to complete some work. Making use of this time, I decided to continue to code my game while fixing some bugs. This was when I decided to ask them to give some feedback for my game. After playing the game for a short period of time, my friends started to give some critical and important feedback. Most of the feedback given was similar: the game was too slow-paced and there was no fun in playing/watching the game. One of my friends even said that the game reminded him of RuneScape, which was slow-paced to him (even though I wanted my game to be a fast-paced one). On the other hand, another classmate made a game that reminded him of Realm of the Mad God since it was fast-paced. This was when I started to give up on the idea of making an RPG game. This was because from the start, I knew that the RPG had to be large-scaled in order for it to be fun (for my theme). After this, I decided to scrap this version of the game (like the previous assignment, unfortunately) because of the lack of ‘feeling’ to properly code the RPG and the problems that I simply could not resolve within this time frame (knowing my capabilities). Assignment 2 - Designer Diary (Part 2)When my team first started to brainstorm on ideas for our game, Gi Kei and I produced many ideas for our game. Some of these ideas include:
After some brainstorming, we decided that the 'horror' exploration/shooter game was the most interesting idea out of all the ideas suggested, thus we started to plan out ideas for this game. Some of the aspects of the game we chose to settle on first included the Story Arc and the type of movement (for the player). I suggested the use of a ‘mix’ of the 3-Act Story Arc and the 5-Part Hero’s Journey since I wanted the story of the game to involve the player starting out with nothing and use the skills he/she learnt after a plot twist to complete future quests. As I had some difficulty in deciding on the type of movement (between a top-down game and a platformer) for the game, we decided to search online on the pros and cons of both types of games. In the end, we decided that a top-down shooter would be more suitable for our game when compared to a platformer because of a few reasons.
After deciding on these few aspects of the game, we started to plan out the progression of the game. After drawing out several sketches of possible maps, we settled on a design that involved the player starting out in one room (tutorial room) that branches out into several other rooms, and one of those rooms would be the boss room. At this point, the map contained several dead ends, and we decided to use this map design as I felt that this would encourage players to continue exploring through several rooms. Unfortunately, this was not the case (more details explained later). Before the end of the first meeting with Gi Kei, I suggested having interesting dialogue (e.g. dialogue that broke the 4th Wall) in order to make the game slightly more interesting and less serious or boring. Thankfully, both of us were interested in that idea, and we jotted down a script of the dialogue that would take place between the player and a Non-Playable Character (NPC), who was supposed to be the player’s guide through the tutorial room. After deciding on game progression and some basic aspects, I jotted down some ideas I had to make the game more interesting.
After all these ideas were suggested, we realised that we missed out on one very crucial element of our game: combat. Following this, we started to discuss what the combat system would include. Firstly, for player resources, we decided to use the typical ‘RPG’ player resources, which include the player’s health and energy/mana. To make this more unique, I suggested the addition of an ultimate charge (used for an ultimate attack) since this is not typically used in exploration or RPG games. Secondly, for the actual combat, we chose to implement a mix of a weak melee and a stronger, but limited ranged attack. This will ensure that there is a choice of attacks that the player can use and players will not be able to continuously use the ranged attack. By the time these were planned out, it was time to show our idea to Dr Oon and receive feedback. When we presented our idea to him, Dr Oon provided many useful feedback, including the problems with our game. Firstly, the game did not feel rewarding at all. For example, for the dead ends in the map, it was pointed out that there was no benefit when getting stuck at the dead end. To elaborate, if there was no incentive in entering rooms with the dead ends, the player will be “turned off” since his/her time would have been wasted and would not find the game fun. To solve this, Dr Oon suggested either removing rooms with dead ends or adding incentives to those rooms. Secondly, the game did not have a fun factor. Even though some interesting mechanics were included, they were not sufficient in making the game “stand out from the crowd”. Knowing that the idea was still in its early stages, we acknowledged the problems that it had and we started to think of ways to solve these problems. During the next discussion, we started to discuss about the suitability of a haunted house/serial killer’s house as the main setting of the game. This was because once we started to piece all the ideas together, the original setting did not seem to be suitable anymore (e.g. it did not make sense to have a melee and a ranged weapon when kidnapped (since the main story starts when the player is kidnapped)). As a result, I suggested that the main setting should be set in a forest instead of a claustrophobic house since a forest would feel more open. After some consideration, Gi Kei agreed to change the setting to a forest. In addition, we decided that we would keep the game simple for the time being and make it one-way (linear), solving the problem of rooms with dead ends. Assignment 2 - Designer Diary (Part 1)For the second GPN assignment, my team had many ideas for our game. However, similar to the previous assignment involving board games, many of those ideas did not succeed. In addition, even though I did not want this to happen again, my team had several (totally different) versions for our game.
Before my team started to brainstorm on possible game ideas, in order to learn the syntax of Gamemaker Studio and how it works, I tried to play around with the code that we had programmed before (with the 'Scout' game) and followed some basic tutorials on YouTube. Some of these tutorials had used the physics engine (in Gamemaker Studio), and at first, I thought that this would make many aspects of the game easier to manage (like collisions with walls/other enemies and movement). However, it turned out to be too much of a hassle in the long run (spoiler alert), and I decided not to make use of the physics engine. When my team had finally started producing ideas for our game, I completed the basic movement and some collisions of the player. At this point, however, all objects were still solid squares. Assignment 1 - Designer Diary (Part 5)For the last version of the board game, we decided to start from scratch and needed to rethink of another idea. Since it was difficult to think of a brand new idea, I suggested that we should start by listing out what makes board games fun (more specifically, what made the board games we played fun). Some of the board games we played in previous lessons were King of Tokyo, Love Letter, Nmbr 9, Carcassonne and Unusual Suspects. In the end, we concluded that there all had some similarities in terms of why they were fun. From there, in addition to the feedback we received about our previous games, we created a check with the following elements:
To briefly explain what each element means, Risk-over-Reward means that a decision a player makes may be very risky, but the reward will be of high value (am I willing to take a risk to hopefully get something valuable?) . Strategic Planning means that players are able to strategise and make meaningful decisions that can affect the game. Always a Way to Win means that each player can have a chance to win, and no one person has the obvious advantage at the start of the game. Decision Making means that players should be able to make a decision and not have one option that they will obviously take. When using this check on previous games, we found out that all the past versions of the game did not meet any of our requirements for a fun game and had failed the check. At this point, we felt disappointed yet relieved as the past versions of the game that we thought were fun were actually not fun at all, but we were relieved that we decided to drop the previous idea and create a new game before it was too late. For this game, we started with Ryan's idea of a game that involves Teacher vs Student. Since we all liked games with a mind game element, I provided ideas like a spy being among the players. In the end, After creating the theme of the game, we consulted Dr Oon for some of his opinions of our idea. He gave us some useful tips on how to plan the gameplay (Students rebel against teachers? How do students or teachers win?). Using some of the ideas he gave us, my team decided that the game would involve the students cheating and the teacher catching the students in their act. After the theme was finalised, we decided to make it a card game since we felt that a card game would be the most suitable game type since some of the ideas and part of the theme would not work well on a board. Some of the mechanics of the game include Set Collection, Hand Management and "Take That". In terms of gameplay, Students and Teachers have different cards, and there are 6 total rounds in the game: 4 pre-test rounds and 2 test rounds. Students can play cards that create cheating conditions in the pre-test rounds and can use cards to activate the conditions during the test rounds. On the other hand, the Teacher can flip 1 of the 3 possible cards played by Students in hopes of catching them in their attempt. When he does so, he gains a suspicion point which can be consumed to use a Teacher card (in their hand). Some of the effects of the Teacher cards include "disable all communication with one student" and "confiscate all phones". For the first turn only, Teachers are able to flip 2 out of the 3 cards played. After the first round, if a 'suspicious'/condition card is flipped (for example, a phone is one such card since students are not supposed to use their phones in class), the Teacher gains the number of points stated on the card and is then granted a second flip. By the end of the game, whoever has the most number of points win. While we were playtesting this game, even though it already felt more fun than the previous versions of our game, a few minor issues started to rise, but were eventually solved.
As mentioned earlier, the game already felt more fun than the previous versions. Here are some reasons why (while using the check):
Assignment 1 - Designer Diary (Part 4)For the forth version of the board game, our team decided to change the type of game, from a board game to a two-player card game. Now, the dragon cards are able to attack, defend and support. In terms of gameplay, players can play up to 2 of these cards in the attack, defend or support position (attacking is last). When a player attacks, elemental effectiveness comes into play again. Similar to the previous version, effective attacks deal double damage and less effective attacks deal half the damage (e.g. when a fire dragon attacks a water dragon, since water is stronger than fire, player who played fire dragon takes more damage while player who played water dragon takes lesser damage). To defend, players can either use a card from their hand or use a dragon in the defence position on their side of the playing field, and a player wins when the other player has 0 health remaining.
Originally, when players defend using a card from their hand, they will lose that card. After playtesting, however, we found out that players will not have enough cards in their hands after a few turns, so we decided that the card will return to the defender's hand after defending. After having a basic idea of the game, we felt that it may be too simple and wanted to add more mechanics to it. This was when I suggested the idea of having an evolution system where two dragon types could combine to become a fusion element (for example, earth and water could fuse to become mud). However, after we tested the game with this fusion system, we noticed that we would see no point in using this system. We then decided to change this system by including tiers (lesser, normal, greater) instead of fusing elements. The lesser dragons are not affected by elemental effectiveness and are not able to damage greater dragons. Greater dragons, on the other hand, are able to be neutral against the Elder dragon. After this (and more playtesting), we added more elements to the game, like adding Light and Dark dragons to the game and using a mana system where players can use a card from their hand to charge up their mana (can only be done once a turn). However, we found out that it depends on whether players are lucky enough to get cards with the same element to use as mana. To fix this, we changed the mana system so that any card can be used as mana (Elder dragon in mana pile is like a "wild card" where it represents all elements), but the mana is discarded when used. To make the game more interesting, we tried to add spell cards (with mana cost) to the game (some examples of these spell cards include "+2 health" and "Destroy one of the enemy's spell cards"). To gain feedback on our game, we brought this game to our class and some of our classmates offered to try out the game. We found out that they did not play any defence cards on the playfield and would only defend by using cards in their hand. When asked why after the game, they said that there was no point in playing any defence cards when they could just defend from their hand (since the card will go back to their hand and will not be discarded). In addition, one of the players got an Elder dragon in their hand and would continuously use it to defend (since the Elder dragon is stronger than most of the other dragons). After the lesson ended, my group stayed behind to continue working on our game (this was 3-4 days before the video pitch was due). While Tristan and Ryan was playtesting the game, this was when I asked them whether the game felt fun as from a spectator's standpoint, it might be interesting at first, but after a while, people may not play it again. This will affect the replayability of the game. They then said that it was not very fun after a while since there is not much strategy to this game. After all, we felt that the only 'strategy' of this game was to continuously charge mana and play cards, and hope that you can deal effective attacks. Also, The spells or support abilities did not feel very impactful at all. This was when we decided to finally scrap this whole idea of dragons and go back to the drawing board. Assignment 1 - Designer Diary (Part 3)For the third version of the board game, we kept the 12x12 board and the theme of dragons, but we chose to add elements to it. This was because the gameplay of ordinary dragons fighting was too plain, therefore to spice things up, elemental dragons were added. I also suggested the implementation of elemental effectiveness so the game is basically a more complex rock-paper-scissors game with the simultaneous and "zero-sum" mechanics.
In terms of movement and combat, we used the Action Point Selection mechanic again since we felt that players would at least be able to strategise where to go to. Similar to the previous version of the game, each player is given some of the elemental dragons at the start of the game to scatter on the board faced up. This ensures that there will be some strategy involved so players can make meaningful decisions. In this game, players now move around to capture elemental dragons to be used to battle other players in a "rock-paper-scissors"-like game. Players can capture a dragon by spending an action point. When players are within a 2 tile range, they can choose to battle. We chose not to force the players to battle anymore as we did not want players to feel forced to battle and wanted to give them that choice. In terms of the actual gameplay, the four elements we implemented are Earth, Fire, Water, and Thunder. To make the game slightly more interesting and fun, an Elder dragon is added. The Elder dragon is stronger and more effective against all elemental dragons, but there will obviously be fewer Elder dragons to balance the game by not having many overpowered cards. As previously mentioned, players carry out combat in a way that is similar to rock-paper-scissors. They will each play a card simultaneously and determine the amount of damage they deal and take. This is when elemental effectiveness comes into play. Similar to rock-paper-scissors (where rock beats scissors, etc), effective attacks deal more damage while less effective attacks deal less damage. In the case of the Elder dragon, it always deals effective damage. Similarly, we brought this version of the game to class and ask for more feedback. After we asked for some feedback, Dr Oon gave some useful feedback again. He also noted some of the game's problems and gave us tips on how to solve these problems. Firstly, it was mentioned that the board needed to be modified. While playtesting, we noticed that the game would take too long simply because of the size of the board. One suggestion was to make the board smaller so players can have more encounters with one another and gameplay will not take as long as with a bigger board. In addition, since the main aim of this game was to capture dragons and fight other players, another suggestion was to remove the board and converted into another kind of game. Secondly, there was no merit in meeting other players to fight. This is because when the attacker is in combat with the defender, there is no "Take that" moment and since the combat is so simple, players do not feel satisfied when in combat. Also, there is some luck involved because of the rock-paper-scissors mechanic, so one player could continue to lose just because of luck (or lack thereof). After taking the feedback by Dr Oon into consideration (including feedback from other classmates), I decided that we actually do not need the board at all and suggested making this game into a card game. Assignment 1 - Designer Diary (Part 2)For the second version of the board game, we decided to keep the theme of "moving around the map" and dragons, but we scrapped the class system. Instead, players will now play as students from Dragon Academy whose aim is to capture dragons and fight other players. Some of the mechanics like Area Movement and Player Elimination still remain. The 12x12 board from the previous version is used again. Instead of an Action Point Selection mechanic, we chose to use 2 dice as movement: 1 die that determines the number of tiles to move and 1 die that determines the direction of movement. The Merchants and legendary cards were removed, and a new system was implemented. Players now capture dragons by moving around the board using the dice and. The dragons have tiers that range from Tier 1 (weakest, most quantity) to Tier 10 (strongest, only one in the centre of the board). At the start of the game, players are given some dragons to scatter randomly on the board faced down. There are now 2 types of combat: combat with dragons and combat with other players. Combat now no longer includes health and damage, but the difference in tiers (more mentioned later).
In order to capture dragons, players will have to stand on a dragon tile for a number of turns to capture it. The number of turns to wait depends on the levels of the dragon and player ( (dragon level - your level) turns to successfully capture the dragon). At the start, players are level 0. After capturing dragons, the highest tier of their captured dragons is their level. If their level is higher than the tier of the dragon tile they are on, they only have to wait 1 turn to capture it. For combat with other players, if a player is within a 1 tile radius of another player, they must fight each other. On the other hand, if players are within a 3 tile radius, they can decide whether or not they want to fight. Of course, there are also issues with this version of the game. When we brought our prototype to class, Dr Oon provided many helpful feedback and tips to help us improve and fix our game. He also pointed out some problems of our game. Firstly, the movement is very luck-based. Originally, the reason why we wanted an Action Point Selection mechanic was because we didn’t want much luck in our game. However, after a team member suggested the use of dice for movement, we decided to stick with this system. After playtesting the game in class, we immediately noticed a huge issue. For the majority of the game, players are staying at their respective corners and in most situations, most of the players will never get the chance to fight. Also, because of this luck-based movement, capturing dragons was also difficult. Personally, while playtesting the game, even though there were a good number of dragons that were near me, it was frustrating when the movement dice brought me further away from where I wanted to go to. While playtesting, Dr Oon happened to be watching the gameplay and immediately pointed out this issue. Secondly, there is no strategy at all. Since the movement was totally random, players could not make any meaningful decisions, thus they are not able to come up with any strategies. In addition to the lack of strategy, the options were also not meaningful enough to work towards. Thirdly, since the dragons are faced down, players will be sceptical and may not feel encouraged to commit to getting the dragon. If the cards are faced up, players will be able to come up with a strategy and play around that strategy. Because of this, we decided to revert back to our original movement system of the Action Point Selection mechanic, but decided to add some new elements to it. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |