#Assignment 3 Playtesting

[donnatang]

Assignment 3 – Playtesting Summary

For the playtesting of our Assignment 3 game, I invited two friends to try out the current version and provide feedback based on their gameplay experience. Overall, both players responded very positively to the game’s design and creative concept. They found the visual theme engaging and were particularly impressed by the highway setting combined with obstacles, which added a sense of tension and immersion during gameplay.

During the session, both players reported being quickly drawn into the experience. The intuitive controls made the game easy to pick up, and they were able to grasp the gameplay mechanics almost immediately. The one-enemy-car-at-a-time system was effective in maintaining focus and challenge without overwhelming new players. This simplicity in interaction allowed them to stay immersed in the gameplay flow.

However, one of the most notable pieces of feedback was a desire for increased variety and excitement in the form of additional obstacles. Players suggested that the experience could be even more thrilling if sudden surprises—such as wild animals or fast-moving hazards—were introduced. These elements could elevate the game’s intensity and make each round feel more unpredictable and exhilarating.

In terms of usability, there were no major issues encountered. Movement and collision detection worked smoothly, and the enemy car system functioned as intended. The players felt that the game was well-balanced and did not require a steep learning curve.

In conclusion, the playtesting session validated the core mechanics and confirmed that the game is both accessible and enjoyable. The feedback emphasized the strength of the current system while also inspiring ideas for future enhancements, such as dynamic obstacles or animated threats, to further enrich the player experience.

[lilymakesgames]

Assignment 3 Playtesting

Playtest Preparation

The team collectively prepared a script, questionnaire, and survey to facilitate fair and accurate playtesting sessions. Our goal was to efficiently and sufficiently gather the most useful data to later interpret and thus use to improve our game.

Some of the playtesting resources themselves (namely prototype and survey) were also iterated as part of the playtesting preparation. This would not compromise any of the results as each prototype version will have a respective survey version that most accurately reflects the new iterations.

Some of the resources created/iterated to facilitate playtesting.

Post-Playtesting

Fullerton (2018) advocates for frequent and early playtesting to ensure that the M2M gameplay is developing in the correct direction and to identify unexpected issues that are unforeseen to the developers. It is important to receive feedback from eyes that haven't been pouring over the design; objective perspectives are also crucial to make improvements to our game (Fullerton, 2018).

For structure and efficiency, we also discussed our approach to post-playtesting processes.

After each playtesting session, whether informal or structured, we ensured to keep a record of the results along with a brief analysis of issues and "where to next?" discussions.

This involved analysing the results and then categorising issues by severity and type. This helped decide who would be responsible for managing the issue and also helped with tracking all issues and bugs collectively. Moreover, "managing" the issue involves analysing the respective data by identifying trends, reflecting on design, considering potential factors/reasons for the issue, and brainstorming solutions.

All of the above enables us to safely and effectively prioritise certain implementations for the next prototype as the results inform the direction of development. Reflecting on the results lets us continuously improve our game.

Additionally, please note that the extent to and formality of this documentation depended on the type of playtesting conducted, i.e., light informal playtesting = light informal documentation. For the minimum 5 playtests; however, we will endeavour to have very formal and structured playtesting + documentation.

Week 11 Playtesting

Light and informal playtesting with the very first build.

Current state of game in week 11.

Some of the findings from week 11 playtesting.

Thanks for reading!

End of post.

[cookie2351]

Assignment 3 Playtesting and Early Post Mortem

"The Curious Case of Hotel Hollow" gameplay testing:

We went into this game project with a large scope. The aim of the game was to solve the mystery by finding clues throughout the game while fighting off ghosts and navigating the puzzles of the hotel rooms. The players aim was to collect all the clues to reveal and then fight off the cause of the mystery. Or if they failed along the way and got too scared, they would run away.

As can be seen in the gameplay footage, the game incorporates a scare meter in the top left that fills up when ghost come into contact with the player. The player also has a torch battery that if it runs out leaves the player very vunerable to the ghosts, so they have to be careful with usage. There are light switches in the rooms that once turned on scares the ghosts away and allows the player to save their precious torch battery.

As the scope of our game was so big, there were some cuts made that we aimed to implement.

