JSigh

Jordan Sy n9971386

[jsigh]

Space Recruitment Postmortem

A future feature that could be implemented into Space Recruitment that was mentioned by a few of the play testers are cosmetics, things such as ships skins along with changing backgrounds after each session. Other great features that could be implemented could be things such as a scoreboard showing the previous in an ascending order and even a highest score meter or something along the lines of that while in game, so the players know their last highest score. And if this was to be released in the future this could also be further expanded to encompass a global leader board as this would help spice things up and to further motivate the player as the objective of Space Recruitment is to try score the highest possible score.

I enjoyed collaborating and working with Jhana as this was an exciting experience for us, because we have always considered trying to make a game together but never made the proper commitment due to personal reasons.

I cannot confirm or deny whether I am satisfied with the overall results of this project as we have learnt and picked up a lot of things along the way, however, I can confidently say I had fun going through the fundamentals of game design. I'm glad that we were fortunate with the chance of interacting with our testers and I’m very appreciative to our testers for lending us their time out of the day to sit down for a 20 minute play test session. Their feedback was critical for us to be able to find the flaws in our game. But, overall I found this project very fulfilling, found it very interesting working in an iterative cycle.

[jsigh]

Space Recruitment Readings Discussion

In Chapter 12: Team Structures from Tracy Fullerton’s Game Design workshop discussed that “understanding your role in a team and having the interpersonal skills to work within a team structure are as important as any of the design skills” that Fullerton has mentioned throughout her book. I believe both Jhana and I know each others skills and capabilities from prior assessments and throughout working together during this unit. Fullerton also recommended to take time to practice team-building and communicate properly with team members. Although Jhana is the lead Game Designer for this project, we generally both brainstorm together and end on the same wavelength of thoughts, which results in what I’d interpret as having good synergy. Due to the fact that we decided to work together as a two member team, all the work and processes are split appropriately.

[jsigh]

Space Recruitment Playtesting

We tested the game with five naïve users, who continued to do a deep playtest. All the users that were chosen, were from our wide demographic in that they enjoyed real-time strategy games, first person shooters and variety of other genres. Two of the users can be considered to be a part of our core demographic, who enjoy the arcade shooter genre, while the rest did not hate or enjoy the genre. All the users that play tested this game primary used mouse and keyboard normally when it came to the main games, thus all users have had extensive experience with the use of mouse and keyboard.

Fortunately, due to majority of the user being experienced with shooters, they were able to enjoy the arcade shooter game to a certain degree and provide feedback accurately addressing the issue the game had. The users who liked role-playing and action-adventure games suggested interesting potential features to be added into the game.

Throughout the play test we were able to gather very valuable feedback and after compiling all of it.  It honestly opened our eyes to so many features and elements of the game that even experienced players within the genre of arcade shooters still found some features frustrating and hard to distinguish without an ample walkthrough.  

Although the prototype we had the play testers use for feedback wasn’t very refined, we still were able to get some very valuable feedback which we will be able to use to further improve the gameplay loop in future iterations of the game Space Recruitment.

A few crucial aspects highlighted by almost of the players that we play tested was the need to change how the asteroids spawned and along with the teleporting mechanic from when the player hits the edge boundary of the map, they will get teleported to the other side of the map. These two criticisms were echo by almost all the play testers and will be the most important thing to address in the following versions of the game as players found these two mechanics to be the most frustrating elements of the game. This was further amplified due to there being no marking or border being shown at the edge of the map leading disorientating teleports.

Most of the players suggested that changes to the assets will be necessary to address issues such as differentiating between different asteroid types depicting if they should be destroyed for scoring points or interacted with to gain benefits such as more ships and lives. Besides assets changes, there are major problems due to the lack of instructions being provided to the player. The win condition of the game is not clearly defined, the usage and penalty of the asteroids with stranded ships. Players were also having issues of the notification that lives were being lost due to the usage of text and the constant clutter of many asteroids the user had to deal with.

There were some issues regarding the balance of the different weapon type pickups, where the full auto fast firing weapon would be considered over powered and break the game balance in comparison to using the inferior shotgun or spread shot powerup that was reviewed as being either too slow or seen as a negative to due to the causality that could be caused to the stranded ships to be rescued.  

Increasing difficulty and progression mechanics were also echoed by some of the play testers as an infinite scoring session without motivating features did not encourage much variety to the playthroughs conducted.

Finally, there are some minor issues regarding some of the designs of the game. The hitboxes of the asteroids were not configured properly and should be solved easily with minimal effort and the design concept for the player interaction with the asteroids containing recruitable stranded ships, needed to be reworked. Players often found themselves unintentionally destroying the asteroid with the ship due to the momentum of shooting while turning to move towards recruiting the ship.

Positively, the responses to the difficulty of the game resulted in what was we had expected and set during the initial design process. Additionally, it is fortunate that all the playtesters had fun.

https://docs.google.com/forms/d/e/1FAIpQLSdTUOYBljPNf284QiXFniKvDNjCAHfN7Nbbf0AGgGJ07WXlIA/viewform?usp=sf_link

Prototype: https://games.gdevelop-app.com/game-caa44c83-d404-463a-915a-645745b5e2cb/index.html

[jsigh]

Space Recruitment

I am partnering with JKhor GameDesign to iterate on his second game ‘Space Recruitment’, which is a Space Arcade asteroids Shooter. Initially we discussed that we could incorporate the shapeshifting ship from my ‘Pologons VS Circles’ feature, however, due to discussions of balance we refrained from proceeding with the integration due to balance and lack of challenge for the game. 

Both of us have been in a couple of groups together for past unit courses and we believe we dynamically have good communication and work well together. We wish to use our skillset and similar mindset to make Space Recruitment a satisfying and functional game.

Currently we are planning to clean up certain mechanics and bring the game up to a more playable state than where it was left off. We have plans to change into more aesthetical assets as well as implementation of sound effects, however, the smoothness of the game mechanics need to be addressed first.

I believe we will need a playtesting session to figure out the roadmap for the development and changes needed for this game. I am looking forward to see what we can achieve.

Reading Reflection

In Chapter 11: Fun and Accessibility of Tracy Fullerton’s Game Design Workshop, the fun aspect of a game can be ruined by stagnation where “nothing new seems to be happening for a long period of time and choices stay the same level of importance and impact”. For our concept and design of the game, there is a high possibility that stagnation can occur due to the current build not having any forms or indications of progression since it is only an infinite scoring session with the only goal for getting the highest score. This issue will most likely need to be addressed during the iterations and changes, but will definitely be an expected response during playtesting.

JKhor GameDesign @ https://jkhor-gamedesign-blog.tumblr.com/

[jsigh]

Assessment 2 Final Design

One-Page-Design

Sell-Sheet

I am not sure if I am satisfied with the end result for the one-page-design and sell-sheet, however, I cannot help but consider regretting the choice of asteroids game because it seemed like there wasn’t enough features to the game and it seemed incomplete. I believe the style of the one-page and sell-sheet are not the best due to the assets chosen but I hate to admit it that this is not my best work.

[jsigh]

Racing Postmortem

Overall I am satisfied with the development process for this game. I enjoyed exploring the balance of the 3 unique models and how they performed in each playthrough. I felt that there was more interaction and iteration with the playtesting after learning about the fundamentals from each of the Fullerton readings read from all 3 games developed. Although I have the tendency of leaving my developed games in an incomplete state, I’ve come to realise that I am trying to enjoy the development process for creating games instead. 

I think I have achieved a portion of my goal, which was meant to turn a current relative recognisable Dyson brand into a satirical racing game while also having logical features. In regards to the way the game has been developed, I have also considered if it might have been better to change the style of the top-down racer to a horizontal side scroller as the models on a side scroller may have more definitive features compared to the aesthetics from a top-down view. 

