Game Development Blog

What Follows.: Assignment 2 - Updated

The main issue for my first version of my Assignment 2's One Sheet and One Page was the size of the text and, as a result, it's readability. To fix this I resized the test to make the document more readable without the need to zoom in.

One Sheet:

One Page:

Entropic Collapse: Assignment 3: Playtesting

We held our first play test on the Friday of Week 11, utilizing the e-sports arena. Our original roles for playtests placed Alex as the Playtest Communicator, however, due to extraneous circumstances , I ended up in the role of Playtest Communicator with Bowen and Lachlan taking notes. We decided - with the playtesters consent - to also record a voice note of the playtest as a means of keeping a record of any important verbal feedback that we may have missed at the time of play testing.

Overall, the play test feedback was extremely useful for the process of improving our game. It provided our team with great insight on how to make the game better by making it more engaging and fixing bugs or clunkly features that made it unpleasant to play.

This round of play testing specifically highlighted the importance of a tutorial page. We ended up adding a brief tutorial after the Playtest Script before the testers played the game. Otherwise, they were too frustrated with the game play and died to quickly to be able to properly explore the game play. This could have effected our ability to gain valuable play test data on the other aspects of the game that wouldn't have been reached without the impromptu tutorial.

Notes From Playtests:

Playtester 1 Notes:

Game rules and tutorials

How enemies working and attacking?

Health systerm

No rewards

Game design looks interesting

 Confused on what were enemies that would harm him and what wouldn’t harm him

Need to put a tutorial explaining game rules and what the goal of the game is 

Doesn’t feel like he is getting rewarded from playing 

Wants to see visual feedback or tangible feedback for collecting rubble or killing enemies

Playtester 2 Notes:

Likes title screen (colours dynamic effects)

Can see tiling on the background

Title screen asteroids can de-spawn

Unsure if they should use as

Wants to recover health

Variance in rubble shapes

Stop enemies from spawning on player

Asteroid feels like it might have too big of a hit-box for damage

Wants movement tech

Quick restart option

Increase difficulty of shielded enemy

Add movement to background

More variety of planets

More nuance to shields (speed can destroy them etc.)

Likes the background movement follows mouse action

Likes the colour selection and simple clean main menu

Likes the buttons highlight effect

Likes the lighting effect in the game

Enjoyable sound effect follow the in-game actions

Likes the black hole design

What should player aim for? (alive or destroy)

The main menu changed when failed a game

 Liked the subtle movement that follows the cursor in the main menu 

Tiling of the main screen image is off

Could be cool to incorporate the dynamic background into the on in gameplay

Simplistic design and the oranges with the starry background looks really nice

Credits doesn't work

Assignment 3 Progress - Group Formation and Game Development

Week 10 marked the start of Assignment 3. In the workshop this week we formed our groups in which we would be working with in order to complete the tasks.

Our group of 4 Quickly formed and we dubbed ourselves the name: Gravity Gigglers or Group 26 as our official group. With our group formed we then had to choose who's game we wanted to prototype, based off our groups previously completed Assessment 2's. We decided to go with Lachlan's Game: Entropic Collapse due to it's unique application of the physic's mechanic within GDevelop.

During the workshop we also allocated tasks amongst the group and created a detailed play testing timeline so that the assignment would be completed on time and the task load would be spread as evenly as possible.

Entropic Collapse's Sell Sheet:

Entropic Collapse: Game Development

My main role in the group was to design and create the assets and animate the relevant parts.

Background:

The background only needed to be altered slightly over the period of development. The main changes was the alteration of the "star" placement so it would tile neatly within GDevelop and the colours were altered so it would fit the established colour pallet, so the sprites that were used didn't look separate from they world they were being placed in.

Enemies:

Laser Enemy

The first enemy we decided on was a laser enemy. Unfortunately, we decided to remove it from the game due to problems with the code that would fire the laser and being unable to set up a proper system so all the laser enemies wouldn't fire simultaneously. This was an issue because, if they were spread out across the screen, the beams would become an inescapable web of lazers - meaning instant death for players.

Shield Enemy

The shied enemy was originally supposed to be blue when shield was activated. However, when play testing the players were occasionally confused by the colour, assuming that the blue meant it was a friendly vessel, only to learn that it was an enemy when they were destroyed. To fix this issue the shield colour was altered to red, due to red often being associated with enemies or bad units. The playtest held after this change showed that the colour change did solve this issue.

A fire animation was also added to make the unit feel more dynamic and "alive".

Bomber Enemy

The bomb enemy was added to give some diversity to the enemies to make the game feel more interesting. These ships were programmed to chase the player around and explode after a certain period of time, damaging the player if in collision with them. two different flashing speeds were animated to reflect how close the ship was to exploding and damaging the player. When paired with the beeping sound effect, it was an effective visual and audio clue to warn players about the tiny enemy units approach, giving them a hint to dodge before the explosion.

