IGB220 Alexander Garner

Having the chance to develop a small game in a group for the first time was a very interesting experience! through this i have gained a multitude of valuable skills across many different fields, that being communication, programming, designing ect.

The main highlight would be the playtesting journey. This has been my first time doing extensive playtesting with naive users to gain feedback and results on a prototype that i have contributed to the development of. I took this as an opportunity to learn how to properly playtest and gain effective feedback to improve my own ideas and prototypes. This experience was most definitely assisted with the information i have gained from Chapter 9 Playtesting, from Fullertons (2018) Game design Workshop. I have mentioned this previously in a post, however i believe it is critical to mention again as this has benefited my own development regarding playtesting and reflecting. With all my naive users i followed the following rules previosuly mentioned in one of my posts, as well as in Chapter 9 Playtesting (Fullerton, 2018).

- Playtest before You Think You Are Ready - Strategize for Early Playtesting - Know Why You Are Playtesting - Prepare Variations - Be Grateful to Your Playtesters - Design the Learning Experience - Know Your Testers - Don’t Explain - Take Notes

As we had extensive amount of playtesters, and playtest results to review, being able to effectively collect data has been a valuable skill i have learned. Reflecting on my individual data collection process ,as well as our groups, i have come to realise the significant role that metrics play in shaping development of a game. One key lesson that i have learned, particularly from reading through how Fullerton (2018) discusses collecting data in Chapter 9. In particular, setting clear objectives before collecting data. Especially, our game had a lot of room for improvement and areas in which we need to collect feedback for, having set objectives helped structure our data collection with purpose, assisting in avoiding aimless data accumulation and ensured all feedback we had gained was beneficial to improving some aspect of our game.

This goes hand in hand with the discussion in Chapter 13 of Setting up goals, creating schedules, and assigning roles when collaborating in developing games (Fullerton, 2018). Having clear set goals for each week, with set tasks for each member to complete, while following deadlines, helped in assisting all areas of our games development were completed effectively and on time.

This also allowed for our team to be able to see areas in which we may be falling behind or struggling in, in particular, if a member had fallen behind, we can all collaborate and complete it as a team.

Finally, balancing became a very important topic regarding our game. As a group we had made a mutltiude of protoype, removing and adding in new features, mechanics and creating new rules. After reading through chapter 10 (Fullerton, 2018), i gained the understanding on the guidelines with ensuring our game offers not only engaging gameplay, but also playability and a balanced player experience. This could mostly be seen through the changes in our enemies, and the inclusion of new enemies due to constructive feedback from playtesters.

-Addition to sea snakes as a new enemy (due to players reporting that our regular mode became too easy to survive in) -Immediately after reduced the amount of snakes that spawn from 5 to 3, as well as their hitbox -Removed whirlpools due to visual clutter -Bullets continuing through targets even when coming into contact with them - cause bubbles to pop off screen, leading to random sharks flying in from the corner of the screens -Projectile speed -Spawn rate of enemies

These are just a few key changes that we had made, these were all discovered and change due to player feedback.

If we were to continue working on this game in the future, we all collectively have had some ideas for future iterations which are the following:

-introduction of additional collectibles, in-game currency, and achievements. -Achievements - collectible trophies that may spawn in bubbles for players to collect during gameplay. -New modes - Endless mode which allows for competitive players to test their skills without a timer - Challenge mode which implements specific objectives and/or restrictions, testing the players creativity and critical thinking skills -Player feedback loop - allows for players to provide feedback, new ideas, or report bugs and issues to us developers - Storyline - goes into the detail of how and why the player must save all these ducks (potentially include lore?) -Boss Battles - include new enemies that could be used as a boss: Whales, Kraken, (maybe even a mutant combined shark/octopus?)

After doing some informal play-testings our group received a lot of feedback and we made changes accordingly.

New enemy:

From informal play-tests, we received feedback that gameplay before the In Hot Water mode became too repetitive, this feedback was both given from experienced video game players, and non video game players. From this feedback our group had discussions regarding implementing a new feature of enemy to add an element of unpredictability, as this is a core aspect of player experience and maintaining player interest over time (Fullerton, 2018).

We decided with adding in "Sea snakes" which will come in a wave of three snakes which will path from the left side of the screen to the right in timed intervals. Coming into contact with these snakes will cause the players to lose a heart point.

This clip has been taken from our Tutorial mode, which explains all of our gameplay mechanics and features.

We have already done some play-tests with just our group members regarding the snakes as originally we had decided on having 5 snakes path through the screen. This quickly was changed as the player had no chance of dodging any of the snakes due to the hitbox of the boat being too large, and the gap between each snake being too small.

Therefore that is how we decided on having only 3.

Future iterations (feedback from formal play-tests for final report):

Players reported that it became too difficult to dodge the snakes as there was never any visual warning of their appearance. So whenever the player was positioned against the left side of the screen, they had no time to react and would lose a heart.

Informal playtest findings

Observations, data, and other findings from informal playtesting in week 11

note: this is the direct feedback written in our week 11 play test document

Low fidelity prototype group feedback: 

Notes on rubber hero Ducky 

When moving quickly and coming into direct contact of bubbles and shooting it can quickly eliminate the bubbles and collect ducks to quickly 

should bullets disappear after coming into contact with a bubble? Only being able to shoot one at a time 

player movement bit too quick 

Should sharks follow players for longer once released?

Should sharks have a one second stun period before moving when shot out of a bubble? 

Sharks that come off screen move a bit too quickly, should there be a warning on the side of the screen notifying the player that a shark is coming in a certain direction. (Was discovered that bullets do not disappear once coming into contact with an object, they were then coming into contact with sharks off the screen) 

should “in hot water” have a shorter timer? 3 minutes seems like a short time in theory, however when playing it feels very long and the gameplay itself can feel a bit static. 

maybe we should include “waves of sharks” where a notification on a certain side of the screen will pop up, a group of sharks will come from one direction to the other and dodge them all. (They do not follow the player) 

In hot water mode the timer is too long, could it lead to the player remaining idle for too long? Or may not even reach it at all. - Once “In hot water” does activate, too many sharks swarm the player and are too difficult to avoid. 

Should have a short cooldown on taking damage (possibly 1 second). Found that the player dies too quickly during “In hot water”. 

Low Fidelity prototype feedback from tutor:

Pictures on start screen with info

“what does octopi do”

Was unsure about shooting sharks? 

What does the pink duck do? (Does Not have any interaction as of now) 

Cannot collect ducks during “In hot water” 