Some concerns that are still on my mind include; handling balance for potential additional playable models and whether the mechanics and goal of the game is enough to justify for a complete game. Another thought I considered was if the game should have a multiplayer or races against AI playable models, however, I did not consider the scope with the timeframe given.

[jsigh]

Racing Game Required Readings

In Tracy Fullerton’s The Game Design Workshop, Chapter 10 of Functionality, Completeness, and Balance, breaks down the results from playtesting into phases. The feedback can give a rough indication of the game’s completion state, specifically, the game must be considered functional before the game can be considered ‘complete’. It is important to balance the game, by adjusting mechanics and concepts when setting a goal for the player to meet. Once the game becomes functional and balanced the game is then ready to be refined before it is officially completed.

The main concern for the racing game is the balance between each of the playable models. The current 3 models can be categorized as:

Cyclone - Technical/Utility-based

Outsize - Tanky/Durable

Omniglide - Speed

Since each model has its own uniqueness, each model has its own variables that need to be considered for balancing the playthrough experience and to ensure that there isn’t one best model which objectively breaks the game. Initially, I intended for the difficulty of each model to scale up to test the player’s skill. Supposedly the Omniglide or the Speed model was meant to be the most challenging as it is a high-risk and fast-paced model which aims for the fastest completion time.

I believe the concept of the model to player skill difficulty is a good element, but the concern to how each model functions or performs is the test for balance. I hope to refine any potential loopholes or unintended experiences when the time comes.

[jsigh]

Racing Playtesting Report

In this week’s playtesting, I was excited to receive 3 playtesters to evaluate my racing game. I am thankful for the feedback that was received from playing the game.

The readings regarding the balance of the game intrigued me as, during the development of the racing game, I was very unsure of the direction of how to balance the 3 playable models during each playthrough. The game received a mix of both positive and negative feedback.

Some issues and bugs that the playtesters noticed were:

The clarity of the objective of the game. The game lacked prompted goals or objectives

Players only understood the game objectives after playing a couple times

Clarity of the game mechanics

Some buggy controls with certain models

Text on the screen was blurry

The feedback noted from each playtester had interesting ideas and solutions for some of the issues and bugs that were apparent in the prototype. Some of these include:

Improve the mobility of all models

Introduce more interactable objects

A shield power-up which prevents lives from being lost

The balance between each playable model vehicle needs to be reworked

It was speculated that the blurry text was due to the resolution the game was exported at

Some positive notes received from the feedback, that I am passionate about include:

The OmniGlide model was a good addition

The mechanics of the dust clouds and obstacles to avoid

Simple menu UI

Clarity of the game after playing a few times (this will be changed so that the clarity is recognized upon starting the game)

Small concerns regarding the placement/styling of the text can be fixed at a later date for better refinement. This happened due to limited time for development.

[jsigh]

Assignment 2 Progress

There have been some notable changes to #game 2 Polygons VS Circles, such as a space background added, and the asteroids have been changed to Circular shapes to fit the game title. A specific layered asteroid shown in the screenshot is intended to be a unique asteroid which homes in and follows the player for collision. Currently it has not been added as I am having difficulties with time to implement this.

Current progress of the One-Page Design

I don’t think I have creative/artistic choices towards the presentation of the information of the game, however I wish to be transparent with features of the game.

[jsigh]

Racing Game Development Cont’d

Using the racing game we created from the workshop, there were some asset changes made to fit the theme of the game, where the oncoming cars are replaced with dust clouds for the player to ‘vacuum’ them up to score points.

Some additional changes have been made from a small playtesting session. A bit of difficulty or challenges added was another group of objects to act as obstacles (Spikes, RoadBloack, Barrel1, Barrel2) while the player is actively vacuuming the clouds of dust for points. 

Additionally, an intended function of an on-screen timer was added to motivate the player to achieve a good time trial time for better scores.

The player passes with a time record under 10 seconds

The player passes with a time record over 10 seconds

End screen when the Player crashes

At the end screen, the player can see the bonus score they receive from attaining a better time record. 

Small Readings Note

In Tracy Fullerton’s The Game Design Workshop, Chapter 10 of Functionality, Completeness, and Balance, I am expecting to find possible loopholes regarding the way the game will be played during playtesting. I am also looking forward to hearing opinions on the way the game can be more balanced as I am unsure on whether the 3 models can be considered to be fair in terms of uniqueness.

In this weeks workshop, we incorporated proper conducts of testing prototypes following the some of the teachings in Chapter 9: Playtesting. It presented the procedure for testing prototypes in a more professional manner, where game designers always need to consider the target audiences they conduct tests on and the ensure they are receiving the feedback they need. Conducting a Playtesting Session has a procedure that contains multiple steps to ensure the user can actively provide constructive feedback instead of receiving what could’ve been a short response. After the session the developers proceed with data analysis and compilations of notes to later refer to for refinement.

[jsigh]

Dyson Master Race Development

In comparison to the previous games, a simple UI for the home menu and controls have been added with room for improvement at a later date.

Menu

Controls

Vehicle Type Selection

In the vehicle ‘Model Selection’, players currently have 3 models or types to select from, with the possibility for more models to be added in the future.

When hovering over a model, information regarding the model’s features will be displayed for the player to understand its uniqueness. Currently, the features of the 3 models are:

Cyclone

Pressing ‘Space bar’ will activate a detection laser which imitates the Dyson Vacuum to use a laser to reveal microscopic dust. Doing this will allow players to double the points they receive from vacuuming dust.

Outsize

The Outsize model is an attempt to represent the Dyson Outsize Vacuum to be larger, however, for game functionality, the current features of this model can take more damage from the obstacles in the game compared to the other 2 models.

OmniGlide

The depiction of the OmniGlide from the Dyson OmniGlide Vacuum is that this model is supposed to have smooth vacuuming capabilities. In addition, this model will have the fastest speed compared to the other 2 models, however, the risk is whether the driver can handle the speed.

Racing Game Prototype: https://games.gdevelop-app.com/game-edebd1ec-a7d5-4764-9446-6f6a8a843f15/index.html

[jsigh]

Racing Game Elevator Pitch

Name: Dyson Master Race

Dyson Master Race is a top-down racing game set in the future. It is 2042 now and the renowned vacuuming brand Dyson has established its own exclusive competitive vacuum racing sport. The player is a representative test driver of one of the many vacuuming models by Dyson that has been built as a vacuum car. Participate in the simulations given by examiners and achieve top scores for your Dyson model department.

Genre: Racing

Mechanics:

The player chooses a car type to race in, where each car has its own advantages to finish the race. On the track, there are obstacles the player could either collide into to increase score and hazards to avoid.

Setting:

This racing game is envisioned to be in the future with the goal of achieving a high score.

Demographics:

The target audience is people who enjoy arcade games by challenging themselves for a high score. The age group is 7+.

[jsigh]

Asteroids Postmortem

It is quite unfortunate that I will be halting the development of the Asteroids game I have been developing. I can only conclude that likewise to the reasoning for the platformer game, I do not believe I have enough time to consistently make progress while committing time to other activities. I can proudly say I have enjoyed the development process I went through this time compared to the platform. The main reason is that implementing the asteroid’s design was easier due to following a design procedure and utilizing my reflection of focusing on the intended game mechanics first.

My other posts talking about the readings from Tracy Fullerton’s The Game Design Workshop helped me establish a structural procedure to manage my time better for designing games. Although I have not implemented any changes to Polygons VS Circles, I believe if I have spare time, I will go back to add in some of the features mentioned during the playtesting feedback. I thoroughly enjoyed the playtesting session for the asteroid game, since the asteroids prototype developed gave me satisfaction and the feedback interactions helped structure a plan for the refinement process.

