IGB220 Assignment 1 - Reflective Journal

Sorren Manson - N10282912

[sorrenm]

Week 13 (Assignment 3 postmortem)

Familiar Witch became my favorite game cycle of IGB220. The final result was the most functional and complete game I had created so far, albeit not on my own. When comparing my mini playtesting sessions for the first three game cycles compared to the deep playtest for Familiar Witch, the quantity of feedback was considerably greater. It was also an engaging experience assuming the role of the communicator, where I was directly running the sessions. The iteration process became far more successful, a direct result of larger quantities of data to analyse. 

The elements of assignment three where I believe could be improved if Familiar Witch was to continue iteration would be exploring mechanics in greater depth. For example, rather than create a level exploring all aspects of the intended game, have levels dedicated to the one mechanic. This would allow us to really push these ideas to their limits, hopefully in turn creating a more engaging and enjoyable experience for the player. Gdevelop proved a useful tool for game design, as it was relatively simple to pick up and comprehend. However, it’s main downfall was the lack of a collaborative function. On a smaller scale project such as this it was manageable, but I could see how on larger projects this could cause significant issues with team collaboration.

Overall, I was happy with my own progression as a game designer. It was evident across the four game prototypes my improvement of designing games, using playtesting and feedback analysis to create a better experience for the player.

[sorrenm]

Week 12 (Assignment 3 findings and changes)

Below is the findings and change recommendations table I created for Familiar Witch from the compiled playtesting feedback data.

[sorrenm]

Week 12 (Assignment 3 playtesting)

During the playtesting sessions for Familiar Witch, I assumed the role of the communicator. Throughout each session, I would brief the player on how the session runs, and the expectations of both parties. This being that it was important that they would speak their thought process out loud, even through steps that may be considered irrelevant to them. In turn, I made it clear that we would not be speaking during the test, nor answering frequent questions relating to the game. However, as the session was a deep playtest, if progression would stagnate I would prompt the player with hints to push them in the right direction. After the playtest and survey was complete, I would openly answer any questions the tester had regarding Familiar Witch. 

From the role of communicator, I frequently had playertesters asking questions throughout testing. It was important that I did not answer them in relation to Familiar Witch, as it result in a false representation of a naive playtester. When this would occur, I would elaborate on the fact that we could not respond or explain the game during the playthrough. I also greatly shortened the intended script, as many playtesters were testing multiple games. It was tedious for both the tester and the testing team to go through the same script when majority knew the process. This was not universally done, only with playtesters familiar with the speaking their thoughts out loud where a practice exercise was not necessary. 

[sorrenm]

Week 11 (Assignment 3 iteration)

The version of Familiar Witch going into playtesting was a combined effort from the team. I had created the power up mechanics, the enemies and the familiar, Ryan added the Title screen and other UI elements and Bec designed and built the levels. Below will run through the main elements of Familiar Witch version 6.0.

The title screen used Bec’s original artwork from her initial pitch. Ryan created the menu design. 

- The start button places the player in the first level

- The tutorial button places the player in the tutorial level

- How to play brings up the instructions and controls

- Exit closes the game

The tutorial level covers the basics of Familiar Witch. The player has a linear level layout, which slowly introduces new mechanics. The player interacts with signs to learn about the upcoming section; the gem followed by the wand. A basic enemy type is also introduced. 

The main level builds upon what the player learns in the tutorial. The beginning increases the difficulty on an initial platforming section, followed by the first enemy type again.  

After the first section, the level opens up in a less linear fashion. While there is one path that leads to the level end, the player has the option to explore the various pathways. To maximize score, all pathways must be cleared of enemies, however the player may simply walk to the end of the bottom pathway to clear the level at any time. Each pathway uses the different mechanics: the wand, the broom and the familiar. 

The broom path has the player navigate a gap too large to clear with a regular jump. After reading a sign explaining what the broom does, the layer must use the newly acquired ability to get the gem. They then can shoot the gem’s spell (right click) to save the enemy and earn 100 points towards their score.

The wand path has the player repeat the block moving process from the tutorial. This unlocks the room with a gem, and a ladder leading to the bouncing enemy. The enemy is hard to  predict as I designed it to randomly bounce around the room, this pathway is possibly the most difficult aspect of Familiar Witch.

The familiar path has the player read a sign, teaching them how to switch controls to the familiar. They then must walk through the pipe to get the previously inaccessible gem. Continuing to the right, the player must then face the walking enemy type along with some additional platforming. At the end of this tunnel is the door to the next level. 