Too easy to not hit sharks (is there any way 

Have a feature where bubbles have timers? After a certain time the bubbles pop. 

Need more urgency in normal mode, more challenge? (more sharks and octopi?) 

No situation where the player will shoot when in any direction of sharks or octopi, can easily avoid releasing them. No sense of real challenge 

Make bubbles similar to a time bomb? For both octopi and sharks 

deciding to introduce a new enemy instead that isn’t dependent on the bubbles

this challenges the player in regular mode without compromising the challenge presented in IHW mode–we don’t want to make the bubbles pop without the player’s actions because that’s the point of IHW mode when all the bubbles pop anyway.

Keep ducks spawning in bubbles during IHW mode 

When reaching checkmarks of RP- the duration of IHW increases - test the increments of time with each checkpoint (Further you reach during the game, the more challenging both IHW and normal mode becomes/lasts longer.) 

Have the position of the boat remain horizontal, have the boat slightly tilt when moving/aiming?

Introduce a particle effect when coming into contact with sharks/being damaged 

Timer needs to be fixed 

(Timers can make the game less enjoyable - players can go at their own pace) 

IHW mode, make it longer as the points that you’ve collected gets higher 

Threshold balance and regulating challenge So if the player has collected 0-10 points within regular mode, make IHW last for 10 seconds If the player has collected 10-50 points make it last for 20 seconds, etc.

Future iterations to prioritise: 

Put something in the background to make it seem like the player is in water 

Include new enemy - sea snakes that come in waves for the player to dodge, there can be a notification on the side of screen where they spawn - move directly to the opposite side of the screen (Could potentially pop bubbles) - solution to adding urgency and challenge to regular mode without compromising the bubbles, a non-bubble-dependent enemy.

Visual indication that the player has taken damage (Boat goes red, splash effect on boat, small “-1” above the boat ect.) 

-cooldown for the nets OR limit the nets

Play testing materials + results from final play test with naive users

Survey:

Questionnaire:

After reviewing each of our group members A2 designs, we collectively agreed on the fact we wanted our game to be similar to an asteroids game. This was an easy decision as we all chose to pursue our asteroid pitches and designs from the previous weeks in our class.

We wanted our game to have unique features and implementations that looked visually appealing and that could entertain our players. We decided on Lily's "Rubber Ducky Hero" as the best fit for this.

Following this we had created multiple google docs and a trello page to help track all of our progress and any ideas/changes/feedback we wanted to include and keep documented.

Has been colour coded to keep track of individual tasks easily.

We have been staying in contact mainly through discord, this is where we share our thoughts, ideas, and any possible changes we want to incorporate to our final game design

As seen above we have dedicated channels to specific topics/tasks.

Group Members:

Alexander Garner

Annmarie Gomez

Cody Barnett

Lily Wang

Prototype Information

Team 1 has decided to develop Lily’s game, Rubber Duckie Hero.

Game Elevator Pitch

Rubber Duckie Hero

Plunge yourself into the bathtub and prove yourself to be a real "Rubber Duckie Hero". Take control of your boat as you navigate treacherous waters to rescue rubber duckies trapped in bubbles. Be careful! Vicious sharks and crafty octopi are here to disturb your mission - don't worry as you have nets at your disposal to assist you in your journey. However you must brace yourself, as the temperature of the water rises, prepare for a scorching challenge during "In Hot Water" mode.

Gameplay

-Bubbles contain ducks, sharks, and octopi

-Shoot at the bubbles the rubber duckies and trapped in to free them

-Shooting bubbles containing sharks/octopi will create more enemies to avoid

-Ducks will disappear after x seconds

-Come into direct contact with ducks to collect RP

-RP claimed after victory can be used as currency to buy new ships/cosmetics

Enemies

-Sharks: Deal 1 damage, disappear after attacked

-Octopi: Steal freed ducks that haven't been obtained - low spawn frequency

Nets

-act as a projectile which can be launched behind and infront of player - Active for 3 seconds

-Defeat sharks and octopi

-Max 3 nets held at once

Health

-Begin with max health-5

-Dropping to 0 health = lose

-Collect hearts to gain health

In Hot Water!

-Countdown to IHW displayed

-Map will turn red and all existing sharks/octopi in bubbles will be unleashed

Player movement speed buffed during this duration

-Lasts for 30 seconds once IHW begins

Controls:

-Movement: WASD

-Shoot: Space bar

-Front Net: Up arrow key

Progress:

After forming the final group for assignment 3, we decided on the final game to be "Rubber hero Ducky", a quirky spin on an asteroids/shooter.

For the roles our team were very versatile in terms of skills and hopes for certain roles. However as none of our members were very experienced in programming, we decided to keep each given role as a loose idea of who does what. Therefore i was given the roles of designer and writer.

So far we have the fundamentals of the game that was listed on the A2 game sheet completed. As of now we have decided to remove/not include temporarily some features such as the "whirlpools" which was originally designed to stun the player as we found this caused the screen to look very messy.

We have all elements of the game as originally intended included, we have some iterations we would like to include and more playtesting to be done.

issues:

We have ran into some bugs after doing some playtests.

-Bullets not disappearing after coming into contact with bubbles, allowing for them to keep moving off the screen, then coming into sharks off the screen. This causes them to fly to the player from off the screen, not allowing them enough time to dodge.

Design and Development

The design phase was an engaging experience, encompassing the creation of car models, race tracks, and power-up mechanisms. The accessibility of GDevelop's event-driven system enabled the realization of creative visions, even for those not well-versed in coding.

Throughout the development process, various significant challenges emerged. Addressing collision detection intricacies and fine-tuning the physics governing the racing cars demanded substantial effort. Debugging was occasionally a source of frustration, yet the sense of accomplishment derived from resolving these issues was profoundly rewarding.

Testing and Feedback

Testing the game was an enlightening and humbling experience.

I wanted to have someone play test my game that i developed for the first time, and i encountered many issues mostly with the programming.

After play testing the past two prototypes with different methods of play testing: My platformer i had very little knowledge on the method of play testing and simply had someone i knew play my finished prototype with no prepared questions, or tasks for the player to perform.

Regarding my asteroid game, i followed along with the play test sheets provided and gained insightful feedback.

However after thoroughly reading through chapter 9 Play testing, Fullerton (2018) discusses the "rules" of play testing which i found very helpful with gaining feedback from my current prototype.

These are the rules mentioned that stand out the most (i will not include all as this post will become too long)

- Playtest before You Think You Are Ready - Strategize for Early Playtesting - Know Why You Are Playtesting - Prepare Variations - Be Grateful to Your Playtesters - Design the Learning Experience - Know Your Testers - Don’t Explain - Take Notes

Having these insights into playtesting made the experience run a lot smoother and allowed me to gain better feedback and provide a better experience for my playtesters.

When organising playtests with my friends, i chose to provide no information regarding my game before the tested. I chose a variety of gamers and people who had little to no experience whith gaming to gain a proper understanding on how easy the game is, and how easy the mechanics are for new players to pick up.

I ran two playtests, the first being my prototype in its more bare form, with little design and aesthetics, just core mechanics or the racing games. This was to see if my program ran smoothly so i can move forward with adding in new features.

After i gained insights regarding the first version of my racing game, i tried to pursue adding in all the features i have mentioned previously. This is what i struggled the most with, I was very ambitious with my ideas, however bringing them to life was a challenge. Firstly adding in small bonuses such as mini speed boosts was not not too challenging, more so adding in the Frenzy mode.

Reflections:

Reflecting on this journey, the oscillation between moments of elation and challenges becomes evident. I had no idea on programming racing games and underestimated the difficulty. Nevertheless, there were instances of doubt, where concerns regarding project completion or game reception arose.

It is pivotal to recognise that setbacks are an intrinsic facet of the development process. They are not insurmountable obstacles but rather stepping stones toward success. Each hurdle surmounted, whether it be debugging a flaw or reevaluating a design choice, contributed to the game's overall improvement. Persistence is a key attribute in this domain.

Creating a 2D racing game within GDevelop presented a formidable yet profoundly gratifying challenge. It scrutinized problem-solving abilities, harnessed creativity, and underscored the significance of unwavering determination. The feeling of accomplishment upon project completion is profound. It is a testament to having added a distinct creation to the tapestry of the gaming world.

Additional Notes:

In another previous post i talked about how Fullerton puts an emphasise how predictability can influence player engagement and satisfaction. Balancing predictability and unpredictability is crucial for maintaining player interest over time (Fullerton, 2018). I decided to implement this "gear shift" mechanic as in the context of a racing game, the addition of a feature that requires players to remain alert and prepared can significantly improve the player experience. By introducing dynamic obstacles, such as these gear changes that has consequences if not completed, has players kept on their toes, adding an element of unpredictability that makes races more engaging and challenging. Variable track conditions, like a wet track affecting vehicle handling, force players to adapt and adjust their strategy on the fly, adding depth and excitement to the gameplay.

Alongside these in game mechanics and features, having in game bonuses that "rewards" such as coins or currency will not only add to the longevity and engagement, but also personalisation, identity and self achievement. This all improves the player experience which Chapter 6: Gameplay from Game Design Workshop describes the player experience, with the goal being to create engaging, balanced, and enjoyable gameplay (Fullerton, 2018).

Regarding the soundtrack ideas (listed below)

Soundtrack/music

80's nostalgia and aesthetic - atmosphere of 1980s Malibu, complete with neon lights, retro cars, and a jazzy soundtrack.

Jazz soundtrack integration

Story driven gameplay - Players are not just racing for victory but also racing against time and the police to protect their stolen loot.

I wanted to do more research into music and this style and genre of and ended up taking inspiration from GTA and Cuphead. For GTA, players have options to change their own radio in the cars, to which i always loved having an upbeat jazz playing in the background while i caused mayhem.

As for Cuphead, their game features a jazz-infused soundtrack, which fits perfectly with the challenging run-and-gun gameplay.

I ultimately decided for a up-beat jazz-influence soundtrack after reading multiple articles, alongside chapter 9 Sound and Music of Fullertons Game Design Workshop article talking about how music can shape a players opinion towards a game.

After reading through the articles i have gained some insights on how music can be utilised to improve player experience.

When choosing a game pitch for assignment 2, i was very unsure on what to pursue. I wanted to chose something that demonstrated creativity and originality but as well i wanted it to be feasible for creation when forming groups and finalising on a pitch.

ive decided to go with my asteroid pitch - cosmic cat

Surrounding the art style, i am no artist by nature :,) so i decided to play around with different art styles as i wanted to keep the art of the game (characters, backgrounds, enemies) my own design. I ended up deciding on creating pixel art as it is quite easy and less time consuming.

so far i have played around with some designs and colour wheels for the game.

As of now i have created a couple simple power up designs alongside the enemies (UFO's) .I used a multitude of medias to create my one sheet, that being Powerpoint and Adobe photoshop.

For the design of the one sheet i wanted to keep the design quite simple, however visually showing off the aesthetic of the game and a clip of what the gameplay actually looks like. Including elements of space, and keeping the colour theme contrary to the space theme.

Final design

After working on previous games and concluding on my final individual game project using GDevelop on my MacBook i have some final thoughts. I've encountered a few performance issues that have been a bit frustrating. First off, GDevelop doesn't seem to run as smoothly as I'd like it to on my Mac. The software tends to lag and freeze, especially when my project becomes more complex with multiple objects and events. It's not uncommon for the interface to become unresponsive, which disrupts my workflow. Additionally, I've noticed that GDevelop doesn't take full advantage of Mac's high-resolution Retina display, making the user interface appear a bit blurry and outdated. These issues, while not insurmountable, do pose some challenges when trying to create games on a MacBook.

Moving forward however as i have begun with my racing game and immediately encountered issues with the rotate command. As i followed the original instructions for the rotating angle and speed my car would move forward like the following:

I have played around with different commands, angles and speeds and have came to a reasonable result.

In addition to this following the instructions that is given to us is harder to follow along with, as for some reason i have noticed a lot of the commands are labelled differently.

Beginning with a clear vision of the game's mechanics, I delved into GDevelop's event-based system to breathe life into my ideas. It's all about setting up conditions and actions, like mapping keyboard inputs to control the car's movements or implementing physics for acceleration, deceleration, and steering.

Managing collisions with track boundaries and other game objects became a struggle. What strikes me most about this process is how GDevelop's event-driven approach simplifies complex tasks, making game development accessible to a range of skill levels.

Frenzy Mode:

In another previous post i talked about how Fullerton puts an emphasise how predictability can influence player engagement and satisfaction. Balancing predictability and unpredictability is crucial for maintaining player interest over time (Fullerton, 2018). I decided to implement this "gear shift" mechanic as in the context of a racing game, the addition of a feature that requires players to remain alert and prepared can significantly improve the player experience. By introducing dynamic obstacles, such as these gear changes that has consequences if not completed, has players kept on their toes, adding an element of unpredictability that makes races more engaging and challenging. Variable track conditions, like a wet track affecting vehicle handling, force players to adapt and adjust their strategy on the fly, adding depth and excitement to the gameplay.

Alongside these in game mechanics and features, having in game bonuses that "rewards" such as coins or currency will not only add to the longevity and engagement, but also personalisation, identity and self achievement. This all improves the player experience which Chapter 10 and 11 from Game Design Workshop describes the player experience, with the goal being to create engaging, balanced, and enjoyable gameplay (Fullerton, 2018).

Adding onto the music element talked about in my Elevator pitch, i discussed including a upbeat jazz-infused soundtrack to the game.

while my game is in development i thought of the mechanic from GTA 5 where the player is able to change the radio station inside the car.

Update Now i have no clue if adding a mechanic like this inside my game for players to interact with will be successful, however i would love to be able to see if its possible. Otherwise, maybe including different soundtracks as purchasable items as well for players to unlock may work as well.

Following the ideas and pitches i had posted previously, i will try my best to bring those ideas and designs to life, but as of now i need to try my best to finish all of the programming, and fix all the bugs and issues i'm already running into. Will post updates as i progress forward!

Chapter 3 of Fullertons book Game Design Workshop: A Playcentric Approach to Creating Innovative Games, discusses the importance of crafting clear and engaging objectives when developing games, as this serves as the driving force for player engagement and enjoyment (Fullerton, 2018)

With my current design for my asteroid, i hope to be able to include more unqiue gameplay mechanics in the future. This being more power ups, boss battles, enemies with varying health and ranging difficulty.

In addition, including potential game modes for players to choose from

Mayhem!:

A gamemode for competitive gamers, just pure destruction! Players have limited health bars and the only goal is to kill as many enemies as possible! there is no time restriction, only the increase in difficulty as time progresses. The game only ends when the player loses all their health.

"Objectives give your players something to strive for. They define what players are trying to accomplish within the rules of the game."

When reviewing my final prototype and having 2 people playtest, i came to the realisation that other than surviving, i didnt have any other clear objectives inside my game. Feedback i received was that yes the overall aesthetic is there, and the fundamentals of an asteroid game is present; shooting asteroids to survive. However my game lacked substance, with no other game mechanics setting it apart from already exisiting asteroid games.

Questions that were discussed regarding improvement were:

"Could the be implementation of new objectives, such as destroying a certain amount of asteroids? that being varying coloured asteroids?" (Fullerton, 2018)

My thoughts for future iterations was having the task for players to have a certain target of enemies defeated per round.

"Sense of predictability would affect not only strategy but also player engagement." (Fullerton, 2018)

I have mentioned this quote in a previous post, but essentially Fullerton discusses how predictability can influence player engagement and satisfaction. In addition, balancing predictability and unpredictability is crucial for maintaining player interest over time.

With my prototype, my playtesters mentioned how the game had no real increased difficulty or any form of surprise. After further discussion what they mean is that it was easy to predict the progression of the game as i programmed the asteroids to spawn in quite slowly and consistently, with no other addition of enemies, powerups ect. They found after playing the game for a longer period of time it become uninteresting.

If i were to revisit this prototype in the future, i would implement more features that have the player gaining powerups, movement enhancements, additional projectiles with different affects. In addition making the asteroids spawn in more randomised patterns with altering speed.

After reading chapter 7 Protoyping, i had some reflctions regarding my asteroid prototype.

Fullerton mentioned the importance of structure and priorities that i felt as though i should have taken into consideration when visualising and creating my prototype (Fullerton, 2018).

Structure and Prioritisation:Although it may seem like common sense, Fullerton emphasised at the beginning of the text, to prioritze essential elements of the gameplay first before continuing with the prototype.

I realised afterwards i prioritised the overall aesthetics more so then the essential mechanics and elements of the gameplay, leading to a lot of flaws during the playtesting.

..........

Playtesting:

As i wasnt able to attend the workshop, i had my roommate test out my prototype!

This racing game sets the scene with an '80s Malibu vibe. Set against the backdrop of sun-soaked beaches, palm trees, and neon-lit streetsPlayers will find themselves immersed in a high-stakes chase after a daring bank heist, all accompanied by a jazzy soundtrack from your speakers. In this game you will be in the midst of a high-speed chase with police as you just committed a crime of theft.

Design:

The design for this game will be centred around Malibu, with palm trees, beachfront promenades, and vibrant city streets, all drenched in the nostalgic neon glow of the era.

Gameplay:

Players will engage in intense high-speed chases with the police, weaving through traffic. You will be tasked with dodging roadblocks, spike strips and other obstacles. Your goal is to keep your stolen loot safe. There will be coins featured across the tracks for players to collect, this will be added up for players to spend towards the end of the game at Black Market Exchange" (in game shop); an area for all criminals to purchase stolen goods such as new add ons, cosmetics and cars.

Players will also be required to hit correct gear changes similar to when driving a manual car in real life. Players will be prompted with a visual notification for when they must change gears, and with each successful gear change a meter bar on the side of the screen will fill up. When this bar is filled up, the players car will go into frenzy mode! However the players can be penalised for not hitting each gear shift, if missed players bar will remain empty and will gain a small temporary speed decrease. If the meter is filled and they miss a gear shift change, players will lose progress on their meter.

Features:

In a previous post i discussed how Fullerton emphasised in her book Game Design Workshop, the relationship regarding the resources, upgrades and outcomes and how its essential to a game (Fullerton, 2018). With this pitch and with the ideas i have in my mind i wanted to have a focus on power-ups the player could potentially interact with.

Coins: Players can pick up coins in their tracks that add up towards their "bank" currency. With this, players are able to access the "Black Market exchange"

Black Market Exchange:

This will simply be the shop where the players can purchase new cosmetics. I want to keep the theme consistent with the players being criminals.

Frenzy mode:

Players must successful hit each "skill check" which in this case is a gear shift, so this will be a notification on the screen where players must hit consecutive number of keys on their keyboard to activate the gear change. When successful a small section of a meter bar will be filled.

When in frenzy mode, players will gain temporary invincibility and speed boosts.

However when unsuccessfully hitting the gear shifts, players will experience a small speed decrease, meaning the police will become closer to capturing you! If your meter is somewhat filled and you miss a gear shift, your meter progress will be decreased!

Target Audience:

Ages 12+

Any players who have a fondness for the 1980s and appreciate games that capture the essence of that era, from the music to the aesthetics accompanied by the fast-paced experience of the racing game. Anyone who also seeks a game in which requires quick responses with high stakes.

Unique selling points:

Soundtrack/music

80's nostalgia and aesthetic - atmosphere of 1980s Malibu, complete with neon lights, retro cars, and a jazzy soundtrack.

Jazz soundtrack integration

Story driven gameplay - Players are not just racing for victory but also racing against time and the police to protect their stolen loot.

I came to the idea of adding this style and genre of music from my inspirations of GTA and Cuphead, which for GTA, players have options to change their own radio in the cars, to which i always loved having an upbeat jazz playing in the background while i caused mayhem.

As for Cuphead, their game features a jazz-infused soundtrack, which fits perfectly with the challenging run-and-gun gameplay.

I ultimately decided for this theme after reading multiple articles, alongside chapter 9 Sound and Music of Fullertons Game Design Workshop article talking about how music can shape a players opinion towards a game.

After reading through the articles i have gained some insights on how music can be utilised to improve player experience. When creating ....

With this game prototype i really wanted to focus on my aesthetics and playing around with assets GDevelop has to offer.

While developing the game, i explored the asset store, which brought me to a few designs. As of right now i'm not super satisfied with the character design (replacement for a ship) as i imagined it being more of a birds eye view of the cat + the overall designs visibility. With this i decided to make my asteroid game progress horizontally instead of vertically .

Alongside this i decided to make the projectiles white stars, which i have encountered an issue. When the player shoots the projectiles the animation of the stars is spawning well above the cat which makes aiming the stars a little more challenging.

Regarding the whole map i kept it a little more simple with the colour palette being predominately purple and pink with the appearance of a few little galaxies simply for aesthetic :).