At this stage though the game is in a playable state!

To be added are the art assets as furniture decorations and objects. Also, the wooden and stone tile sprites to fit more with a hotel aesthetic.

With such a short time to create a viable project and such a large scope we are happy with our ability to produce a working game, although far from its original aim. We had grand ideas for the level design and decorations and player obstacles but just didn't get to the stage of development to implement them.

[skylerch]

Assignment 3 Playtesting

We conducted our playtest during the Monday playtest party by inviting five classmates to try out our prototype. The environment was a little noisy and we unfortunately forgot to turn on the game’s sounds for the first two playtesters. Although even after fixing it, the music is still hard to hear. My role was the playtest conductor. I need to guide the participants with the playtest instructions and encouraging them to share their thoughts and opinions as they played. Overall, I think the playtest went smoothly. At first I felt a little embarrassed, but our classmates were kind and provided some valuable insights through both feedback and their in-game behavior.

Something they all praised on is the game’s visual style! Which I really appreciated since I spent a lot of time on it. And the biggest problem they had with our game was it was too simple. While the players seemed to like the core Shadow mechanics with, they found the puzzles were too lacking in challenges and didn’t feel rewarding. This aligned with my own concerns during development. It made me consider where the source of this problem lies. Is it due to the map sizes being too small, so that there is not enough space for more intertwined puzzles, or we had not fully explored the mechanics’ potential, or the mechanics themselves being not complicated enough, or my brain being not good enough for designing puzzles? Perhaps all of them, this is something I need to think about.

A few interesting things happened during the playtesting. One playtester failed extremely hard with the platform jumping and it turned out they rarely play games. This explained their struggles, though they still figured out the puzzles with no trouble. Another major issue is the playtesters easily forgot the controls, despite the game only using four interaction keys besides moving and jumping. One of them didn’t even find out the controls through the tutorial, which was really hilarious. They finished the prototype without realizing how to change perspectives. I realized the dialogues from the flower may have been too subtle. Adding a UI for the controls seems really necessary.

This playtest gave us valuable insights and gave me a clear understanding of how important playtesting and player feedback is. There are many other problems that emerged and had all been noted down. I need to think about them and really come up with something that could make the game more fun and the puzzles more engaging.

[wheeledspy55]

Week 11:

Entropic Collapse: Assignment 3: Playtesting

We held our first play test on the Friday of Week 11, utilizing the e-sports arena. Our original roles for playtests placed Alex as the Playtest Communicator, however, due to extraneous circumstances , I ended up in the role of Playtest Communicator with Bowen and Lachlan taking notes. We decided - with the playtesters consent - to also record a voice note of the playtest as a means of keeping a record of any important verbal feedback that we may have missed at the time of play testing.

Overall, the play test feedback was extremely useful for the process of improving our game. It provided our team with great insight on how to make the game better by making it more engaging and fixing bugs or clunkly features that made it unpleasant to play.

This round of play testing specifically highlighted the importance of a tutorial page. We ended up adding a brief tutorial after the Playtest Script before the testers played the game. Otherwise, they were too frustrated with the game play and died to quickly to be able to properly explore the game play. This could have effected our ability to gain valuable play test data on the other aspects of the game that wouldn't have been reached without the impromptu tutorial.

Notes From Playtests:

Playtester 1 Notes:

Game rules and tutorials

How enemies working and attacking?

Health systerm

No rewards

Game design looks interesting

 Confused on what were enemies that would harm him and what wouldn’t harm him

Need to put a tutorial explaining game rules and what the goal of the game is 

Doesn’t feel like he is getting rewarded from playing 

Wants to see visual feedback or tangible feedback for collecting rubble or killing enemies

Playtester 2 Notes:

Likes title screen (colours dynamic effects)

Can see tiling on the background

Title screen asteroids can de-spawn

Unsure if they should use as

Wants to recover health

Variance in rubble shapes

Stop enemies from spawning on player

Asteroid feels like it might have too big of a hit-box for damage

Wants movement tech

Quick restart option

Increase difficulty of shielded enemy

Add movement to background

More variety of planets

More nuance to shields (speed can destroy them etc.)

Likes the background movement follows mouse action

Likes the colour selection and simple clean main menu

