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. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |