Game Design Blog @badortilted - Tumblr Blog

Post Playtesting Changes Gameplay

RuNinja - A3 Postmortem 2.0

Additions to the game that could be added:

- Home Screen

- Death Screen

- Play Again Screen

- Larger variety of obstacles but using the same amount of forms as too many will be too complicated and confusing for players.

#IGB220

Post Playtest changes gameplay

#IGB220

RuNinja - A3 Postmortem 1.0

After playtesting with “naive” users there were a few things that came to show that the game wasn’t quite ready.

Firstly, the most common and recurring issue which could be classified as a pattern was the overall tutorial. There wasn’t enough explanation in the tutorial for the players to properly understand or grasp how the abilities work. Therefore, to fix this issue with the tutorial each form of the player ability was split with a brief written “how to” use the ability with an image showing what it would look like. The tutorial in the prototype was not clear enough as it did not state that the players first had to press the numbers on the keyboard 1 - 4 to change forms to use the different abilities. Therefore, the players kept dying after the tutorial ended as they were unable to pass the first obstacle that appeared.

Another problem was the User Interface (UI) of the different forms. It was found that a few of the users found that the UI was confusing because the colours of the icon did not actually match the land. The different icons have specific powers relevant to that land and the coloring of the icons did not match. Therefore, it created confusion for the player and they failed to pass some obstacles or kill enemies due to that. To fix/change this, a change in the icon colours would fix that problem: changing the color of the icon to match the land or change the color of the icon to match the form’s colour.

The hitboxes of the character, obstacles and enemies were too big at times. Sometimes when the playtesters moved a little too close but had not actually touched the enemy/obstacles the player died. This stops the players from properly avoiding them accurately without making a large amount of assuming that they may or may not die after attempting to avoid the enemies. This was seen when one user tried to jump over the enemy ninjas but died after barely touching the ninja due to the enemy hitbox being default square/rectangle which is inaccurate for the players. This was also the same for the boss that appeared and floated to the right side middle of the screen. If the player approached too close or too early sometimes the player would die without even actually touching the boss. To fix this problem, all the hitboxes for the enemies and obstacles would need to be changed to be more accurate for the players.

Finally, an exploit was found that the players could use form four and teleport far enough off the screen to the right before the next level would load in and glitch out. The player would be infinitely falling but would not die due to no boundaries being added in to kill the player if they were out of the map. There is already an invisible border that stops the players from running off the left and right side. To fix this issue, there would be a set kill border where if the player exited the screen using the ability they would automatically die

#IGB220

Thoughts/Changes

There were a bunch of additions to the game. The original pitch idea did include some things but was not enough to allow potential players to properly understand how to play the game.

We decided to add at the start when the player starts, a quick tutorial using a series of images that show the ability of the chosen form. The different form icons are located at the top left of the screen for the player to see and we had to add the numbers to indicate what number pressed would give which form. Additionally, those numbers are in the same order as the images appear.

A timer system was added so that the player can see how long they survive for and a boss that appears after a set amount of time has passed. A boss added to the design of the game because we wanted a new or different sort of “obstacle” the player had to deal with every once in a while rather than the same levels to make it more interesting and/or harder for the player. The boss initially had a firerate that was too fast for the player to dodge while avoiding the current obstacles that had already spawned. Therefore, the firerate was lowered which allows the player optimal time to move past the already spawned in obstacles before dealing with the boss.

The level does slowly approach a faster speed which needs to be capped but has not been added in yet.

#IGB220

Short Gameplay of created game

#IGB220

Assignment 3 - Commencement

It was interesting to see all the different game design pitches in the workshop. That workshop was used to pitch everyones design ideas from assignment 2 to form groups for assignment 3. It seemed a lot of people were too scared to approach someone to ask to join their group. This may be case because people weren’t sure if they would work well in the group or be able to do the tasks assigned or even might not have taken an interest in any of the pitched designs. If it was the latter, they would need to have asked to join someone after looking at their design with the highest interest comparing to the others or wait for someone else to join them.

Additionally, I also had a look through the design pithces by the other students in the workshop and was thinking about what I could potentially do/help with in the group and what is possible. I approached another student to join their group. However, at the same time two other students sent me a message about wanting to join me with my game design pitch for assessment 3.

Lucas and Ruaridh had joined my group and I discussed with them after showing them the one page and one sheet from assignment 2, what would be in the game and thought about any possible additions or changes with the existing idea. There weren’t any changes from that discussion.

A2 - One Page Below:

#IGB220

Postmortem – RuNinja – “Car Game”