Likes the buttons highlight effect

Likes the lighting effect in the game

Enjoyable sound effect follow the in-game actions

Likes the black hole design

What should player aim for? (alive or destroy)

The main menu changed when failed a game

 Liked the subtle movement that follows the cursor in the main menu 

Tiling of the main screen image is off

Could be cool to incorporate the dynamic background into the on in gameplay

Simplistic design and the oranges with the starry background looks really nice

Credits doesn't work

The UI highlighting when hovering over intractable elements (Visual Feedback) is nice 

[isaachaworthgamesdesign]

Week 13b- Implementing Feedback and Iterative Design

Following the advice in Fullerton, we compiled the data gathered during the playtesting party and then got to work solving the issues that came up before continuing with the rest of development. The following was what was fixed up this week:

Fixing the Movement

This was something I couldn't figure out when I first start work on this assessment, but when I finally sat down with the goal to fix it, I realized how easy it was to fix. My biggest problem with the movement for a top-down character was the Acceleration and Deceleration settings as they were features I couldn't turn off in the behaviours box. What this meant was that the characters had a level of "Ice Physics" or "Floatiness" to them that I believed at the time was irremovable.

Turns out the solution was dead easy. All I had to do was speed up the acceleration and deceleration to a high enough speed that the player would reach max speed or stop to a standstill to what they would perceive as an instant. Before the acceleration/deceleration was a little above the player's max speed. Now the acceleration/deceleration is at a value of 10 000 units each. That solved the problem.

Solving the I-Frame Deathspiral

This was also a surprisingly easy problem to fix, when going through our code, a lot of the character's attacks and abilities had an extra requirement that they needed to not be invincible for the ability to trigger. As a result, we could just remove that requirement and lo and behold the characters played much better after the change.

Changing this effect did mean something though, which was that Peter's Shift needed to be touched up now.

Enhancing Peter

While not the biggest comment, I recall a player mentioning that Peter felt a little awkward to play so I decided to touch him up. For the most part, all I did was increase the size of his primary fire's bullets, allowing them to hit their mark better. I also gave an arc to his grenade and added a new property to his shift.

Whenever the player uses shift as Peter, they will now gain an additional benefit where if they use LMB or RMB while invincible from shift, they will end it early and fire additional shots of each from their gun. This was done to help with the I-Frames fix as the player would be able to shoot perfectly fine during Peter's Shift so we made it so it ended early but empowered the attack used to exit it.

[a5green]

A3 Playtesting Session 2

For the second playtesting session, we had a playtesting party. Between this session and the last we made a few more changes that we had planned such as custom music and more power ups so the feedback we received had some noticeable differences.

We found 2 more playtesters here to playtest Dragon Champions!

These playtesters I'll refer to as playtester 4 and 5.

It was observed that playtester 4 was playing the game over and over again, having a lot of fun even though they kept dying. They made a lot of comments such as "The dragons are really cute!" and "I really like the music!". In the game aspect ratings, they gave these aspects the highest scores, with enemies and story being the lowest.

Playtester 5 took their time trying out each dragon and their abilities, deciding which one they liked most. Throughout their session it was observed that at first they pointed out things they didn't like such as the feel of the hitboxes and the sound of the water attack. However, their thoughts changed on this the more they played the game and eventually they felt they liked these aspects of the game, the more they played.

They wanted to play the game a lot longer than most playtesters and set themselves a goal to reach 7000 points after they were told another player got to 6000. This shows that the leaderboard would be a good way to motivate players to compete against each other.

[idkbutheresmyname]

Assignment 3 Iteration and Changes

All the playtests have been concluded and I will now discuss some of the changes and Iterations that have occurred as well as info on playtesting, as most of the data will be put inside of my assignment 3.

Play tester 1

Didn't know what to do one since there were no instructions

Found 2 bugs which were high priority as they made him play against level 2 and 3 enemies on level one and that the player health was actually 3 instead of 10

Changes made because of the playtester

Added instructions to every screen on what the controls are and what to do (This was found very helpful by play tester 2 and 4).

Fixed bugs that broke the game

Play tester 2

Had to be told what the controls were despite them being on screen