Regarding my code, im still a bit unfamiliar with GDevelop and coding. So far i have encountered issues with the asteroids spawning. When playing i have found that either there are very few asteroids spawning, or a mass amount of asteroids spawn pretty much killing the player instantly. I am trying to figure out where i exactly went wrong with this issue.

These are all the other assets i have added so far, however i havent included the "meteorRed", "Meteor" or "TiledEmptyUiHeart". I have attempted to change the previous black meteors to the new designs but with each attempt it seems to fail with the meteors not spawning at all.

Astro Cat: The Purrfect space adventure

Astro Cat has all the elements to a normal asteroid game in mind so far.

Aesthetic:

This game will also be based in space of course, hence the name,

I envision the game straying away from simply just a spaceship in space and wanted to be a little more creative with the overall aesthetics and design.

The player will control a cat in space in which the projectiles are stars. While moving through the galaxy and shooting down asteroids, the player is able to gain power-ups, which these power-ups could potentially be either stars or hearts (something that fits with the cute aesthetic in my head). As well as this, the thought of adding unique animations for the cat would add a unique charm to the game.

Unique selling points:

Vibrant cosmic visuals alongside the captivating space environment filled with neon and cosmic aesthetics that are sure to dazzle players and immerse them in the games universe. Seeming that this game strays away from a lot of the aesthetics and design of previous Asteroid games; The characters' distinctive designs and animations, coupled with their dance moves, add charm and personality to the game, setting it apart from other space-themed titles.

