ordinary00

[ordinary00]

Assignment 3 - Post Mortem

Within the final week of the semester, the lecture session was used as a play-testing period. During this time, our team were able to successfully playtest our most recent version of 'Galaxy Bandit' with the remaining required naive testers, more notes were taken and data are recorded in the playtest findings table. The team will now be able to continue working on the final version of the game and make progress towards the report.

By the end of all playtesting, below are our findings:

In my opinion, the team did exceptionally well to develop such a great game with the provided game engine. The game captures the essence of challenge and rewards through the progression of difficulty by increasing a score requirement, introduction of new enemies, and a final boss level. The game had evolved so much in the span of a few weeks. Some notable inclusions are the scoring system, advanced movement with momentum, and the introduction of powerups to enhance player experience and increase fun and playability.

There are some areas that I believe the game can still benefit from:

The enemies are almost perfect with their aim, and could result in frustration among players. Decrease their aim will allow players to move with a little more freedom, while still focused on their goal to achieve the required score to advance to the next level.

The tutorials lack explanation on some mechanics the game offers. This is founded during our Playtesting sessions. Including them may assist players to be more active and less likely to discourage them when they kept losing.

Advanced movements with momentum are added at some point to remove the 'staticky' feel of the player ship when they abruptly stop. The introduction of the movement momentum is a nice change, but also comes with a new challenge. Players colliding with obstacles are more often than before, but at least dodging enemies' bullets are easier as the player ship is constantly moving. But player aiming is also a little more difficult as the ship will still be moving.

Overall, I am satisfied with the outcome of this development.

[ordinary00]

Assignment 3 - Prototype Development

Improvements were made to the prototype for the next playtest session during the workshop. Based on Chris Lee's initial playtest feedback, the control scheme of Galaxy Bandit has been changed to keyboard keys. Character movement is also changed in that the spaceship is moving within the "space", and obstacles should spawn just outside the player's field of view. There are also other changes, such as the inclusion of a timer ticking down instead of up, and a score goal in the UI. The UI is also changed where it is now static and remained on the player's screen as the spaceship traverses the space. Additionally, the health bar sprite is changed as the previous one wasn't working as intended.

Once the team had implemented feedback to the initial prototype, these changes are now ready for playtesting once again. It is a crucial process that Tracy Fullerton expresses in Chapter 9 of 'Game Design Workshop'.

At the time, we were able to recruit a playtester during our workshop other than Chris Lee, which contributed to our count of naive testers for the entire project. Some of the findings in this session can be found below:

Playtester 1

Want to go back to previous screen.

Want Options menu. 

A few bugs.

Picture demoing the controls, goals, etc.

Standing still. Wondering if there are any reasons they should be moving.

Once enemy ships introduced, starts moving.

Is there a limitation to fire rate? Playtester kept holding down shoot button. Their recommendation: Is there a timeout for how long shooting is?

Standing still again, waiting for obstacles to pop into view.

Finding the enemies scary.

Wondering the damage dealt from enemies to player.

Control: More control. Boosts in speed to evade.

UI cleanup

Want game to end once score reaches goal.

With such informative data, the team will utilise them (after populating it within a playtesting findings table) to implement future iterations of 'Galaxy Bandit'.

[ordinary00]

Assignment 3 - Initial Playtest + Development

As discussed in Tracy Fullerton's 'Game Design Workshop', specifically Chapter 9, playtesting is a vital process of any game development, yet it is often overlooked. The team understands this importance as we prepare our initial prototype for playtesting during Week 11's workshop.

We had our low-fi prototype ready to playtest and gain insights into the many potential areas of improvement. Our main goal at this stage is to get the movement "right". During the workshop, Chris Lee was able to partake in this initial playtest, and some notes were taken:

Increase difficulty over time - game feels too easy.

Keys for movement - currently a little too slow but is a preferred control method as it feels more player controlled.

Add more content for an interesting experience.

Based on these initial findings, the team were able to refine the prototype so that it aligns with the playtester's feedback.

Reference: Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[ordinary00]

Assignment 3 - Group Formation + Development

My group was formed the week prior to mid-semester break. We are a team of four, and their names are Nicholas Kruger, Nicholas Burda, and Kyle Goodwin. The team's identity is known as "The Consonants".

Development and progress of Assignment 3 began with Part A. In an overview, the main task is to determine which One Page among the team will be chosen to use as the main prototype, of which we all agreed it will be Nic K's "Galaxy Bandit".

Once the initial processes were done, we began to brainstorm of potential features the prototype may benefit to enhance player experience. Some of these notes are pinned within Discord, our main preferred method of communication.

Galaxy Bandit Brainstorm Ideas:

Point system at certain miles new things are introduced

Points per asteroids/ships

Newer ships appearing have

New scenes with new difficulties, new elements introduced? E.G. Music, speed,

Camera follows ship.

Tracker that tracks number of ships in a scene