There wasn’t really anything that I could think of to change as I felt quite satisfied with the outcome of the game. It’s not hard to learn and play. However, I do think that a larger variety of obstacles or game mechanics could be added to make it more interesting. This would be the case of adding more obstacles or enemies because the player could easily stay in one lane a majority of the game because all they would need to do is switch to another lane if something comes down at them.

An obstacle could be a boss that comes down after a certain time or points accumulated to shoot projectiles that is targeted straight at the player and the player would need to avoid obstacles and try to kill the boss at the same time.

Another idea could be an obstacle that takes up multiple lanes instead of one so that it forces the player to constantly move left and right as they aren’t sure where the larger obstacle will appear.

Even having something that explodes as it comes near the player and the explosion covers several lanes beside it with a larger area of impact/damage.

#IGB220

Development Post – RuNinja – “Car Game”

The creation of the game so far is coming to be what I had thought it to be. Though, there are slight differences such as the movement following the same coding as the tutorial car game to create this character’s movement is a little awkward for what the character needs to do.

The initial idea for the rock obstacles was that the player would have to run around it, but it wouldn’t kill them. However, after playing with it more, it would be better to have the collision of the obstacle kill the player rather than stop them running forward because it was too easy to avoid and not die.

Additionally, the original idea was that the player could also slash in front of them and throw kunai. This was changed to just throwing the kunai to make it more challenging. Slashing wasn’t much use and more of problem for the player because they would have to be up close and it would be better to just throw the kunai and not slash.

#IGB220

Elevator Pitch – “Racing Game”

Title: RuNinja

Pitch:

Runinja is a game where you play as a ninja character that is infinitely running at the bottom of the screen. The objective of this game is to survive the randomly thrown kunai knives from enemy ninja and successfully passing them gives you a point. There will be obstacles that will block you from running past a certain spot and you need to go around it. There are also going to be “jewels” that if you collect you earn even more points than a single star passed. The player can slash or throw the knife at the enemy kunai knife to protect themselves.

Player Controls:

A – Move Left at an angle

D – Move Right at an angle

Mouse click – Throw Kunai (at direction of mouse)

Left Shift – Quick Dash

Selling Points:

- Infinite Runner

- Easy to learn and play

#IGB220

Asteroid - Postmortem

After finishing as much of this game as possible, it is quite hard to actually create the letters out of the blank spaces created by destorying the asteroids. Even if they were slightly connected it would take too long for the final few sections to be formed.

Additionally, there may be people who would enjoy a slow paced game. It would not be possible to have the asteroids spawn at rate that would make this game too fast because the player ship would keep colliding into the asteroids then lose and restart.

To stop the player from just sitting on the spot, the idea of having a life bar instead of actual lives was taken into consideration. The life bar would act as an enforcement of the player to move the ship around rather than sitting idly shooting asteroids. The player must also not shoot asteroids as it would be best to avoid making unnecessary blank spots that could kill them if they flew into it.

The life bar idea was that it would slowly slowly reduce if the player was not moving. However, not sure if this was possible to implement it was not put in. The player would gain life back by moving. However, this would break the idea of having damage from collision with asteroids unless the life bar was regenerated at a slow rate from flying around.

However, this element and the first original pitch ideas could potentially be implemented into future game design depending on how it goes.

Gameplay

After really trying to create a letter out of the blank spaces that are formed from destroying an asteroid, it took an extreme amount of patience and time to create a letter.

Additionally, this would take to long to create one letter being the objective of the game as the player would need to fly around avoiding the asteroid instead of destroying them as it would make it even harder for the player to move around if they destroyed them unnecessarily as the black void would kill the player.

Here is an image of an example of what it would look like to some extent:

#IGB220

Asteroid – Development Process

The first original name for this asteroid game was meant to be Wave Survistro. The aim of the game was a typical game of destroying asteroids, gaining points to buy upgrades for the ship to make the game easier with each upgrade. However, as each round or as time continues the waves of asteroids become hard to destroy and has different mechanics such as a homing asteroid that tracked the player down until it was destroyed or collided with the player.

Upgrades:

- Speed boost with longer boost timer upgrades and speed amount

- Ship’s general speed upgrade

- Shooting time and speed of bullet

- Armor that acts as more health to be able to sustain more damage

- And potentially more

However, this initial game pitch idea above was changed to the current design due to large amounts of confusion in being unable to make this game. Even with constant research and playing with GDevelop’s features it was too hard for me to personally make it.