The shooting mechanics itself allows for captivating gameplay

Gameplay:

Mechanics: Players will use arrow keys to move, mouse or touch pad to aim, and left or right click to fire projectiles.

The game will feature multiple levels, all with increased difficulty as you progress forward; more asteroids, movement of asteroids increased ect.

Players will control a cat in which shoots stars at projectiles!

Players will be required to defeat a set number of UFO's under a time limit. Players will start with 5 health bars, and are able to pick up power-ups and health points.

This game will feature a cosmetic shop in which players can earn points by completing levels. Players can purchase new cats with their own unique power -up they can use during the game, so all players with different playstyles can enjoy!

Target audience: 7+

Gameplay:

In regards to my original concept for my platform prototype, I had made several changes to the gameplay and implemented new features. I originally was contemplating wether or not I wanted to implement a way in which a player can kill enemies. When prototyping and developing my ideas for gameplay I moved forward with keeping the enemies un-killable, however recently I have been watching tutorials on how I can add a feature where players can pick up a weapon; ray gun of some sorts. With this they gain the ability to shoot a projectile to kill enemies within a vertical range.

In addition, I was not able to play test with people inside my workshop, however I had my roommate, who isn't too familiar with playing video games. I had originally had only three lives for the player; loosing one when coming into contact with enemies and losing all of them when falling off the map. I had realised that maybe I made the game a bit too difficult, especially for non-experienced gamers and even younger players. Moving forward I decided to have 5 lives, however with an increase of enemies. Alongside only losing one heart for when a player falls off the map.