Different scenes with different difficulties. Respawn at beginning of CURRENT scene

Enemies that shoot or follow player

Timer for scene progression and points

Shoot = gain points

Asteroid has health? As the game progresses the asteroid becomes less relevant but maybe slight bit more difficult?

Give enemy ships health (Object Variables)

Additionally, we also planned our time for the remaining weeks of the semester. Each member is assigned a role:

And activities for the weeks are also recorded:

[ordinary00]

Racing Final Prototype + Post Mortem

In this final prototype, I've added additional movements for the player where they can now move forward and backwards, giving the player a little more flexibility to evade the obstacles in their way. A simple score system is also added to encourage better gameplay and aiming for a high score.

POST MORTEM

Similar to Asteroids, this game is also inspired by the racing game example that I had created during my workshop. In this implementation, I've expanded on that by adding additional obstacles, expanding the play area, and introducing some more challenges.

Like all other game developments, this game can also benefit from further enhancements to improve experiences for players:

The current boundaries of the 'water' area are very difficult to avoid. If the player object slightly touch the hidden boundary, they will crash. This can be remedied my moving the boundary a little further away, but will then allow the player to position their sprite over the water, which is also not ideal.

Similar to the water area boundary issue, when the player go off road, the sprite will suffer speed penalty until their sprite is no longer in contact with the hidden boundary. However, as you can see in the final prototype video, the sprite still suffer from speed penalties even when the majority of the sprite is no longer off road. A potential fix for both this issue and the water issue is to remove the sprite turning when moving altogether. However, this change will remove the difficulty of navigating pass obstacles.

Certain areas of the play area does not spawn obstacles, or obstacles are not large enough to cover a wider area, hence leaving a few spots that lets the player to just stand still without needing to move at all. One such place is the ground area between the roads. These issues can be fixed by spawning in additional obstacles.

The left side of the road spawn cars that are moving much slower than other areas. This is because cars in that lane are conceptually depicted to be driving up, so the player's car is trying to out speed them. We can add more variety in that the cars moving even slower, so they will be moving much quicker as the player speeds past them. However, this may introduce other problems in which cars are spawning on the same lane with different speeds, and ends up overlapping with one another.

The current way the game functions is that each time the player crashed, their score will reset. I've noted earlier during development that I have found a variety of sprites that can be used each time the player crashes to add more variety and making the game less dull.

On that note, different player sprites could also indicate different lives of the player in one game session. A lives system allows for second chances, or multiple chances to continue working towards that high score.

Additionally, another challenge that could also be introduced is difficulty levels. When the player's score reaches a certain threshold, the time to spawn obstacles is reduced, further spawning more obstacles more often.

That's it...I think.

Game improvements aside, Chapter 10 of Game Design Workshop by Tracy Fullerton discusses the functionality, completeness, and balance of games. With this "complete" prototype, the game still isn't exactly finished, leaving room for future game fixes mentioned above. However, with functionality, the core mechanic is to constantly spawn obstacles that will move down in the player's screen. For a racing game that aims to get a high score without touching obstacles, I believe the game is functional. At this current stage, the balance of the game feels a little in favour of the player, making it unbalanced. As noted before, there are sections that are not covered by obstacles, the intervals in which obstacles spawn can be a little slow, and the left side of the road spawns much slower-moving obstacles. I feel that if changes were specifically made to these areas, the game would eventually become unbalanced again, but this time not in favour of the player.

Reference: Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[ordinary00]

Racing Prototype #3

There are now many objects added that will act as obstacles the player must avoid. This game is also heavily influenced by the racing game example in the workshop, but I've expanded a bit more on the play area. Additionally, rather than stopping the player when they're too close to the water, I've decided to make it an extra challenge that the player must avoid touching it as it will result in game over if they do.

[ordinary00]

Racing Prototype #2

The main core mechanic of this game is to move left and right to avoid collision with objects and stay 'alive' as long as possible. I want to further challenge the player by adding in additional challenges the player must endure to stay alive. For example, there is a small section of ground between the two lane road. When the player attempts to cross over, their maximum speed will decrease and leave them vulnerable until they can regain their full speed again.

[ordinary00]

Assignment 2 Progress

Assignment 2 is coming along nicely with a finished draft of One Sheet. Not the best looking one compared to examples provided but I believe it portrays the game genre and mechanics effectively. At this point, I'm concerned whether there will be enough content for it to be even considered a game. Perhaps a One Page will remedy this.

[ordinary00]

Racing Prototype #1

Starting off this project by looking around for assets to be used. I've found a nice road as well as some details to the scene. There are also a variety of different car models that I have found that can be used as details and obstacles as well.

[ordinary00]

Racing Game Elevator Pitch

Title:

Drive, DRIVE, DRIVE! (Placeholder name)

Genre:

Racing

Audience:

All ages

Pitch:

You’re a responsible driver who is currently driving safely…oh you’re speeding. Who are you trying to get away from? …or what? Whatever the case, just DRIVE!