The pitch idea was changed to suit my abilities of game making in GDevelop. With very little idea of how to make this game a little interesting without being able to include and have the game mechanics on the first pitch idea it was hard to brainstorm of something “unique”. Therefore, the idea pitch for Alpha-Timer was created.

Originally, for this pitch I was going to have no health included so the player can fly around without stressing about the constant flying of asteroids around the screen. However, after trying the game without the risk of dying there wasn’t much of a challenge in this game. Therefore, it was added so the player started with 30 lives and the largest asteroid’s collision damage is three and the smallest being one. In this game, the player must have patience as the asteroids fly in random directions around the screen. It may be a slow process of creating letters with small blank spaces but depending on the player they might enjoy the slow process of this.

#IGB220

Gdevelop - Asteroid Elevator Pitch

Title: Alpha-Timer

Pitch:

The aim of Alpha-Timer is to shoot the asteroids that spawn and pass by on the map that as it is destroyed it creates a blank space in which you need to form the given letter under the best time. The player can use a booster to get around the place to re orientate the ship for better position to create holes for the letter that is needed to be “drawn”. As long as the black spaces all connect no matter how weirdly shaped it is, it counts as drawn. If the player runs into too many asteroids, they lose. If the player flies into the blank space, the player loses and must restart.

Player Controls:

W – Move Forward

Mouse Moving – Navigating ship around

Spacebar – Burst forward

E – Pause All Movement stopping all force

Selling Points:

The ship would need to always fly around to reposition due to the movements of the asteroids as some could hit the player. This forces the player to move instead of standing in the one spot because the player can’t recklessly shoot the asteroids as it creates a random black spot that would potentially be in the way.

#elevator-pitch #igb220

Review: Week 3

Hello 😊 so I may have missed doing week 2’s review of the unit hahah

Anyways so, from the past two weeks of learning to create my first game using Gdevelop – Assief, was an interesting experience because I have very little experience with platformer games. Super Mario Bros. being the only platformer game I’ve played because platformers aren’t really the type of game, I enjoy playing more than many other genres of games. GDevelop was pretty confusing to use and still a little hard to get around to using since it’s completely new to me and still don’t know what can or cannot be done in the program.

There was a little struggling and mind blanking for thinking of an original platformer game in the moment to learn to make in GDevelop as the idea of Mario constantly popped into my head. The idea for Assief randomly popped into my head after seeing what sort of materials have been given to use for our first game pitch. There were some game mechanics I would have liked to have had in Assief but was unable to add them in due to lack of time and experience. Additionally, I am unsure if my ideas are unique and original to the game itself due to the deficient amount of experience with platform games.

#igb220

Gdevelop - Platformer Pitch

Title: Assief

Pitch: Character is an “assassin” or “thief” where they have jobs to assassinate their target or steal something from a location. (In this scenario, due to lack of skill and time I’ve had to change it to be really basic). They can jump up on blocks that are solid or can jump-through certain platforms. Collect coins that are placed around the map and kill the slimes to earn more points.

Stuff I wanted in this game but was unable to do:

In the event of having more time, experience, and research with Gdevelop the points would be used to buy items. However, the game is not highly developed to be able to do this yet. I also wanted to include “traps” that move around in a specific path to “kill” the character to protect the location of which you need to get to. Additionally, I also wanted there to be “watch towers” that look around with a beam of light and if you are exposed by that light you die (restart) the map. However, since these ideas were not input to this first game, there is a chance that with this I may have a chance to develop it into the next upcoming games.

Player Controls:

A – Move Left

D – Move Right

Space Bar – Jump

Selling Points:

I made two sections where the player had to continue jumping on top of the slimes to continue and complete the level otherwise, they would fall and need to restart. If the things I had been unable to input to the game was added, the game would be a little unique and different to other platformer games.

Below is an image of the level I created: The starting point is the bottom left and the end is the top right.

#elevator-pitch #igb220

About Me :)

Hello! My name is William, bear with me as I’ve never used Tumblr before and slowly get the hang of using it :) I am a first-year student currently studying Games Design at QUT. I unintentionally stumbled upon this course when looking for something to study and thought this would be quite interesting to do. I love playing games in general but also sometimes I see certain aspects in games that I think could be changed or concepts added that I play or watch YouTubers play for a more exciting and/or interesting experience. My aim for this unit is to learn more about the backend development of games to better understand the games industry world whilst gaining new experience and skills in game development. In the end, I seek to become a Game Designer for my own start-up company or work for a bigger and well-known company.

#aboutme #igb220

Trending Blogs

Recently Viewed Blogs

Game Design Blog