This enemy unit only went under one major change, which was it's size. Originally the bomber enemy was quite small, which made it difficult for players to see it, making it frustrating and not engaging when playing the game. To repair this the sprite was increased in size and the red flashing element was increased in brightness and saturation, which made it much easier to see against the duller planet coloured rubble.

For the same reason and the shield enemy, a fire animation was also added to make the unit feel more dynamic and "alive".

Planets:

The planets used these three sprites and were randomised to create some variety and visual interest. Only slight changes were made in regards to harmonising the colour palette, scaling (if they were too small or too large) and adjusting the shadows and highlights of the sprites.

Asteriod

Assignment 2: What Follows.

For my Assignment 2 we had to choose a base idea to further develop and pitch by making it a One Page and One Sheet. I decided to expand upon my racing game idea: "What Follows.".

One Sheet:

The purpose of a One Sheet (Sell Sheet) is to sell the game to its potential audience. It only displays key information, such as: the game's title, an X statement, the developer's contact details, and a brief description and the game's core mechanics, features and selling points.

One Page:

What Follows.: Racing Game - Development Post

I experimented with adding my own assets during the development of my racing game prototype.

I ran into a couple of problems when doing this:

My file sizes were VERY different to the ones from the tutorial (this included the spacing between the lanes and the size of the entire road).

When exporting the files the colours dramatically changed, the colours appearing MUCH darker than I originally intended.

This meant that I had to experiment with the file sizing and scaling a lot while making this game, but I learnt a lot about transferring external files, the importance of file scale and how GDevelop works with assets that don't use pixel art (unlike the previous two game prototypes that we created this semester).

Racer: Elevator Pitch

*Something to be noted: this is a concept and therefore it will most likely be subject to change, major points will be updated over the project's duration

Title: What Follows.

Theme: Top-down Racer, Horror

The fog is relentless. It carries nothing but the echos of screams and howls of it's victims as it envelops everything in it's path. In this game 'Temple Run' meets 'Horror' in the form of a top-down racer, where you must work to outrun the inevitable in your rickety old car.

There is no other option, you must outrun What Follows.

Concept Art:

Game Mechanics:

WASD movement controls

Mouse is used to aim

Left & right mouse click – use character abilities

Lives - Players are provided with 2 lives that can be lost via:

Running into road obstacles

Getting hit by the monsters

Going too far backwards into the fog

Going off the road (treeline)

Character abilities are determined by the players character selections at the beginning of the game.

Possible abilities may include:

Bomb (destroys monster/obstacle selected)

Time slow

Foresight (shows player where future obstacles are going to appear for 2 seconds)

ect.

Audience: Ages 13+

Selling Points:

Multiple unique characters whose abilities allow for a different experience each play-through

Simple gameplay structure makes it easy to learn the game and improve in skill

Point-based score breeds competition between players by comparing scores (Leader board system) and wanting to be the best

Student Contact Information:

FOOD FIGHT!: Asteroids Development Post

The most challenging part of developing the asteroid game was linking the lives UI to the asteroid collision. Once it was working I was free to adjust lives and the score UI to reflect the desired difficulty of my game.

For this game prototype I wanted to experiment with the use of different enemies but also adding a variety of different sprites to each enemy so that it was more visually interesting. In the place of the "teachers" and "students" enemies that are shown in the Elevator Pitch's Concept Art, I instead opted to use the meteor sprites provided (with smiley faces added to them) to save time on assets so I could focus on the games logic.

I also experimented with giving the enemies different firing rates (teachers, students) in an attempt to make the enemies feel more dynamic.

To improve this prototype in the future I would want to add a variety of different offensive enemies, maybe even providing the enemies with defensive abilities as well. This would make the game feel less repetitive and predictable due to the single type of enemy attack at the moment.

I would also like to add the power up feature that I discussed in the Elevator Pitch to improve the games sense of fun.

Asteroids: Elevator Pitch

*Something to be noted: this is a concept and therefore it will most likely be subject to change, major points will be updated over the project's duration

Title: FOOD FIGHT!

Theme: Asteroids

FOOD FIGHT! is an asteroids style game in which the player takes on the role of a mischievous high school student who does not wish to return to class. This has resulted in a showdown-esque situation where the player must throw food from behind the tuckshop counter to stave off the hordes of teachers and students that are trying to drag them back to class. This leaves the player with the challenge: how long will you last before you are dragged back to class?

Concept Art:

Game Mechanics:

Left and Right Arrow Keys – used to move left and right to dodge projectiles from enemies

Mouse is used to aim

Left Click of mouse – fire players projectiles