Found Bugs that the hitboxes weren't registering, level 2 instructions were appearing on level one and every level completes at 150 score instead of increasing with each level

Changes made because of the play tester

The instructions to say "wasd on the keyboard" instead of just "wasd"

Fixed all 3 bugs as they all broke the game it ways that would be frustrating with further play testers

Play Tester 3

Found Bug that he could play level 3 without beating 2

Didnt know what each of the upgrades did

Changes made because of the play tester

Fixed the bug to prevent players from bypassing levels

Added descriptions to each of the upgrades, explaining what they did

Play tester 4

Did not like that everything reset after one game over

found level 2 way to hard

Found bug that the planet shield stays even after being used

Changes made because of the playtester

Fixed bug quickly by updating a broken line of code

Play tester 5 was done immediately after 4

Play tester 5

Also did not like game over screen

Also found level 2 way to hard

No bugs were found

Wanted an end screen that shows you were you get you gold/upgrade points from

Changes made because of the playtester

Nerfed level 2 as it was deemed to hard after changes made after playtest 3

Game over will be scraped and might be play tested with a 6th person

Thinking about adding end screen if there is a 6th play tester

Currently this is were the play testers end if more are done in the future this post will be updated to add there bugs and information and the changes made from them.

[layzlee]

Assignment 3 Playtesting

In this post, I will be taking about my assignment 3's playtesting with my group members and I. This is a follow up to the previous post. Currently, we have not conducted playtesting on people outside of the group.

How will we be playtesting

We will first be playtesting parts of our game, separately. Starting with the movement, then enemies, followed by enemy bosses and finally upgrades and powerups. We will slowly add on the prototypes that people outside of our group will playtest. We are doing this slow and incremental playtesting to make sure that we can pinpoint the specific part that they have discontent with. After these Unit Testing has been conducted, we will integrate all the parts segregated sections together and have them playtest the prototype again.

Planned Playtesting Timeline (starting from 1)

Each of these are their own separate versions of the prototype and every iteration of timeline adds on to the previous prototype.

Player movement: We will test the player movement with some basic static targets for the player to destroy - allowing them to have a feel of the movement and give us feedback on it.

Enemy behavior: We change the static targets with enemies with some AI; the enemy will be randomly chosen for each testing and quantity of enemies are fixed. A randomly chosen boss will be chosen as the enemy every three stages.

Upgrades (stat changes and survival powerups): After defeating all enemies from the previous prototype, they will enter a "shop" with stat changes and survival powerup upgrades. After choosing one, they will enter the stage again with randomly chosen enemies and quantity of enemies being fixed.

Upgrades (attack powerups): The prototype now consist of additional upgrades which adds another means of attacking other than the dashing.

Shop System: Putting all of it together with all the upgrades and powerups now available to purchase in a shop system that will be available after every stage.

Gameplay looping: Increasing the difficulty of the game after every three stages (after the boss level), adding more challenge to the game.

Full Game's Prototype Playtesting: Implementing all the necessary additions and changes to the game and testing it.

Closing Statement

We hope that after all this playtesting has been conducted and reviewed, we will be able to make a game that we are proud of and the players of our game would enjoy.

[wenqi-wang]

Assignment 3 Playtesting

Finally, it's time to get some feedback on our prototype. I was assigned to read the instructions for the playtest to make our testers comfortable with the entire experience.

We asked the testers some simple questions about the genre of games they play in their spare time to familiarise ourselves with our clients. Also, we kept track of their reactions when they got to our prototype, whether they were frustrated with the gameplay or found it boring to play with. We've had 5 testers so far, and most of them were stuck with the controls of the prototype as it struggled to adjust the angle aiming at the target. Some of them attempted to jump to reach the required height. However, they failed since there is no a particular mechanic of jumping. It turned out to be the lack of informative instructions for interactive keys, which was absolutely annoying when you have to figure it out yourself.

In conclusion, most of the testers ranked the visuals and audio the highest, and a few were a little frustrated with the controls and gameplay because they were slightly unclear and simple. We will be refining the prototype based on the feedback so far.

[maeveuniblog]

Assignment 3 Play testing

With assignment 3, I'm not undertaking the majority of the play testing, and wasn't able to attend the main play testing day, but I do have information that was gathered from those events.