Reflecting upon the current version of Familiar Witch, I am quite happy with the result. Playing the game within our team, I believe we have created a good foundation to bring to the actual playtesting process. Majority of our intended designed was implemented into the game. The only element we were unable to add currently was the timed scoring mechanic, designed to punish slow gameplay for a high score system. 

[sorrenm]

Week 10 (Assignment 3 development)

1. Items

Broom.

The broom item was relatively simple to set up. I setup a variable called broom, which kept track of whether or not the player had picked up the broom item. Once picked up, the events would check if the player was falling or jumping, and allow them to jump once more. Initially the broom would have the player hover, however this functioned in a similar way and was much easier to implement.

Wand.

The wand used a similar code that Bec had created for the mechanic trapping the evil animal spirits. It used the same process of using  a variable to check if the wand had been picked up. It would track the mouse position, and fire the spell towards it, destroying itself upon impact. 

2. Familiar

The familiar was considerably difficult to implement, and while it does function it is quite chaotic in nature. This may add to the enjoyment of the game (the difficulty definitely increases), playtesting should reveal the impact in greater detail.

I again used a variable to determine if the player was controlling the witch or the familiar. It was important that the familiar moved alongside the player. Upon pressing Tab the witch stopped in place and the player directly controlled the familiar. This was achieved by having the familiar follow the players position, while playing the correct animations. Immediately upon switching, the camera snaps to the familiar’s position.

3. Enemies

Ground and Flying Patrol.

The enemies patrolling the ground and the skies were simple to set up. These used near exact event set-up used in the original platformer tutorial for game cycle 1. 

Bouncing.

The bouncing enemy was probably the hardest mechanic to implement. Through trial and error, I have a event setup that checks if the enemy is stationary, then launches it upwards in a random direction. This solution came after the previous design, which proved incredibly catastrophic and unpredictable. The old system had invisible colliders set up, upon collision the enemy would launch diagonally left or right. To not have it going crazy, I had to set it so that each collision would only trigger once. The downfall of this method was that if the enemy collided with two seperate ‘right’ colliders, it would sit still. The solution to this was the random bounce when stationary event setup, which actually allowed me to remove the mass of colliders i had set up entirely. Two colliders are used on the sides to prevent the enemy going past. 

[sorrenm]

Week 9 (Assignment 3 start)

After hearing all the pitches from the other students within my tutorial, I joined a group with Bec (and Ryan) who pitched the game ‘Familiar Witch’. This was a cute. retro styled platformer where the player controls a witch. The aspect that I really grabbed me as really unique was that instead of defeating enemies, they were corrupted animals. The player was required to pick up empty crystals and with their magic restore the creatures. Bec had also envisioned exploration for up-gradable items, but had yet to implement it. 

Below are the One Sheet and One Page Bec had created.

As a group we came together to further the current design of Familiar Witch. Several revisions of the game were made:

1. The witch would have a familiar that follows them around the map. The player can switch controls to play as the familiar, accessing places the witch cannot fit.

2. Two items would expand the witches abilities. A wand would allow the witch to fire a spell which would interact with specific pieces of terrain and the broom would allow greater jumping distances. 

3. Three enemy types: ground based patrolling, sky based patrolling and a randomly bouncing variant.  

4. The crystals would work the same way as intended. Upon pickup the player will have an empty crystal slot, which when cast upon an enemy will trap the angry spirit, freeing the friendly creature.

5. A scoring system would be implemented. It would take into consideration: animals saved and time

A task allocation spreadsheet was created. For the prototype development, I was assigned enemy creation, power-ups and the familiar. 

[sorrenm]

Week 8 (Assignment 2)

Jolly Roger Racing - One Sheet.

Jolly Roger Racing - One Page

[sorrenm]

Week 8 (Racing post mortem)

My concept for Jolly Roger Racing was ambitious, to the point where I was unable to implement some design idea give the short game cycle. However, the current prototype did result in some chaotic fun during playtesting. The mechanic idea that I was most proud of was the randomized map obstacles (whirlpools and explosive barrels). Implementing these I managed entirely on my own without outside resources, showing to me the potential of Gdevelop and the intuitiveness of it’s design. On the flip side my lack of experience had once again prevented me from adding a mechanic, the ship choosing system. If pursued as my Assignment 3 game I believe I would be able to implement this, however it was out of scope for this initial cycle. 

