Ilyas's IGB220 Reflective Journal

It was an interesting Journey I must say !

>.<

Cya 

As a group , we collectively playtested 12 naive users for our three versions of the prototype. The information retrieved from the playtest allowed our group to gain a better understanding of the changes that needed to be implemented.  Majority of the  participants involved in the playtesting had prior gaming experience which made it easier for us to explain the concepts and features within the deep playtest. The participants also participated in answering the playtest questionnaire and survey which provided us a substantial amount of quantitative and qualitative data to work with for the report. The playtest sessions with the participants lasted around 25 minutes to an hour sometimes due to gaining more feedback from enthusiastic participants. The age rank of the participants ranged from 12 years old to 32 years old which provided a better idea of how different generations play and their thinking process of games.

I have attached the results from the playtest questionnaire.

We conducted our play testing session with another group within the workshop in week 11. For this playtesting session, we took the informal approach and didn’t use any script when it came to asking questions about the player’s experience. The data retrieved from the playtesting session provided us an insight into the shortcomings of the prototype and what aspects to improve on for the next development iteration.

The players found it difficult to shoot the enemies which my team member followed up with the question “why?” and their reasoning for their experience was the enemy were blending into the background which made it somewhat difficult to spot and keep track of the enemy.  One of the suggestions made by all the players from the other group was to include a mini-instruction manual at the beginning of the game to guide players in using the ace pilot as most of them didn’t know they could use the up and down key to maneuver in the game.

 Recommendations from players:

·         Add a live system

·         Change the pattern of the enemy due

·         Add a small delay to the bullet because rapid fire is a bit too overpowered.

·         Randomize enemy Attacks as it is easy to read the next move made by the enemy.

·         Change the player’s bullet color to blue to differentiate from the enemy bullets due to the confusions caused numerous bullets on the screen

As a group, we have agreed to change the old enemy designs of the asteroid prototype to the new designs developed by our team member Patrick. The new designs of the enemies are attached below within this blog post. The new enemy designs include the first type enemy, second type enemy and mini boss.

The first phase of the development, we focused on adjusting the spawn point and modifying the size of the new enemy designs due to a new flaw we identified when we tested the prototype ourselves. The issue we identified was associated with the width and height of the new enemy designs which wasn’t modified to the previous figures which pretty much led to a gigantic enemy randomly appearing on the screen once you kill the first type of enemy within the first level of the game shown below. This issue was resolved as we altered the width and height of the new enemy designs in windows paint. The new theme add-ons we included within the first phase of the development was the design of earth which sits behind the player’s pilot. We positioned the earth behind the player’s ace pilot to showcase what the player needs to protect from the enemy as this will play a significant factor within the story line of the game last man standing. The player’s ace pilot has also been changed to a new design created by Patrick which is attached below in this blog post.

The last assignment of this unit requires us students to form a group with each other to create and develop a playable game for players to test. For assignment 3, I formed group 11 with Jamie and Patrick from my workshop. As a group, we analyzed each other’s one-page and came to an end point decision to select the best suitable prototype for assignment 3. As a group, we have selected Jamie’s asteroid prototype for Assignment 3 as it’s not too complicated or simple to iterate upon in three weeks of time which had to be realistic about since we had other responsibilities.

We discussed about future implementations of designs, changes, new levels, and a story line for the game. As a group, we have allocated different and similar team roles for each of the team member for the development of the game last man standing as you can see below.

Team Roles: 

Jamie: Level     Design, Writer, Game Programmer

Patrick:     Character Design, Level Design, Writer, Game Programmer

It took me quite a while to come up with a theme for the racing prototype as I had no idea on how to approach in designing my sell sheet and creating my one sheet as I stated previously in my assignment 2 progress post. For the final designs, I used photoshop to design my sell sheet and word document to include details about the prototype in the one sheet. The purpose of my sell sheet is to provide an insight and an idea of my game to potential players. The colors I went with for my sell and one sheet is white, green, and yellow to match what an f1 racing track would like.  The one sheet allows other game designers to gain a better understanding of the game features and game mechanics. I’ve attached the final designs of the sell sheet and one sheet.

At the meantime, I have many ideas, but I don’t have a plan or strategy to create my sell sheet and one sheet. I also have no idea on how to design my sell sheet. I don’t know if using photoshop or word document will allow me to create the visual concept of the sell sheet I have in my mind.  I have not yet thought about which features I’m going to list on the one sheet.  I want to ensure that my sell sheet is presentable and explains the idea of the racing game towards my demographic as explained by Tracy Fullerton in chapter 16 : “Selling Yourself and Your Ideas to the Game Industry, page 498-499”.

