02ashs

[02ashs]

Assignment 3 Post-mortem

After having completed Assignment 3 and our game BIORG I feel that I have learned a lot about the process of designing and making a game in a collaborative environment.

When creating the idea for BIORG, the group wanted a platformer that would introduce the player to game mechanics, in our case "cores" and then combine them in a final level. The player would take the role of our little robot character and escape this testing lab.

We wanted to engage the player with this character and its mechanics to form an experience that would draw players in and want to play our game. (Fullerton, Chapter 2).

One thing I would change about our prototyping process is communication and organisation. Throughout the process of creating our game it could be difficult to understand what stage everybody in the group was at, and if we were all on the same page. We did use Discord for communication which helped the process immensely, however I believe the disorganisation may have been due to a lack of specifically laid out designs. We had a general idea for the mechanics and who would be creating what level, but we may have been too disjointed with our level design and goals. Perhaps creating physical prototypes before digital ones would have benefitted the group. As mentioned in Fullerton's Game Design Workshop, creating physical prototypes is often a good idea before going digital and I do think creating levels on paper first and getting the team to agree that everything is in order would have been a better way of going about our game development.

Overall this was a valuable learning experience when it came to creating a game as a team. I now appreciate the importance of early development and getting everybody in a team on the same page when it comes to what is being created.

[02ashs]

Assignment 3 Progress

After further refinement on my level of our game BIORG, this is what I have.

I have changed where certain hazards are, added a better health UI as well as making un-killable enemies more distinct from killable enemies, mainly by changing their colour.

The rest of the team are working on their levels, and we will combine them all into a 4 level game.

Next I will most likely get more playtests using these questionnaires and surveys.

[02ashs]

Assignment 3 Playtesting

After getting people to playtest our game there are some common issues that each ran across. These include:

Boundary issues where players fall out of the level

Lack of animations for certain hazards makes them hard to understand what they are

Current grapple implementation causes a multitude of issues including phasing through objects and moving across the level

Other issues that were found:

Play tester 1:

Felt multiple health wasn't necessary with current difficulty

Showing the controls before game would be useful

Have target switch mechanic introduced earlier

Play tester 2:

Current difficulty too easy

Visual feedback for grapple would be nice

Maybe too slow-paced

With this information in mind, the team will now go back to our current game and attempt to implement some things to solve these issues. Personally I will try to add boundaries to the level as well as animate the hazards.

[02ashs]

Assignment 3 Development Progress

When developing the one-page for Assignment 3 our team built a small level to showcase some of the mechanics for our game.

This is the level that I made to show what the game might look like.

Apart from the enemy designs that I made I used pre-made assets.

The main character robot was made by my teammate Ethan.

The level assets that were used: https://craftpix.net/freebies/free-industrial-zone-tileset-pixel-art/

Using this showcase and all the info that our team (Tom, Ethan, Huy and myself) came up with, Tom put all of it into the on-page.

The next process will be integrating these ideas using GDevelop and creating working levels that can be played.

[02ashs]

Racing Game Post-mortem

For the racing game I had 3 people playtest it.

Common issues that arose for all 3 players included a particular difficulty spike driving around a corner. I believe I got too comfortable with my own difficulty.

Players also found it difficult to tell when they were taking damage and what was causing it.

Other issues that were individual to players included the controls being too sensitive, and made them lose control too often.

The abilities were not utilised as much as they could have been.

Having a visual indication for the cooldown of the jump ability.

Having a level between the first and second in order to reduce the sudden spike in difficulty.

Audio being a bit too loud.

Adding a timer would encourage players to get a fast time.

Finally, one player found multiple ways to get out of the level and over the invisible walls placed.

[02ashs]

Racing Game Development

To speed development I am using free assets:

Vehicles - tmdstudios.wordpress.com

Track Parts - https://craftpix.net

Audio - https://kronbits.itch.io/freesfx

Barrels - https://bradfrey.itch.io/oil-barrels

Explosions - https://ansimuz.itch.io/explosion-animations-pack

First I created a selection screen for the 3 vehicles the player can choose

Each vehicle has its own attributes.

Red Lightning: As seen above

Gatling Green: Low Acceleration and Speed, High Deceleration, Gatling Ability

Blue Jumper: Medium Acceleration and Speed, Medium Acceleration, Jump Ability

Used the track assets to create 2 courses.

These tracks started out with just the tile pieces to get a layout. Then yellow invisible borders were added so the player can't leave the playing area.

The red squares are detection points for blocked gates, that unlock when the player goes through it.

Rocks and barrels were placed as obstacles which are to be avoided. Each vehicle has different ways of playing around these obstacles. Red Lightning has to move around these obstacles with its speed. Gatling Green can destroy barrels with its gun, but must avoid rocks. Blue Jumper is able to jump over barrels.