Jolly Roger Racing aimed to create a challenging gameplay, where the player could personalize their experience. While I believe the challenging gameplay goal was met, the personalisation never quite made it in the game yet. 

[sorrenm]

Week 7 (Feedback)

Three participants playtested the current prototype of Jolly Roger Racing. This had them play for 3-5 minutes, commenting as they play and then leaving feedback notes. All of these were then compiled into a table to easily identify the key issues and strategies to address them.

[sorrenm]

Week 6 (Game update)

Clarified by the tutor (Chris), I am able to use the starter project file for a top down racer. This allows me to skip creating the basic movement and AI, and immediately work on Jolly Roger Racing’s unique mechanics, being unique playable ships, randomly generated obstacles and cannon warfare. I will also need to replace the sprites with ones relevant to the setting and theme of my game. 

After looking around for a free asset pack, I came across the Pirate Pack on Kenny.com. This contained everything I was looking for plus more, so I implemented these assets and adjusted the layout of the race track. Below is the first iteration of the level with a functional track. I did not want to spend a huge amount of time building the level so I can focus on the unique mechanics.

The first mechanic I added was the randomly spawning explosive barrels. I figured how to implement this on my own, using knowledge from the asteroid game. The explosive barrel object had multiple animation variants and would randomly assign one on creation, with 3/4 deleting itself upon creation. This allowed me to place a large amount around the map with only a quarter on average actually spawning at a random set location.

The next mechanic added was the whirlpools. I originally it to send the player spinning in a random direction but I could never get it to work properly.Instead I decided to have it function as a forced breaking system, where a player would slow down considerably if they went through a whirlpool. I added in the random spawning system I used for the explosive barrels as well.

When implementing the shooting mechanics, a problem occurred.I follow the simple shooting setup events and absolutely no shooting happens in game, despite my code being identical to what it is supposed to be. In class I will ask for a second opinion as I have spend an hour or two trying to fix it and nothing is working.

SOLUTION: Turns out the X axis on my background was 1, not -1. This meant that the cannonballs were spawning but were hidden underneath. 

Shooting currently works, however it is not executed perfectly. It shoots the way the ship is shooting, rather than were the cannons are facing. It also only shoots out of one cannon at an unrealistic rate of acceleration. In the future, this aspect will need to be refined.

At this stage it was time to playtest. Jolly Roger Racing was at a playable and testable state, however a lot of work is required for the intended game. Hopefully feedback can help me iterate what is currently in the game and future additions.

[sorrenm]

Week 6

Game Cycle 3 Elevator Pitch.

Title: Jolly Roger Racing

Pitch: The worlds greatest pirates gather for the annual Jolly Roger Race. The winner not only earns endless treasure but the bragging right of being the fastest pirate sailing the high seas. Players will take control of a pirate of their choice, with each captain’s ship having unique traits. The race takes place on an ocean course, with various obstacles such as islands, explosive barrels, and storms. Each ship is manned with cannons, varying on the captain chosen.

 Image:

Player Controls:

WASD = movement

Spacebar = shoot cannons

 Selling Points:

Unique choice of ships.

Randomly generated terrain obstacles.

Cannon warfare.

[sorrenm]

Week 6 (Postmortem)

Reverse Asteroid, on paper was a unique concept. In practice however, I failed to create what I had originally envisioned, the resulting prototype being rather unpolished.

I did however learn some techniques in Gdevelop I could apply to future games. Learning how to create randomly generating objects and different locations is a vital component of many games, and I can see myself using it in my next game. Another mechanic was that of enemies tracking player location and the player tracking mouse movement. These open up the possibility of using the mouse as possible input alongside the keyboard. Previously I had only considered standard keyboard inputs for my platformer.

Areas I need to improve are primarily related to setting an beginning and end state to my games. Throwing the player straight into the gameplay loop, without instruction consistently resulted in confusion and frustration. Have a goal or endgame causes a similar reaction for testers.

[sorrenm]

Week 5 (Feedback)

Playesting was formatted in the same way as the previous game cycle. Playtesters would participate in short 5 minute sessions, where I would prompt them to walk me through their thought process as they played. I would then ask them on their thoughts on the prototype, and record for analysis.

[sorrenm]

Week 5 (Development)