I had mentioned previously with the animations that I had to remove them all from my character as it caused a bug where the players character would immediately fall through the map when beginning the game. I had tried multiple times to figure out what the issue in the code may be but came to no conclusions.

Design:

When designing, I was again contemplating wether I should change the design of the character even though it actually fits with my design theme. After finishing my prototype I tried to play around with creating a new design myself but found I did not have enough time nor experience with drawing to create my own.

After working on my prototype, I wasn’t very satisfied with the overal concept I had chosen. I felt as though it kind of lacked substance and wasn’t very creative. While working my job (I work as a barista) I thought of an idea I would actually like to trial out as a platformer if I have the time. Here is a somewhat finalised elevator pitch for my new idea.

New pitch idea!!!!!!

Gameplay

Players embark on a caffeine-fueled journey through various levels, each set in a unique coffee-themed environment. The game encourages exploration, discovery, and a relaxed pace while delivering an engaging platforming experience.

The game features a soothing lofi soundtrack that adapts to the player's actions and the environment. The music changes tempo and mood as players progress through different levels, creating a calming and immersive atmosphere.

Coffee inspired power ups - Brewster can collect coffee beans, which serve as power-ups. These beans allow him to perform unique abilities, such as espresso boost jumps, cappuccino glides, and mocha ground pound attacks.

Each level is set in a different coffee-themed world, such as a bustling coffee shop, a serene coffee bean farm, and an ancient coffee temple.

Visual Design

The game boasts a cozy and inviting visual style with warm colors and detailed pixel art. The coffee-themed environments are filled with lush vegetation, steaming coffee cups, and lofi-inspired art pieces. The characters and enemies have a cute and quirky design that fits well with the overall aesthetic.

Ages

After reading through chapters 3, 4 and 5 of Game Design workshop by Tracy Fullerman (2018), i have taken some particular parts, particularly from chapter 5 Working With System Designs into consideration especially when play-testing my platform game, future game developments and overall playing around with GDevelop.

Takeaways from Chapter 5: Working With System Designs

"If you said that the element of chance in the game would increase in both individual combat encounters and overall outcome, you are right." (Fullerton, 2018)

Essentially, Fullerton highlights the concept of introducing chance as an element in games as this a a core component for creating an environment where the player may feel a sense of agency and allows for more strategic thinking.

Even though we have only made it through half of the current semester and still have many play testings and game developments ahead of us, i will be making sure to include elements of chance into my own developments. In the context of the platform game i have created.

This may be achieved by adding in the ability for players to gain power-ups: empowered space boots which increase the height of when the player jumps, randomly appearing obstacles or enemies ect.

Although i haven't fully explored the limitations of GDevelop as of yet, potentially taking creative liberties and introducing some sort of weather-like effects such as solar flares, radiation storms, or energy surges that affect gameplay in unexpected ways.

"Also, the value of resources and the upgrades available via those resources would disappear because upgrades to units and armor would mean nothing in terms of determining outcome."

Fullerton (2018) emphasised the relationship regarding resources, upgrades and outcomes and how its essential to a game. following this, it is discussed further that essentially if there are changes to the system's components render certain elements irrelevant, the strategic depth and decision-making in the game might be compromised.

"Sense of predictability would affect not only strategy but also player engagement."

Similar to the previous point, predictability can influence player engagement and satisfaction. Balancing predictability and unpredictability is crucial for maintaining player interest over time.

Thinking forward and imagining my ideas and current rough designs of games, i feel as though having the difficulty of a game varying throughout the progression of the storyline/and or physical progression through levels in a non-linear way may enhance a players engagement with the game itself.

"This is important for game designers to realise because games can only be understood during play when their dynamics become evident."

This emphasizes the practicality of understanding systems through gameplay. Game designers must test and iterate their designs to truly grasp how the dynamics unfold in real-world player interactions.

Fullerton also discusses how predictability can play a big part in a players decision making and can be detrimental to the player experience. Essentially removing the aspect of "randomness" can potentially lead to more calculable outcomes within a game, damaging the overall excitement and surprise factor that a player may experience, predominantly coming from uncertainty within a game (Fullerton, 2018).

Will continue on with chapter 3 and 4 in the next post once i have garnered a better understanding of the topics. :)

After having time practicing and playing around with GDevelop for the first time, i have faced some challenges and still unsure of the limitations of GDevelop and my own skills.

Following my pitch, my skills are still very underdeveloped however my goal is to somehow implement an element in which players are able to obtain some sorts of artifacts as they complete levels of varying parkour difficulties.