I am overwhelmingly satisfied with the design process for the asteroid prototype and will be excited to finish the prototype once I can allocate appropriate times to work on it.

[jsigh]

Readings for Asteroids

Upon looking into Chapter 6: Conceptualization of Tracy Fullerton’s The Game Design Workshop, it is concluded that “most beginning game designers simply borrow elements from successful games and adapt them to their own purposes”. I believe that as a beginner game designer myself, I will be heavily structuring my game as Fullerton said. Additionally, I don’t find myself being very creative for major or mind-blowing concepts and much prefer to work on certain existing features that can be adapted and changed to create another unique style of playing. Polygons VS Circles is the prime example as I only wished to have the power-up as the core unique feature that was different from the already existing asteroids game concept.

Negative thoughts aside, I am learning to use Fullerton’s method of Turning Ideas into a Game, which mentions Focusing on the Formal Elements when creating a game, which helps me as a guideline for times that I am stuck during the design process. Specifically, it was mentioned to flesh out the game structure, consider the following:

Define the player’s goal(s)

Only focus on the most critical rules

Map out how a typical turn or core loop works.

I have noticed that there is a core loop regarding the asteroids game having an infinite scoring goal, however, I believe over time it will be necessary to develop more critical rules to clarify the game’s win condition. 

[jsigh]

Asteroids Playtesting Feedback

In this week's workshop for playtesting, I was fortunate to get 3 playtesters to evaluate my asteroids game. I am thankful for the positive feedback that was received from playing the game. 

I used one of the Techniques for Balancing Your Game, from Chapter 10 in The Game Design Workshop by Tracy Fullerton to graph the data of the playtesting feedback. The readings regarding the balance of the game intrigued me as, during the development of the asteroids game, I didn’t plan ahead of time how the powerup should be balanced and as a result, all playtesters commented that the game should be more challenging.

Some issues and bugs that the playtesters noticed were:

The loss of lives when the ship collides into an asteroid can be buggy, there was a moment where colliding into the asteroid did not deduct any lives whereas others could

There was some confusion regarding the thickly outlined asteroids, which are the asteroids with shield layers

The feedback noted from each playtester had interesting ideas and solutions for some of the issues and bugs that were apparent in the prototype. Some of these include:

Changing the asteroid to spawn on the sides instead of being randomly on the screen

Add an asteroid that follows the player instead of drifting on a set path

A shield power-up which prevents lives from being lost

Common solutions for refinement from the feedback included:

Adding animations for being hit and destroying asteroids

An explanation of the controls, possibly on a new scene

Change the sprites and background to be less generic

An important part of the feedback was specifically the handling of the controls on a laptop since holding down RMB was the form of movement. In the future, the game developed should be optimized to have functional controls for any device.

[jsigh]

Polygons VS Circles Development Cont’d

While designing and developing the game, I realized that the events for the mechanics created in GDevelop are possibly excessively redundant, as the screenshot above is one example where a better understanding of nesting conditions in GDevelop could have resulted in more cleaner code. However, doing this within a limited time has allowed me to obtain my goal of achieving the feat of showing the intentions of the game.

[jsigh]

Polygons VS Circles Development

In this weeks workshop, after creating a basic asteroids game I focused on achieving the implementation of the intended mechanics for the game.

I can proudly say that I have successfully portrayed the core mechanic of the game which is when the player picks up the power-up, it morphs the default ship to another polygon shape and has its own unique shooting feature. I also tried implementing a second layer to the asteroids as another mechanic (indicated by the thicker white outlines of the asteroid), which requires the player to shoot the asteroid twice before destroying it.

I have run into an issue where the movement of the ship flips constantly or spazzes out, as the conditions and actions of the ship movement are a bit flawed without appropriate handling.

Asteroids Prototype: https://games.gdevelop-app.com/game-539cea1f-f540-4a5e-a5c6-8304c8c5a9fd/index.html