Audio was added to give feedback to the player. When hitting a barrel not only will it explode but the sound of an explosion plays to reinforce the effect. The detection zones have audio so that the player knows something has changed, that the red lights have become green and passable. Using any of the abilities has its own distinct sound as well.

When designing the course I tried to cater to all vehicles and their abilities. Long sections with lots of barrels that Green Gatling could go straight through shooting, Blue Jumper would be able to jump over them, and Red Lightning would need to dodge. Other areas would be filled with rocks where all vehicles had to dodge through. And paths that only certain vehicles could safely access.

For example Gatling Green can shoot these barrels and create a safer path to go.

I will need to get feedback to see if I have successfully catered for each vehicle.

[02ashs]

Racing Game Pitch

Title: Rocky Road

Premise:

A top-down pixel, racing game where the player can pick between a variety of vehicles that each have unique properties with advantages and disadvantages. For example, some vehicles might have weapons while others might be faster. On the tracks/ courses there will be obstacles where the player will need to use their vehicles' abilities to proceed.

I am aiming to balance my game by using a “rock, paper, scissors” method where each vehicle has strengths and weaknesses, but none are necessarily better than the other. Fullerton details how this works in games in Chapter 10 of the Game Design Workshop textbook. Even giving an example for a racing game where a car might be good going up hills but do poorly on corners.

Unique Aspects:

Terrain affects vehicles

Vehicles each have different properties and visuals

Multiple ways to get through courses

Possible Controls:

Vehicle facing will follow cursor

"W" to accelerate

"LShift" for turbo

"M1" for projectiles

Some inspiration for the types of possible vehicles:

[02ashs]

Asteroids Game Post-mortem

When developing my game I wanted to take the base Asteroids formula and add onto it in order to provide more challenge and interesting gameplay.

One of the main ways that I did this was by attempting to add dynamic challenge, as mentioned by Fullerton in Chapter 4, so that as the game progressed it would provide more challenge for the player so that they wouldn't become bored.

Game Design Workshop: A Playcentric Approach to Creating Innovative Games. Tracy Fullerton. Chapter 4, pg. 98.

After playtesting, it was clear to me that adding enemies to shoot at the player was an interesting element that added to the game, however it did not make it as exciting as wanted.

Even with added challenge the game still got boring to players after a short time. This has taught me that further innovation in the gameplay was needed, and more connection towards the player character.

[02ashs]

Asteroids Game Playtesting

Four people play tested my asteroids game and filled out a criteria survey, these were the results.

Everyone generally understood the objective of the game.

Everyone generally felt that the game flowed well.

The game wasn't as balanced as they would have liked.

Everybody agreed that there was a clear strategy.

A sense of tension and release was mediocre.

The game was generally fun to play.

Half felt the game was replay able, the other half didn't think it was as replay able.

What Worked:

Player movement was good

Added enemies provided interesting gameplay

Things to Improve:

Replay ability

Asteroid spawning

Increase challenge

Be able to interact with enemies

Red crystal colour should be different. Make red = danger only

Add border so player can't go outside playable area

New Ideas:

Powerups

UI elements

More enemies

Levels/ maps

Most Exciting/ Fun Moment when Playing:

Moving fast through enemy sight made more projectiles to dodge

Trying to get a high score

Learning the projectiles timing to be able to hit smaller asteroids.

From this feedback it is clear that for some players a game needs to be more than challenge to effectively draw players in. As Fullerton mentions in Chapter 2. For the future I need to more effectively create an interesting character or story premise to keep players interested.

[02ashs]

Asteroids Game Development

Things that I have been working on and everything in the game before the planned playtests.

In the beginning began by creating sprites for the player ship and asteroids.

Then added controls and movement to the ship. Added movement to the asteroids as well.

Asteroids spawn in randomly on the playing screen and breakdown when shot at by player.

Added crystals for player to collect which acts as a score, these only drop after small asteroids are destroyed. Creates positive feedback which entices players to continue playing. (Fullerton Game Design Workshop).

Added global variables for shields (player health) as well as crystals collected (high score).

Added game over screen with a way to restart game without exiting program.

I wanted to add onto the current systems present in the classic Asteroids game by adding more objects (enemies) and behaviours (the way the player moves and plays the game) to create a new dynamic. (Game Design Workshop).

To add to the basic gameplay of asteroids I began experimenting with an enemy onto of the screen that shoots when the play enters its view. This was accomplished by making a enemy view sprite that attaches to the enemy and when it collides with player it will shoot a projectile.

When the player collects 10 crystals a second enemy will spawn on the bottom of the screen. These enemies cannot be killed by player and projectiles cannot be shot down.

Created an alt-fire that shoots a larger projectile that can destroy multiple asteroids at once. Has a longer cooldown compared to regular player fire mode.

Added a start screen to show player controls before playing.

[02ashs]

Asteroids Elevator Pitch

Title: Between an Asteroid and a Hard Place

Genre: Action top-down shooter

Mechanics/ Premise:

You control a ship that needs to destroy asteroids in order to collect crystals. Enemies will attempt to destroy your ship while you are dodging and blasting asteroids. Asteroids can interact with each other and enemies as well.

The games unique selling points include the interactivity between the player, enemy ships and asteroids, as well as the different types of fire modes.

Setting/ Style:

The game will be set in outer space, with a pixel art-style.

Audience:

Game is intended for players of any age, with decent spatial awareness.  

Control Scheme:

Move ship with WASD and aim and shoot with mouse.

[02ashs]

Platformer Post-mortem

Readings that primarily helped inspire me from Fullerton's book were based around engaginhg players through a unique premise and character, as well as digital prototyping. (Chapters 2 and 8).

This helped me to create an interesting character, that players will attach to with a unique premise of changing forms to create interesting gameplay. Prototypes could be separated into different sections such as mechanics, feel, technology and aesthetics. Creating the digital prototype I focused heavily on gameplay and feel of controls rather than sound or aesthetics.

One thing that I would change about the prototype is definitely the visuals, adding extra detail in order to flesh out the environment, as well as taking playtest feedback and rework sections that players had difficulty on, and try to fix bugs. As mentioned in class playtesting and iterating on prototypes is essential in the creation of a good game.

[02ashs]

Platformer Playtests

Having created a basic version of my pitch idea, I got people to playtest the game while I watched. This enabled me to see sections that people struggled with. I also asked 4 questions at the end to get more information.

Using Tracy Fullerton's Game Design Workshop book, I utilised some of the questions that were mentioned when getting people to playtest.

These questions were:

What was a frustrating part of the game?

What was your favourite part of the game?

Was it clear what you had to do?

Was it what you wanted or would you like something else from this game?

7 people play tested my prototype level. Here are the results.

Issues:

-A common issue was players falling through the geometry, particularly when changing forms.

-A particular section, the laser section, was found to be a bit too difficult by almost every player.

-The character auto jumping when landing threw players off.

Observations:

-Some players combined the ball forms speed with the glide form, which was unexpected.

-Some players found an exploit/ glitch where they could spam the forms, which resulted in them being able to fly through the level with large jumps.

Player Responses to Questions:

Tester 1:

1- Yeah, but in a good way. Bit slidy in movement 2-Squash into vents and parkour 3-Yes, immediately knew what type of game it was 4-No, enjoyed it. Add more ways to move and more challenges

Tester 2:

1- Lasers timing was challenging, too fast 2-Jump glitch, character is cool 3-Yes, pretty clear 4-More levels

Tester 3:

1-Getting stuck in geometry, laser was too hard 2-The different forms 3-Yes, text was helpful 4-It was good, bit more content, more polished, animations

Tester 4:

1-Not really, challenging 2-Gliding section 3-Yes, didn't release had to kill boss 4-Good as is

Tester 5:

1-Timing of platforms 2-Laser flying 3-Yes 4-More combat

Tester 6:

1- Janky crawl reset movement 2- Spamming "s" because character is cute, liked animations 3- Yes 4- Character cosmetics

Tester 7:

1-Laser run was frustrating 2-Moving platforms 3-Yes 4-Not really, add some collectibles

[02ashs]

Platformer Development

-Created basic animation for character when moving left and right.

-Configured platformer behaviour and changed key bindings. Changed speed, gravity, etc.

-Got the 4 forms for slime player to work, each with different properties. (Issue with glide form sprite not showing in-game).

-Figured out how to make player be able to fall through platforms, by teleporting the model down with (x,y) coords.

-Made spikbot enemy move from left to right and interact with the player model.

-Every time the player collides with an enemy they teleport to (x,y) coordinates.

-Created laser obstacles.

-Created 2 types of moving platforms. One that goes from left-to-right and one that goes up and down.

-Put the level together using created tiles and sprites.

-Added text on-screen to show controls.

Below is previous testing scene to try the implemented features.

[02ashs]

Visual plan for a level for the platformer.

[02ashs]

Elevator Platformer Pitch

Name: A Slimy Situation

Genre: Action-adventure platformer

Mechanics/ Premise: A game where the player controls a slime, escaping through a lab complex battling both enemies and obstacles. As the slime, players will be able to morph their shape, as well as use movement options such as jumping in order to pass obstacles and solve puzzles.

The games unique selling points include the unusual protagonist being a slime with its morphing abilities, and the unique traversal that this creates.

Setting/ Style The game will have a pixel art style, set in a secret laboratory complex that the slime will need to escape.

^ A slime character I made with Piskel inside GDevelop ^

Audience: The game is intended for players of any age

Tracy Fullerton's Game Design Workshop book mentions that a game needs more than just abstract challenges in order to fully engage all players. Some of the ways this is accomplished is through unique premises, characters and stories. My goal is that this pitch will be able to create a unique premise that hooks players into an interesting world, through the eyes of a bizarre character.