Lives - Players are provided with 3 lives that can be lost via:

Getting hit by the "Cleaning Supplies" or "Detention Slip" from the teachers or "Food" from other students

Power Ups (such as multi-shot) are picked up on player collision and time out after 5 seconds

Audience: Ages 7+

Selling Points:

Fun elements and design providing entertaining atmosphere and engages the audience

Simple game loop allows for the game to be learnt quickly

Point-based score breeds competition between players by comparing scores (Leader board system) and wanting to be the best

Student Contact Information:

Playtesting Insights:

During the Week 4 Workshop we had an opportunity to play test our platformer game. I took full advantage of this despite the flawed prototype I had ready.

Play Test Insights:

When play tested the feedback was centered a lot around the movement mechanics of the player. While the speed and movement was fun when rolling, as soon as the player returned to the snails regular state they player found the pace too slow which affected their ability to engage with the game. At the time of play testing the level was incomplete and served as a display of features rather than a polished prototype. The lack of background and the fact I was still experimenting with the best way to get the platform to move to a fixed position also didn’t lend to the players immersion or the incomplete look of the prototype.

Platformer Development:

To make the original concept more manageable for this prototype I decided to focus on a single level rather than attempting to make a bigger project.

This week I expanded upon the experimental prototype, while keeping it to the single level.

For Snail Pace I wanted to add a moving platform mechanic that would allow the snail (when in a rolling state) to interact with the leaf, hitting it’s “lever” to trigger a waterdrop to fall and make the platform move by “growing” the flower platform upwards. While I achieved this in the Experimental Prototype, it was still not transferable to multiple instances within the scene. I fixed this by programming the flower platform to move to the small black boxes (invisible when the game is running) which served as an anchor for it. It wasnt a neat solution, but it got the job done. Although I would like to clean the movement up and add animations to the flowers in the future and maybe even find a better system to acheive the same effect.

Snail Pace: GDevelop Experimentation

For Snail Pace my main focus was experimenting with the interaction of the player character with other game objects, especially when the player is a specific status.

The most complicated section of my prototype concept would be the moving platform. I wanted it to move to a very specific location however at the time I was still unfamiliar with GDevelop and needed to figure out the best method to achieve the desired effect. Ideally, I wanted the platform to look like it was a growing flower using an animation and a more organic programmed movement. However, due to time constraints and my limited knowledge at the time, it was an unrealistic goal. Instead, I aimed to get the flower platform to just move at a diagonal when triggered by the players interaction with the plant, while also carrying the player character with it.

I eventually got the platform to work properly however I was unable to get it to reset and the code was only able to be used for that specific platform and wasn't transferable to platforms placed in other locations.

Moving Platform:

Experiment Game:

Above is what the Experiment Game looked like. It was very rudimentary design with one of each game asset/ mechanic.

2D-Platformer Game: Elevator Pitch

*Something to be noted: this is a concept and therefore it will most likely be subject to change, major points will be updated over the project's duration

Title: Snail Pace

Theme: 2D-Platformer

You are a snail. And GOODNESS GRACIOUS are you hungry! The only thing between you and that beautiful lettuce is the humans who REALLY want to keep it. In this 2D platformer players have to traverse a range of obstacles and puzzles in order to get to their goal using items they unlock over the progress of the game, but be careful, it can be dangerous in the garden.

Concept Art:

Game Mechanics:

Movement:

Uses arrow keys to move left and right

‘Space Bar’ is used to jump (with the appropriate items equipped)

Snail can ball up into its shell and roll by using 's'

Lives - Players are provided with 3 lives that can be lost via:

Taking damage from enemies

Rolling into walls too quickly

Falling from high places

Taking damage from obstacles (e.g.: eggshells and salt, ect.)

Selling Points:

Humorous playful elements and design provide fun atmosphere

Picking up different items provides the player with unique abilities that build upon gameplay and reward players as they progress

The gimmick as playing as a snail

Student Contact Information:

About Me:

Hi! My name is Kaitlyn and I am a current student studying game design at QUT. Games have been a huge part of my life - looking back over my memories I cannot think of a time where I haven't been surrounded by them. Some of my fondest memories is sitting on the couch with my Dad as he taught me how to absolutely demolish our foes with my necromancer in Diablo 3 and staying up to odd hours of the night with my friends discussing and playing through the deep lore of Story Games together. To me games are not only a means of entertainment but a form of creativity and they provide a unique reflection of the world that we live in. They are stories that are created through the collaboration between the players and the developers, and through that, it becomes something more.

For that reason I was inspired to study game design. My ultimate goal (and dream) is to be able to create compelling and intricate games that allow players to explore complex themes and worlds that they can share as a common experience to bond over with their friends, family and peers.