The first mechanic implemented was the player movement along with the boost ability. This done by following the asteroids tutorial provided for basic mouse following movement. I then added a short boost the was locked on a timer so it could not be used infinitely. Below is the events and a demonstration. 

I have had a very tricky time attempting to create enemies that function well. Currently I have an enemy that tracks the player and fires a projectile t the player. However, it works not as intended. As demonstrated in the GIF below, the enemy ship drops the bullets, which then after a time shoots in the players directions. Despite this not working straight forward like expected, I decided to keep this mechanic in as it creates a unique dynamic where the player must react to delayed bullets.  

With my variable tracking system not working correctly I came to the conclusion that making a unique boss system was at this time impossible. Instead, I opted to create another enemy type, the kamikaze ship. This ship would hype jump randomly onto the screen, charge its boosters then charge at the players position in attempt to blow itself up on contact (along with the player). This enemy could not be rammed by the player, they must instead dodge them entirely while attempting to destroy the other enemy type. 

[sorrenm]

Week 4 (Asteroids elevator pitch)

Title: Reverse Asteroids

Pitch: In an alternate universe, the asteroids are considered the heroes and the space ships the villains. Playing as the lone surviving asteroid, you must survive and fight back against a fleet of asteroid murdering spaceships. The player will be avoiding enemy gunfire, while trying to ram them directly to take them down. A variety of powerups are dropped by random enemies ensuring the experience is varied each time. Reaching certain ship killing quotas will unlock the chance to fight a boss. Depending on which variable the player fulfils, a unique boss will spawn.

 Player Controls:

Mouse = movement

Left Click = boost (used to destroy enemy ships)

Right Click = use powerup

 Selling Points:

-          Interesting twist on a classic arcade game

-          Randomly generated powerups

-          Variety of bosses spawning directly effected by player actions

Images:

[sorrenm]

Week 4 (Postmortem)

Experimenting within Gdevelop for the first time, I didn’t expect a perfectly functional game, which is exactly what I ended up with. I attempted to cover a variety of unique mechanics within ‘Super Massive Blackhole’, with different levels of challenge for implementation. As an example, the platforms where the player can phase through was considerably easy to create using events. In contrast, creating a functional gravity flipping mechanic as a Gdevelop noob proved difficult. Despite making this feature somewhat functional it was glitchy, messy and extremely difficult to control without considerable practice. I wanted to create signs that acted as a tutorial for the player, as I dislike the idea of an instructions screen that dumps a load of text to the player in one go. The signs offered a solution, where the player would slowly be introduced to the mechanics one by one. This was my favorite design decision and I aim to recreate a similar mechanic in later games.

Iterative design was an important aspect of the development for my platformer. Not only did I have a recorded and analysed playtest of the my game with a naive playtester, but I was constantly testing the game as I implemented ideas. Evidence of this was the sign system, without feedback I would have had a game without instructions. Players were also discovering bugs I never found, as well as showing me a player experience from some who hadn’t spend hours developing it (me).

[sorrenm]

Week 3 (update 4)

This session was set up for playtesting the current state of our games. I had three different people play my game for roughly 3-5 minutes each. During the playtime I took observation notes and asked each the same set of questions. Players were treated as naive playtesters, being told nothing before playing I did offer prompts if progress stagnated to long. Below are the results compiled in a table. 

Two issues discovered will not be solved due to the limited time span of development. Both the gravity and keybinding issues require a vast amount of coding and overhaul of the game’s default behaviors for platformers. Due to this I decided to focus on the other problems.

The first fix was that the player changes direction depending on which way he is moving. This was incredibly easy and I cannot believe I missed adding it in earlier. I simply flipped the character horizontally based on the left and right key input, both when on the floor and jumping. 

The next issue I addressed was making sure the player was aware that the alien could not be jumped on to defeat it. I never wanted to have the player directly destroy the alien by touching it them self, but rather long ranged combat of some kind. The sign was changed from saying: 

“Watch out for the alien! (Combat mechanics work in progress)”

to

“Watch out for the alien! It's poisonous body will hurt alot.” 

Hopefully this will make the player think twice before attempting to touch it.

The final fix was adjusting the final gravity puzzle towards the end of the level. The black and yellow girders often saw players becoming stuck and completely bugging out if they made contact with them. To solve this I removed the girders creating the initial tunnel as it was impassable for anyone not experienced in navigating it. The puzzle itself was made more accessible and more fair, playing through it felt less janky and far more satisfying.