If I had another opportunity to develop the racing prototype, I would ensure the prototype is playable and conduct mini play testing sessions myself after implementing any new changes in GDevelop to ensure the game doesn’t break. I would also allocate more time in developing the racing prototype to ensure I have a playable game for the player to test out and play without any significant setbacks caused by any type of flaws.

This time, I only got one player from the workshop to test and play my prototype in the week 8 workshop. The downside of this playtesting session was that I didn’t receive enough critical feedback due to the limitation of my prototype which didn’t provide the player much to do in the game.  The reasoning behind the limitation of my prototype is since I didn’t have the opportunity to finish or polish my prototype because I had to allocate my time and effort towards other units.  Even though, I didn’t finish my prototype, I still got the opportunity to gain an insight and thoughts upon my unfinished prototype. I also made sure to notify the player to provide me honest feedback and not worry about me getting upset or anything.

The player stated that he found the game unplayable due to several flaws that was present during the play testing session. The player stated that he liked the movement of the main red car but didn’t find it smooth when it came to switching lanes to avoid oncoming cars. The player stated that the spawn point of the green car made the game unplayable and annoying to deal with. The player’s reasoning for his dislike of the green car’s spawn point is due to the lack of time given to the player in dodging oncoming cars. He also stated that the spawn point of the green car was too close to him which he found it too challenging to avoid. The player suggested that the tress should look more natural than staggered. The player surprisingly liked the snake concept and movement of the oncoming cars but didn’t like the fact that he couldn’t really dodge them due to the oncoming cars taking most of  the space in the game window.

The development phase of the racing game didn’t go as smooth as I wanted the process to be. The reason for the poor quality in developing the racing game is because I didn’t have enough time to devote in developing and adding my own creative spin on the racing game which led to a few major errors that I overlooked when I labelled the conditions and actions in Gdevelop. At the meantime, the racing game I developed in week 7 & 8 wasn’t on par with my elevator pitch due to several missing features and objects.  

The issues I stumbled across during the development phase of the racing prototype included a few major flaws that I was only able to figure out during the playtesting session, thanks to a colleague from the workshop which helped me with correcting my mistakes. I misspelt “TreeTimer” and “TrafficTimer” which led to duplicated objects in the racing prototype. Another significant issue I was dealing with, was that the cars were moving towards the main red car at an angle over the lanes which wasn’t supposed to happen.  I have attached a video of this below to provide an idea of what it looked like at the mean time. As you can see from the preview, the racing prototype was unplayable.  

If I had to redevelop the asteroid prototype, I would regularly spend at around 15 to 20 min play testing the asteroid prototype myself to identify any flaws and ensure it’s working and functioning properly to reduce any type of setbacks in developing the prototype.

If I had another chance to redesign the asteroid prototype, I would include a reward system to entice and reward the player for their unique plays in surviving the rounds. This would also add a sense of excitement once the players are gifted with power ups to utilize against asteroids and the enemy ships.  I would randomize the spawn points of the asteroids to increase the difficulty as the second player stated within the play testing session that he could easily adapt to the static spawn points which he thought made the game less challenging. Taking both players advice, I would include a scoring and high score system which will allow players to view their score and achievement. I would also include the concept of gathering points or power ups through destroying asteroids to reward the player, but this would depend on the number of asteroids the player has destroyed without taking damage.

I got two of my colleagues in my workshop to play test my asteroid prototype which has given me an insight into their experience and thoughts of playing my asteroid prototype. I collected informal qualitative and quantitative data from their play test experience. The feedback collected from their play test experience will allow me to gain a better idea and understanding of the expectations and demands for my asteroid prototype. What I learned from reading chapter 9: play testing , page 278 is that playtesting within the early stage of development is critical as this allows the game designer to modify the core fundamental of gameplay to meet players expectations and needs compared to after production which is too late and might cost the game designer or game studio more time and money which we want to avoid.