So far i have developed areas in which players are to avoid enemies whilst progressing forward throughout the level. I have kept in mind a quote from Fullertons Game Design Workshop "they wont play for long unless the gameplay hooks them" (Fullerton, 2018), in which Fullerton discusses the fundamental truth of game design in which a players engagement lays within the game designers ability to define the players experience within the game world. This being controls, objectives, difficulty, challenges ect. Therefore moving forward i will focus on these elements when further developing my platform game and my own skills within GDevelop.

When first creating my platform game, i have ran into some difficulties. Firstly when creating my first sprite i found when applying running/jumping animations this would force the player to fall through the map instantaneously when previewing. So far i have had to remove all animations as i have not figured out a resolution to the issue

Alongside this, when creating enemies i had struggled with the collision behaviour for creating the enemy to move left and right.

Whilst playing around i had realised this was due to me inputting incorrect angles of force as well as having the action for the direction of "flip horizontally" as no for both left and right.

Regarding the characters, i kept both the original playable character and enemy the same as to when i was following along the tasksheet for creating this platform game, as i believe it conveniently enough fits very well with my theme of space.

In a future discussion regarding aspects mentioned from chapter 5 of Game Design Workshop, i hope to play around more with adding elements of "chance" and resources that allows players to be able to experience the game in different manners. This being able to either spend time gaining things like armor, power ups to help assist in progressing through each level, or simply relying on the parkour element and mechanics of jumping from platform to platform. I want to create a game in which different types of players aren't restricted to a certain play style, and this applies for any future developments as well.

Alongside this it is discussed that having various forms of objectives helps keep players engaged and grants them a feeling of gratification once completing tasks and missions, even if it is not the main objective of a game (Fullerton, 2018). Therefore my current goal as of now is to figure out ways in which ill be able implement an objective of collecting artifacts to align with my original pitch.

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Fourth Edition (4th ed.). A K Peters/CRC Press. https://doi.org/10.1201/b22309

Before i properly played around with GDevelop, i had many ideas of creating a platform game which main focus would be centred having to players working on solving puzzles to progress through each stage. I had already planned on adding too many complex features, which exceeded my own capabilities with using GDevelop, especially being new to the software. Thus after reading chapter 1 of chapter 1: The Role of the Game Designer by Tracey Fullerton. I took into consideration setting "player experience goals". She discusses the importance on narrowing down on how you want a player to experience your game alongside focusing on the features and parts of your game that make it "unique". After reading this i wanted create some sort of game which will have player to feel a sense of satisfaction after completing certain requirements and goals of the game.

After properly having a go at playing around in GDevelop, i have come to the realisation that my skills and confidence will most likely not be developed enough to create a game of this complexity, especially being my first.

I have decided on creating a minimalist single player parkour platformer which will feature simple graphics and controls whilst having increased difficulty with each level moving forward. The main genre will be Scifi and be based on a single explorer who is trying to collect scattered pieces to rebuild his spaceship (the planet the game will be based on is undecided) to return back to earth.

Title of game

Star seekers

Setting/Style

Concept Art:

Image by upklyak on Freepik

The game will be based in space and the player will control an astronaut. Enemies featured in this game will be a multitude of different coloured aliens.

Varying coloured enemy aliens

Varying coloured stars (power ups)

Music will be a sort of Lofi track, with visual sound effects when obtaining power ups and dying to enemies/ falling of the map

Gameplay/Mechanic

The game will focus primarily rely on acquiring scattered pieces of a spaceship whilst manoeuvring past enemies (aliens) in which can damage the player. However i want to elevate my idea by including a power up feature, in this case may be obtaining certain coloured stars which grant immunity or advantages when dealing with the correlating monster (an example would be collecting a blue star may grant a time restricted immunity against a blue monster ect..) To be able to complete the game, the player must have collected all pieces through each level to be able to create the spaceship in the end of the game.

The player will use basic moving mechanics such as the arrow keys to move forward, back ect.., the space bar to jump ad will use physics

The player will also have a health bar and coming into contact with enemies will afflict damage and will lose "health hearts" in correlation with such.

There will be areas that have negative space for the player to fall through, in this instance, the player will automatically die and lose all health hearts and progression with spaceship pieces collected.

Will be power ups scattered in different areas, however in areas surrounded by an increase in enemies (so it becomes more rewarding for the player).

Each level will increase in difficulty for the player (harder parkour areas, harder areas to reach when collecting the scattered pieces, more enemies ect..)

Target Audience:

Ages 7

This game will feature no blood, and only requires the player to avoid the enemies rather than kill them. The death animation of the player will not be graphic, more so just a "fade" effect.

Why is my game compelling?

the game increasing difficulty will allow for players to remain engaged throughout each level,

challenges featured throughout the levels will force players to critically think and problem solve: this could be through having to figure out best ways to navigate through enemies, gaining certain power ups and timing them correctly when attempting to pass certain enemies ect.

Having an objective alongside parkour, this being collecting artifacts players must make contact with to obtain, only allowing the player to progress onto a new level once all pieces have been collected. Each level will have an increased difficulty meaning players will have to think harder about how they will approach each level.

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Fourth Edition (4th ed.). A K Peters/CRC Press. https://doi.org/10.1201/b22309