The reports are as follows:

From these reports we can see a general lack of understanding in what the goal of the game is, as well as an issue with the level of difficulty. Though we can also see that most players love the design of the game. We can see some disparity between the controls, with some players enjoying them and some players disliking them.

With future development of the level up system, as well as possibly a more clear UI to indicate the overall goal of the game, which is simply to survive, similar to Vampire Survivors.

[jordan-glover--game-design]

Week 11:

Assignment 3 Playtesting:

For the playtesting we interviewed 5 different people ranging from serious gamers who play over 60 hours a week to inexperienced gamers who have barely played any video games at all. Throughout these interviews we did not give the person any instructions as to how to play the game and if they looked confused, excited, angry etc we asked them what they were thinking about the game at that moment. As we believed that would be the best way to get critiqued which ended up working really well combined with the instruction we gave them to think out loud always saying what they were thinking. For example, ��During the level select it allows me to continuously redo level one gaining all the gold I need to fully upgrade my abilities before I even reach level two”. Which was extremely helpful as we did not intend to add this mechanic, this led to the players giving several pieces of feedback each leading us to be able to further enhance our game. We then categorized our findings based on the answers that the player gave which were transcribed leading to this table being created.

Based on our findings we determined whether the priorities of the changes were high, medium or low which gave us a basis of what to try to change first about our game, then we determined what would be causing the problems and how to start to fix them.

[imslightlyproblematic]

Playtest 5 (assignment 3)

Pre-playtest questionnaire: Our final playtester identified themselves as a wide demographic tester because they ranked our game’s genre 2/5 and its cousin genres slightly higher. One of the cousin genres did make it into their list of 3 favourites.

The test: They decided to spend time experiementing with the game and found there was no boundary in the menu screen and proceeded to miss the toast message at the top of the screen upon starting the first level. Like previous testers they realised the goal of the game after failing the level so at least the death message is clear. They found that the difficulty curve was very steep from level to level and disliked that they lost their purchased upgrades after dying. They were the only one to correctly assume the gold earned was correlated with remaining health but only as a result of being probed for thoughtful comments. Even with their struggle to progress through subsequent levels, they opted not to replay earlier levels for gold because they simply didn’t want to and felt they shouldn’t have to.

Post-playtest survey: Once again aligning with previous survey data the game was ranked a 2/5 for learnability. The game was listed a 4/5 for difficulty and only 3/5 for enjoyment but part of the reason for these scores can be attributed to the fact that they were part of the wide demographic.

Conclusions: Adjustments to be made based on the results of this test are limited. Learnability is still a key area for improvement as well as balancing. However, some suggestions received in the interest of improving the game have significant potential to hurt it instead. They disliked the rule that the player loses all upgrades upon death and wanted to keep them. This may make subsequent runs easier but could be exploited to overpower the player and trivialise later levels. Smaller, permanent upgrades may be a possibility later in development as a form of meta-progression but for now it doesn’t effectively solve the issue of difficulty.

[givesonl]

Assignment 3 - Iteration and Changes

Based on the valuable feedback from our recent playtesting sessions, we have implemented several changes to improve the overall experience of our game. Here are some key updates and iterations we've made, reflecting the insights provided by our dedicated playtesters.

Key Changes Implemented:

Control Mechanics:

Dash and Jump Adjustments: We’ve reassigned the dash to a more intuitive key and smoothed out the transition between movements. This change addresses the awkward separation of movement keys and enhances the overall flow of the game.

Visual Enhancements:

Improved Obstacle Visibility: Several players noted that certain obstacles, particularly branches, were hard to see. We have updated the visual design of these elements to make them more distinguishable, ensuring players can navigate the game environment more effectively.

Game Flow and Difficulty:

Lives System Overhaul: The previous lives system was found to be excessively punishing. We’ve revised it to be less punitive, providing a more balanced and enjoyable experience. Checkpoints have been added to reduce frustration and maintain player engagement.

User Interface and Feedback:

UI Clarity: To address confusion regarding cooldowns and abilities, we have redesigned the UI to include better feedback mechanisms. New visual indicators for cooldowns and interactive objects make it easier for players to understand their status and available actions.

Narrative Integration:

Enhanced Storytelling: We’ve worked on embedding the narrative more seamlessly into the gameplay. This ensures that players are gradually immersed in the game world without overwhelming them with exposition, creating a more cohesive and engaging story experience.

Player Feedback Highlights:

Control Mechanics: “Reassigning the dash key made a huge difference. The game feels much smoother now!”

Obstacle Visibility: “The updated visuals make it so much easier to see and avoid obstacles. Great improvement!”

Lives System: “The new lives system is much fairer. Checkpoints really help in reducing frustration.”

What’s Next?

While we’ve made significant improvements, we are continuously looking for ways to enhance the game. Further iterations will focus on refining the level design, enhancing character animations, and incorporating more player feedback to ensure the best possible gaming experience.

[whysosiriusb]

Assessment 3 Playtesting

With our game now in a finalised state, it was time for it to undergo playtesting. We generated a build of the game which shall be used for all playtesting so that there aren't any discrepancies or differences in the game each player experiences.

We conducted playtesting with 8 total playtesters, only one of whom was familiar with the game while the remainder were unaware of any details regarding the game prior to playing it for the first time. Furthermore, four of these playtesters were among the core-demographic of our game, that being arcade score-chasers, and all players were experienced gamers.

After subjecting our game to playtesting, we received plenty of feedback regarding which systems were well-implemented as well as any areas which might need additional changes or updates to create a more enjoyable experience for the player. The majority of playtesters commented that the movement was rather awkward to control, often commenting that the Asteroid felt too slow to rotate. Furthermore, the UI design was often discussed as not being obvious enough, with players often unsure of what the health bar and ultimate bar actually meant during gameplay. Many players also did not understand the goal of the game on the first attempt, or did not understand what controls were needed to move the Asteroid, often resorting to using solely the dash ability for movement. Some players never achieved sufficient energy to activate the ultimate ability, and those who did commented that it did not feel powerful enough considering the cost and time to charge it. Two players also commented they felt unengaged with the game after a period of playing, adding that there is not enough variety and challenge over time.

Overall, this feedback was extremely valuable, as it has highlighted the areas which need to be improved if we want our game to be as enjoyable as possible. The most interesting part about this process was that many of the playtesters encountered problems that none of us developers noticed or struggled with, for example, the movement. This heralds back to the advice left by Tracy Fullerton in Chapter 1 of the textbook regarding the playcentric design process, and how the game isn't meant for the developer to enjoy, but the player.

Next up will be a post about the post-mortem of Assessment 3 and some of the iteration and changes we have made as a result of our playtesting feedback.

Until next time!

Fullerton, T. (2018). Game design workshop : A playcentric approach to creating innovative games, fourth edition. CRC Press LLC.

[isaachaworthgamesdesign]

Week 13a- Playtesting Party Results

With the playtesting party today, I went to Uni along with Nishant and Mahzar to gather valuable playtesting data that we can then iterate on as described by Fullerton in Games Workshop. A total of seven testers were found for the game, with varying levels of skill between them.

The following is some of the feedback

General Feedback

Movement/dodging is weird- It was described by the playtesters as the momentum feeling off, dodgin from a standstill being hard, jank and to have a "bit of sway". Despite all of this, one tester did describe the movement as good (tester 7)

Get a HP bar for the boss- at the time, only the soul grinder was there as a boss and we hadn't gotten around to giving it a health bar. This feedback was reinforcement on that fact

Disapproval from being unable to attack during I-Frames (invincibility frames): At this point in development, the player could not attack after taking damage and can only attack if they currently weren't in I-Frames. This lead to several playtesters going into a death spiral where they would get hit once, then break out of I-frames only to be immediately hit again, being unable to fight back in the process.

Peter felt a little weird: only one of the testers noted this, but I took note regarding it as he should feel the best to play considering the intent behind his design.

Miscellaneous Comments

This section is just a collection of comments and reactions that were gotten during the playtesting process that I found amusing. Most of these are in reaction to the boss and were the kinds of reactions that I enjoy to hear:

"Just trying to survive" "Ah!" "Oh my days..." "Dude there's a boss!" "Oh my F****** god!" "I am so bad at this" "Oh god I'm gonna die..."