The first player suggested that I change the number of bullets to one to increase the difficulty because the current rapid-fire of the bullet destroys multiple asteroids at a time which decreases the challenge and tension for the player as he further explained his reasoning. He found the controls smooth and liked the concept of using a mouse to steer the ship compared to using key arrows. I asked the player for his thoughts and experience using the rapid fire equipped with the ship. He thought the rapid fire was a good addition to the game system but didn’t like the idea of how easy it was to destroy multiple asteroids at one click with the bullet fire rate which he thinks is a downside to the rapid fire.  I asked the player for his opinion based on the enemy; he liked the idea of an enemy to deal with but wished he could kill the enemy ship so he could fight back as the enemy ship wasn’t operating at a functional level but just moving from one side to another in a repetitive manner.

He suggested that I include a scoreboard to display the player’s progress and score. He also said adding a high score would be a nice addition as he stated he could compare his high score to his friends. He also suggested to reduce the amount and pace of asteroids on the screen as he found it somewhat challenging trying to maneuver around the asteroids due to a great number of asteroids popping up. He also pointed out that the ship hitting the asteroid wasn’t accurate and suggested that I make the animation of the scene more natural and smoother. He found the game over scene simple and nice. He recommended to me that I should include laser power ups that shoot everywhere on a condition that the ship meets a certain number of points when destroying several asteroids. He also liked the idea of only having one life as he stated that this would make it easier to compare scores with other players without having to wait for a while. I asked him if he understood the objective and he stated that it was clear from the beginning as it is a straightforward game concept.

The second player also liked the rapid fire of the bullet but recommends I should increase the amount of damage an asteroid can take to balance out the game mechanics.  The second player also liked the smoothness of using the mouse to direct the ship on the screen. The second player didn’t like the pace of the asteroid as I requested him to further explain why, he stated that it should be easier for the player to dodge the oncoming asteroids. He liked that the game was in full screen which he explained further that he didn’t have to squint his eyes. He didn’t particularly find the asteroid prototype challenging as he stated that there’s only asteroids to destroy. He also suggested that the main threat should be the enemy ship while the asteroids are secondary to increase the difficulty and make it more challenging for the player. He also suggested that I should include a scoring system. The second player also pointed out towards to the end of the play testing session that there weren’t any instructions when the game over scene appeared, but I explained to him that the game resets after 15 seconds.

The asteroid links provided in the week 5 workshop document to help us get inspired gave me confusing and a mixed feeling experience playing the asteroid games. There were no visual instructions outlining the key binds to steer the asteroid which undoubtedly took me a while to gain a better understanding and knowledge of which keys to steer the ship from oncoming asteroids. The reason I went with using a mouse to steer the ship compared to using key binds to steer the ship is because it felt clunky and awkward as the movements from the ship didn’t feel natural or smooth as a player. Furthermore, utilizing the mouse will allow the player to easily adapt to the controls and provide a better experience compared to using key binds for steering.

I took the iterative approach when developing the asteroid prototype to ensure that this time I had a game for my colleagues and players to test so I can gain a better understanding of the expectations and requirement to build a successful play centric experience. Implementing the iterative process in the development phase allowed me to evaluate the aspect of my prototype and communicate my ideas more clearly as I was struggling to visualize what I really wanted which Tracy Fullerton discusses about the concept of the iterative process in chapter 1, page 17.Taking the iterative approach has allowed me to identify a few issues I had with developing the asteroid prototype. For example, I found out that I couldn’t successfully set the condition of the number of lives to more than 1 without the scene changing over to the game over scene so instead I used this flaw to my advantage. I set the number of lives to 1 to enhance the difficulty which worked out in my favor at the end.

The other issue I stumbled across while developing the asteroid prototype was trying to successfully get the asteroids to delete the ship as shown in the video below when the asteroid touches the ship and ensuring the bullet deletes the asteroid smoothly which I achieved after playing with the conditions and actions for a while. Another issue that I came across which I couldn’t figure out without the help of my workshop teacher in setting the correct condition to successfully get the enemy ship from moving point A to point B in repetitive manner which I have attached a screenshot in this post below.

Title: Asteroid Blaster

 Asteroid blaster is a 2D game that takes place in outer space, where you play as a ship trying to reach your space station. The goal of Asteroid blaster is to survive the asteroid and enemy attacks to successfully reach the space station. As a ship, you are equipped with a blaster to destroy oncoming asteroids and enemy ships. The perks of destroying numerous asteroids provides you a power up that you can utilize against the enemy ship. The longer you stay alive and take less damage, the more asteroids spawn on your screen to really challenge if you have what it takes to dodge and destroy oncoming asteroids at a faster rate which will challenge your maneuver skills.

Controls:

·         Move the mouse or move your finger on the touch pad to move the ship.