Control Diagram:

The player car is constantly moving. The only way to stop is…well, you crash and hopefully don’t die.

Left and right arrow key to turn to move the car.

AVOID COLLIDING WITH OBJECTS IN YOUR WAY.

Selling Points:

A little inspiration from a game called “Crazy Taxi”

You’re literally speeding, probably for a good reason but still, you’re speeding. (People probably find speeding fun. Probably)

There's not much else besides driving and speeding.

[ordinary00]

Asteroids Final Prototype + Post Mortem

I've managed to convert the game into the proper genre of 'Asteroids'.

This will also be the final prototype as I believe it is 'complete'.

The player's ship will remain in the centre throughout the game, with the ability to rotate left and right to aim and destroy meteorites that are spawned from the top and bottom of the window.

I've implemented a simple 'Game Over' overlay, and players can restart their game with a button press. The game window size is also changed into a square so the player can see more of the meteorites spawning and moving.

POST MORTEM

This game is heavily inspired by the Asteroids example that I created during my workshop. I wanted to explore other possible mechanics that GDevelop can provide by opting to approach this project with different control schemes. With this in mind, a chapter within Tracy Fullerton's book 'Game Design Workshop', stands out to me. Specifically in Chapter 1 'Designing for Innovation', I believe that my initial approach to the game genre is an innovation, but over time, I had a chance to reflect:

If the game genre 'Asteroids' is well-known, taking it with a new approach will certainly introduce new perspectives. But, is it TRULY an 'Asteroids' game? Or does this create (or already exist) a new genre, similar to Shoot 'em Up? Overall, I believe that my game is straying from the original genre of 'Asteroids', hence at the last minute, much of my time was spent on capturing that genre within 'Saving Planet Earth', with the exception that controls are based on keyboard keys (again, approach probably existed somewhere already).

With the final prototype, there are areas that can be improved to further enhance the experience for players. Some of these possible game iterations are also influenced by lectures:

There are noticeable visuals that incorrectly appear. For example, the bullet fired from the ship appears normal when the ship is facing up. When it is rotated, the bullet is created at incorrect positions. The bullet is also spawned facing in the wrong direction, that is other than going up.

Meteorites can explode and spawn smaller ones.

A point system to encourage aiming for high score.

A lives system that maintains the points earned during one session.

Perhaps a game objective and levels. For example, a certain amount of meteorites will spawn and players must destroy a minimum amount to proceed to the next level.

Could spice up gameplay by introducing special powers.

That's about it I think.

Reference: Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[ordinary00]

Revised Asteroid Game Pitch

Revised Pitch:

The end of the world is nearing. Meteorites are falling from the sky. The 'Apocalypse' has begun. Mankind sent their last attempt to space, a spaceship that is capable of obliterating the meteorites. You are one of many pilots sent to space. Destroy as much meteorites as possible, and don't die.

Revised Controls:

Rotate left or right by using the Left or Right arrow key, or 'A' and 'D'.

Shoot using using 'Space' key.

When spaceship is destroyed, press 'r' to try again.

[ordinary00]

Asteroid Prototype #5

In this prototype, I've implemented the moving backgrounds and a quick and simple restart that spawns the player immediately after they have made contact with the meteorite. At this development stage, I believe the game is complete.

HOWEVER, it seems the game is straying from what an 'Asteroid' game is, as currently the game is not 'multidirectional'.

I will be attempting to tweak the game so that it correctly portrays the genre.

[ordinary00]

Asteroid Prototype #4

To deal with meteorites spawning and the player ship moving out of the frame, I've used coloured objects and surround it around the border. The black objects is slightly overlapping into the frame to limit the border a little further in so objects can't go outside the frame. Additionally, if meteorites were to spawn outside the frame and touches the black object it will be deleted but it will be able to pass through the white object. For the player ship, it won't be able to move pass either the black or white objects at all. This is achieved by assigning the coloured objects with the platform behaviour, the ship with the platformer behaviour with the default controls unchecked, and a gravity value of 0. The ship is moved through custom added controls.

[ordinary00]

Asteroid Prototype #3

I have added asteroids, and collisions. Currently, when the bullet and asteroid collide, both object will disappear. I'll probably add in an explosion animation. I've also included random speeds of how quick an asteroid falls down as well.

[ordinary00]

Asteroid Prototype #2

Implementation:

Movements are added (a, s, d, w/arrow keys) and shooting is mapped to space.

I'll still need to make the background move somehow so that it will look alive. I will also need to add a border to keep the ship within the window.

[ordinary00]

Asteroid Prototype #1

I have been looking for Asteroid game assets to be used in my game. The background fits in with the central idea of the ending of the world. There are also variations of the ship as well. I'm currently undecided on which to use, or perhaps use all of them as a way to represent the different 'lives' of a single play through. I also want to make the background feel 'alive' by making it move somehow.