laughingcamelzz - Tumblr blog

[laughingcamelzz]

Assignment 3 Post-Mortem

The development of the final prototype of our game from the pitched original idea was smooth and a team effort. With everyone tasked with doing something else the development of the prototype went much faster than we initially expected. Basing the game off of my original platformer prototype we stayed pretty true to the concept I originally had and added more on top of it to make it a much more complete product. With my part in the team being responsible for level and sound design along with taking notes of playtests I experienced much through my first attempt at a group project.

When it came to designing the prototype, I was again tasked with doing level design and sound design. If I had to change anything about my work on the prototype the first thing I would do is add more levels. While 3 levels itself is good I believe adding more levels would benefit the overall playability and make the prototype more replayable this can also lead into making stages for the game with the player being able to explore different environments and even additional enemies and bosses. I would also go out and fix the current levels in the game to make them more polished by fixing platform designs, so they are a continuous platform instead of repeating platforms. This would go a long way with making the game look better. Along with adding new levels I would also add a tutorial level which would explain how the game itself functions and make the gameplay much easier for first time players.

When it came to playtesting there are some aspects about the playtesting and notetaking that I myself would change if I ever performed play testing session again. The first aspect I would change about the playtesting would be to implement a section where you would directly ask the play testers for feedback on every aspect of the game. This would allow for much more concise and easier to interpret information referring to the prototype. This would occur after the first and second playthrough of the game where at this point the play tester would be well equipped with the game and be able to identify what they think works and does not work in the game. This direct information would make changing the game for the better much easier as I would know exactly what factor and where the game is currently lacking.

Here are some screenshots of the final prototype:

[laughingcamelzz]

Assignment 3 Play-testing Post

After the completion of the final prototype for our game we ran five separate playtests to find out what if any issues our game presents when being played. The majority of the issues we actually came across were issues retaining to the intended design of the game. Mainly people had complaints that the prototype was a bit too hard. Some complaints were received multiple times whereas some were a one off where a player encountered an aspect of the game differently to the other play testers.

A major aspect players had issues with when playtesting our prototype were the enemies. The most prominently occurring issue referring to the enemies was the goblins and how they worked. The play testers when first encountering the goblins struggled to understand exactly how they worked and would often die repeatedly before understanding them. Intended to be killed by jumping on them when the are slow and going to the right many of the play testers would attempt to kill the goblins when they were fast and going to the left. The main complaint with this aspect was they were to fast going to the left. An easy fix for this would be to simply reduce the burst speed they have travelling to the left.

Another major issue play testers had when playing our game were pertaining to the hitboxes of all the sprites. It was determined that the hitboxes of the sprites were actually larger than the model. This resulted in players dying to enemies and traps without actually coming in contact with them. An easy and simple fix for this problem is just to reduce the size of the hitboxes on all the sprites to match the size of the model.

Traps were another major issue that players encountered during play testing. The traps were cited as being too well hidden and requiring extreme attention to find. As well the players are not introduced into what traps are rather having to encounter them and possibly taking damage to them to understand how they actually work. Not to mention of the play testers mistook the traps for trees and touched them. Another minor issue was that traps could be triggered from underneath which would be fixed by simply fixing hitboxes. As for the rest of the issues simply introducing the player to traps better would go a mile in making the game easier to play.

Coins and their placements were quite a minor issue but was brought up frequently during playtesting. The coin placement was slightly off the ground requiring you to jump to collect the coins rather than being able just to walk over them. As well some coins were placed in either really hard places to get or impossible places to get. This is one of the easier fixes requiring just changing coin placements in levels to fix. However, another issue pertaining to the coins was how little time you had to collect your coins after being hit. Increasing the time to collect the coins by a couple tenths of a second should fix this issue.

I-frames or invincibility frames were also cited as an issue in playtesting. It was said that the time period of invincibility was to short after being hit. This often resulted in the play testers being double hit and dying. The overall consensus from the play testers was that i-frames are an integral part of platforming games and that the time should be increased. Increasing the invincibility period by around 0.5 seconds should help solve this issue and ultimately make the game more user friendly and slightly easier to play.

Not all the feedback we received was negative though. Many aspects of our prototype were well received by the play testers. These aspects include the stomp mechanic and the ability to chain kills through it. The background music and sound effects being nice and fitting the game. The design choice of the game looking nice. The controls being easy to understand and many more.

[laughingcamelzz]

Assignment 3 Development Post

When choosing a game to continue our work on in prototyping as a group we decided to go with my platformer prototype known as Treasure rush. When splitting development duties for the group game project I was tasked with both level design and sound design. These two tasks each created their own problems during development that had to be figured out during development.

While the game originally only had one level in the very first instance of the prototype I went on and created two more levels (see bottom of post for levels) for the player to be able to traverse whilst collecting coins and killing enemies. I founded a major problem after creating the base of the levels. The chest at the end of the level would only teleport the player to a singular level and not all of them so when the player finishes the second level instead of moving on to the third you would instead be placed at the start of the second level creating and endless loop. To fix this I create a scene variable called “level” which scene value would change depending on what level the player was on. Level 1 being level = 0, level 2 being level = 1 and level 3 being level = 2. This allows the player to successfully teleport form the second level to the third level. Along with this I had to create multiple different versions of chest so that each chest would teleport a player to a different level since on chest can’t have all the scene values put into one. Another issue founded was when the player would be killed, they would teleport back to the start of level 1 no matter what level they were on. To fix this I again used the level scene variable this time to create a function that spawns the player at the level respective to the scene variable. This entailed me using the x and y positioning on the player to force spawn them at the begging of the level. Once hitting the chest at the end of level 3 the player would be taken to a placeholder victory screen signifying the end of the game. (the placeholder screen will be updated to the final victory screen created by another group member)

When it comes to sound design there were a lot less issues to be solved due to the innovations made in the level design section. The main changes that needed to be made to sound from the original prototype was volume leveling as in the original prototype the game volume was simply too loud. This was changed by reducing all sound in the prototype from 100% volume all the way down to 40% volume. This made a great difference in the sound department as the game was no longer attempting to deafen who ever played it. The second and final aspect of sound design that was needed was the introduction of different background music for the two new levels. The original sound track on the first level was called Retro Forest, the second levels music is called Land of 8 Bits and the third levels music is called 8 Bit Nostalgia and they can all be found on https://www.fesliyanstudios.com/royalty-free-music/downloads-c/8-bit-music/6. The game triggers which song It should playing by again identifying the value of level at the beginning of each stage.

Overall, the level design and sound design did create their own issues during the development of the final prototype but with mainly the use of a scene variable these issues were practically nullified and allowed the game to be in a state that makes it both playable and completable.

Screenshots of Levels:

Level 1:

Level 2:

Level 3:

Win screen placeholder:

[laughingcamelzz]

Racing Game Post-Mortem

The racing games original concept was a pretty simple and easily defined one so I don’t take any steps to overcomplicate it. Using the arrow keys to dodge the cars is more friendly to the consumer than using a and d as not all people play games often. No general issues were found with the control set up making it optimal to use throughout the entire project with no need for change.

If I had to redevelop the prototype, I would re-implement the cut time survive as a separate game mode. This allows for a different experience with a different goal and mindset for the player. In this instance the player would set a time they would like to survive and then dodge the oncoming traffic for said time before being greeted with a victory screen. I would also add in more settings to play on from the current grassy highway to a desert road, icy/snowy path, mountain path etc. These different settings will have different cars and obstacles from each other being functionally the same but visibly different.

If I had to change the design of the prototype, I would add two new obstacles to the road. The first would be an oil spill. This would make the car spin out and change lanes immediately. This alone would not destroy the car but instead make it likely that you will crash into another. The second would be a road closed sign. These would act similar to the other obstacles present before but will instead cover two lanes instead of one forcing you to drive to the other side of the road in order to avoid them. These would drastically change how the game would flow and make it somewhat more difficult.

Here is a screenshot of my racing game prototype:

[laughingcamelzz]

Racing Game Development Post

I again used Game Design Workshop by Tracy Fullerton chapters 2, 3 ,4 and 8 to identify what I wanted from my game design process.

For this game I did not download any other game asset packs as I used the sprite and assets we received in class for this game. However I did download a PNG of a pot hole from: https://www.pngall.com/hole-png/download/36991

Car:

Animations – The car should have a single static animation. While it does not actually have any animated features the oncoming obstacles will make it appear as if it’s going forward.

Car:

Behaviours – The car is the playable character of the game and can be controlled with the left key to move left and the right key to move right. When colliding with potholes or traffic it gets destroyed and creates an explosion signifying a game over

Traffic:

Animations – There are four different colours of cars that will appear on the road. They are all static.

Blue:

Gray:

Green:

Pink:

Behaviours – The Blue and Gray car drive in the same direction as the player so a slower speed is set for them to make it easy to overtake. The Green and Pink car drive the opposite of the player and drive faster so they can get past quicker. When colliding with the car they create an explosion.

Pothole:

Animations – the pothole has a single static animation. The pothole makes it look as though the highway has a hole in it.

Pothole:

Behaviours – The pothole will spawn randomly across any of the 4 lanes and come at the player at a slower speed due to them being driven towards and being static.

Highway:

Animations – The Highway is a long singular image of a highway. It fills the majority of the screen and is an extension to the background

Highway:

Behaviours – The highway does not have any coded behaviours but rather acts as a guide for the spawning of cars and potholes as well the player car is forced to stay within the yellow lines.

Trees:

Animations – The tree has a single static animation. This static animation contributes to making it look like everything else is moving.

Tree:

Behaviours – As stated the trees’ main purpose is to make everything else look like it is moving. They spawn frequently on both sides of the road.

Explosion:

Animations – The explosion is the only animated sprite in the entire game. It’s animation does not loop.

Explosion:

Behaviours – The explosions purpose is to spawn when either the car and traffic collide, or the car and a pothole collide. It doesn’t spawn anywhere else.

Background:

The background is a solid green colour.

Score:

When the game starts, the score is set to 0 and is increased according to how many obstacles are passed by the player with different obstacles giving different point levels.

Survive timer (Cut):

Originally the player was meant to survive a set time to win but this was cut in favour of an infinite game with a point system.

Sound Design: This game currently has no sound effects

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

[laughingcamelzz]

Game Direction and Elevator Pitch of Racing Game

 Today on my blog I will be talking about my third prototype which will be a racing game.

I will use the player centric approach once again as it seemed to work quite well last time. What do I want the main parts of my game that keep players playing to be this time around? The player will dodge cars and obstacles on road in order to last the time limit and win

The questions from the first IGB220 Lecture will be used again for the high concept statement.

What is your gameplay?

-          My gameplay is very reaction based and solely purposed on RNG spawn mechanics for oncoming obstacles and traffic.

Why will it be compelling?

-          The game focuses on the urge to get better and keep going. Beating the time being the final goal.

Who is the target audience?

-          There is no general target audience as it is a game that can be had fun with by many different ages but more likely it will be considered 6 and up due to difficulty.

What is the players role?

-          The player will take on the of a car racing in oncoming traffic dodging cars and obstacles such as pot holes and puddles.

How will you motivate the player? How will you reward them?

-         Finish line screen.

What genre is the game?

-          Top down racing game

What is the setting of the game?

-          The game is set on a crowded highway which is badly damaged resulting in many obstacles.

The elevator pitch for my racing game goes as followed:

“In street racer you find yourself on the road racing against other road outlaws putting the pedal to the metal in order to be crowned king of the road. You will have to dodge oncoming traffic and many different road hazards in order to make it to the line. Survive the time limit long enough and you will be crowned king of the road.”

The game will be rated G due it being just a racing game with no violence. The target audience is 6 and up due to this being a more difficult game.

Concept Art:

In my next post I will again be in GDevelop developing this idea into a playable prototype.

Google Images: Racing. Retrieved from: https://www.google.com/search?q=racing%20game%20concept%20art&tbm=isch&tbs=il:cl&client=opera-gx&hs=7km&hl=en-GB&sa=X&ved=0CAAQ1vwEahcKEwigt-76-4TzAhUAAAAAHQAAAAAQAg&biw=1651&bih=819#imgrc=om_oUGsoP9cfwM

  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

[laughingcamelzz]

Asteroids Game Post-Mortem

The asteroid game concept was already simple to play so I didn’t over-complicate it. The movement being just moving the mouse makes playing the game a lot easier. The shooting being bound to the left mouse key also makes it easier for those playing the game as they don’t have to use their keyboard at all when playing. An issue when the ship would touch the mouse was found and was fixed by making the ship stop once it touches the mouse cursor.

If I had to redevelop the prototype, I would implement the various cut animations. The main one included being the ship falling into multiple different pieces before being re-spawned with a current invincibility effect. I would also attempt to fix and re-implement the quad shot power up. I would try to individual align the cannon trajectory instead of doing them all together. I would also make it that large asteroids split into two medium asteroids and medium asteroids split into two small asteroids. I would also add a high score screen in the game over section along with the score reached last game.

If I had to change the design of the prototype, I would add two new expandable aspects. I would include alien spaceships into the game. These alien ships would come in various different shapes and would have a varying amount of health depending on what ship they are. These alien ships would also do a varying amount of damage to the players as well. This leads into the second thing I would add which is player ship health. This way when a player comes in contact with an asteroid, they will lose health instead of a live making the game go on for longer. The set health of a player per life will be 100.

Here are two screenshots of my asteroids game prototype:

Playing Game:

Game Over:

[laughingcamelzz]

Asteroids Game Development Post

I again used Game Design Workshop by Tracy Fullerton chapters 2, 3 ,4 and 8 to identify what I wanted from my game design process.

For this game I did not download any other game asset packs as I used the sprite and assets we received in class for this game. However, the background I used in my game can be found through this link https://gamespawnchris.artstation.com/projects/qA8yAL to a free use art station.

Ship:

Animations – The ship should have a single static animation for when flying. A death animation was planned but was ultimately scrapped due to an issue with the game over screen.

Ship:

Behaviours – The ship is the playable character and follows the mouse of the user. Left clicking will shoot a bullet and when coming into collisions with an asteroid of any form the ship will lose a live/s. The ship can also collide with power ups to collect them.

Bullet:

Animations – The bullet has a single animation. No other animation was planned for the bullet.

Bullet:

Behaviours – Bullets are shot out of the front of the ship. When colliding with an asteroid they destroy them and increase the players score by an adjusted amount. The bullet sits at a steady fire rate but can be changed through the collection of power ups.

Asteroids:

Animations – There are three different variations of asteroid: Large, Medium and Small. Each variation has three different animations. Explosions to signify the destruction of an asteroid was planned but scrapped due to it not matching the game.

LargeAsteroid1:

LargeAsteroid2:

LargeAsteroid3:

MediumAsteroid1:

MediumAsteroid2:

MediumAsteroid3:

SmallAsteroid1:

SmallAsteroid2:

SmallAsteroid3:

Behaviours – The different types of asteroids are not cosmetic they have different effects. The large asteroid will take two lives away from the player and gives 500 score when destroyed. The medium asteroid takes 1 live away from the player and gives 250 score when destroyed. The small asteroid also takes 1 live away from the player but only gives 100 score when destroyed. They spawn in at random and bounce around the screen until they are destroyed.

Powerups:

Animations – There were planned two powerups: Rapid Fire and Quad Shot. However, the Quad Shot powerup was cut from the game due to issues with bullet trajectory.

RapidFire:

QuadShot (Cut):

Behaviours – The rapid-fire power up increases the fire rate of the ships cannon for 5 seconds whereas the quad shot was intended to have a bullet shoot from each side of the ship but would only shoot out the front resulting in it being cut.

Background:

The background is an image of deep space.

Lives: When the game starts you are set with 10 lives and lose them when colliding into asteroids. Once on 0 or less lives the player will go to the game over screen.

Score: When the game starts the score is set to 0 and is increased according to what asteroids are destroyed and how many.

Sound Design: There was originally background music in game but was later cut due to music not fitting in the game well enough.

All sound effects used in this game were provided in class.

Explosion – Plays when asteroid is destroyed.

Laser_Shoot – Plays when bullet is shot.

thruster – Plays when ship is moving.

Thruster_down – Plays when the ship is idle.

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

[laughingcamelzz]

Game Direction and Elevator Pitch of Asteroid Game

High there back again with another game dev update, Today I will be talking about my second prototype which will be an asteroids game.

I will use the player centric approach once again as it seemed to work quite well last time. What do I want the main parts of my game that keep players playing to be this time around? The player will be tasked with destroying and dodging asteroids with the help of power ups.

The questions from the first IGB220 Lecture will be used again for the high concept statement.

What is your gameplay?

-          My gameplay is that of a classic shoot-em-up the relies heavily on the players reaction time and the constant use of power ups.

Why will it be compelling?

-          The game focuses primarily on addictiveness where you want to keep goin and playing the game in order to get a high score.

Who is the target audience?

-          There is no general target audience as it is a game that can be had fun with by many different ages but more likely it will be considered 6 and up due to difficulty.

What is the players role?

-          The player will take on the role of a spaceship pilot stuck deep in an asteroid field with the only goal being to survive.

How will you motivate the player? How will you reward them?

-         High-Score system.

What genre is the game?

-          Shoot-em-up

What is the setting of the game?

-          The game is set in deep space in an asteroid field where asteroids of varying size will fly in and out as well as the appearance of power ups.

The elevator pitch for my asteroid game goes as followed:

“In Asteroids Assault you the player find yourself disconnected from your space fleet and out in the middle of open space. However, you notice something large on your radar, an asteroid, then another asteroid, then another. You are not in open space you are in an asteroid belt. In Asteroid Assault with the help of powerups you will destroy all incoming asteroids until your fleet can reach you.”

The game will be rated G due to there being no real forms of harsh violence. The target audience is 6 and up due to this being a more difficult game.

Concept Art:

In my next post I will again be in GDevelop developing this idea into a playable prototype.

Google Images: Asteroids. Retrieved from: https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.flickr.com%2Fphotos%2Fvintage_illustration%2F31424791047&psig=AOvVaw2G5d2BD_WCl2QYOSXmmnLn&ust=1631631411754000&source=images&cd=vfe&ved=0CAkQjRxqFwoTCNjDzuya_PICFQAAAAAdAAAAABAS

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

[laughingcamelzz]

Platformer Postmortem

Since players would be unfamiliar with my game, I made sure the base game was simple and easy to understand and could be played easily without information. The linear design of the stage made it easy for the play testers to reach the end of the stage. The movement being left, and right arrows makes the button mapping easy for someone playing it. The level was redesigned to be horizontal based over vertical after an exploit to reach the finish without playing the level was found by one of the play testers.

If I had to redevelop the prototype, I would implement more animations for each character and try and fix the issues that prevented me from implementing various animations and other features entirely. For example, the player would have a death animation play before being respawned at the start of the level I would also consider adding further ambience into the game such as background noise that would be heard in a jungle like birds chirping, leaves rustling and raindrops falling off the tops of leaves. I would also add different music for different areas of the game. For example, keep the much more adventure-esque and calm music already in the game for the above ground and then add in a much darker music fitting of the setting. As well I would create different stages that can be accessed by completing a current stage with different level themes. For example, one is completely above ground and the other is completely underground. This would also mean that the backdrop would change accordingly to the setting of the level.

If I had to change the design of the prototype there would be various aspects I would add/change. The first thing that I would add would be multiple stages. Once the chest at the end of the stage would be reached and the treasure would be “obtained” the player will be teleported to a different stage and come in contact with an invisible object which starts to play new music. The second feature I would add would be ranged combat. This would be implemented to make the combat system more interesting then just jump on an enemy to kill them. This also leads into my next feature to add being boss enemies. Boss enemy combat will be entirely different from regular combat and be more of a dodge and shoot system where the boss will shoot projectiles and the player is to dodge them and then shoot back to kill the enemy after a certain number of hits. The only already in the game feature I would change would be the enemies I would change their attack system to a more advanced one then just walking into a player, whether that be by adding projectile based enemies or improving already implemented enemies.

Here are two screenshots of my platformer prototype:

The above ground:

The below ground + finish:

[laughingcamelzz]

Development of Platformer in Gdevelop 5

Game Design Workshop by Tracy Fullerton chapters 2, 3 ,4 and 8 helped me identify what I wanted from my design process.

I have found a suitable asset pack to be used in my platformer game as it contains all the sprites I need for my game including players, enemies, platforms, items and a fitting backdrop. This pack is labelled the PIXEL ART METROIDVANIA ASSET PACK and can be found through this link: https://o-lobster.itch.io/platformmetroidvania-pixel-art-asset-pack

Hero:

Animations - I feel as though the Hero should have animations for being idle, running, jumping and falling. A death animation was planned but ultimately scrapped due to the respawn system clashing with it.

Hero Animation Set:

Idle:

Running:

Jumping:

Falling:

Behaviours – The Hero is the playable character and as such is controlled using arrow keys to move left and right and spacebar to jump. When falling on top of enemies the Hero will kill the enemy and jump again however if the player is not falling and come in contact with an enemy they will die and be respawned at the start position. If the Hero falls past y1000 they will die and respawn at the start position. The Hero is also the only asset with the ability to collect coins and open the end goal chest.

Enemies:

Animations – For both enemies they only have a singular walking/running animation. They did have a planned death animation but issues with the way they are killed prevented it from being implemented.

Enemies Animation Set:

Enemy1 (Slime):

Enemy2 (Goblin):

Behaviours – as stated before the enemies only serve as obstacles for the Hero either being killed by them or killing them. However, to prevent enemies from walking of platforms and floating in the air invisible barriers should be made to change the enemy’s direction. The following images could be used to identify left and right barriers.

Coin:

Animations – Coins have a single animation with no other animations planned.

Coin Animation Set:

Coin:

Behaviours – The coin acts as a collectible for the Hero and serves no purpose other than to be picked up. Coins can only be picked up by the Hero and when collected will produce a noise.

Chest:

Animations – The Chest has two animations one when it has not been open with a reflective shine pulsating across it to emphasise to the player that they can interact with it and an animation of the chest opening after the Hero touches it.

Chest Animation Set:

Unopened:

Opening:

Behaviours – The Chest is always situated at the end of the level and can only be activated by the Hero. When activated the background music will stop, the chest will open, and a positive sounding jingle will play signifying the end of the game.

Platforms:

The platforms in the game are used to split up the game area into two parts above ground and below ground with the above ground terrain being the ones with green grass and the below ground being a darker soil-esque material. The above ground is where the slime enemies reside, and the below ground is where the goblin enemies reside.

Background:

The background is a tile of repeating trees showing that the game is in fact located deep within a jungle.

Sound Design:

Background Music:

The background music used is called Retro Forrest and can be found on https://www.fesliyanstudios.com/royalty-free-music/downloads-c/8-bit-music/6

Sound Effects:

All sound effects in this game can be found on https://freesound.org/people/LittleRobotSoundFactory/packs/16681/?page=1#sound

Jump (Jump_03.wav) – plays when the Hero jumps

death (Hero_Death_00.wav) – plays when the Hero dies

enemydead (Explosion_02.wav) – plays when Hero kills an enemy

coin (Collect_Point_01.wav) – plays when Hero picks up a coin

chestopenwin (Jingle_Win_01.wav) – plays when Hero comes in contact with chest

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

[laughingcamelzz]

Game Direction and Elevator Pitch of Platformer

The first prototype I will be making for IGB220 making is a platformer. Considering what I want from my game would go a good mile in helping me make my elevator pitch and prototype.

Player centric experience is a good process to use when creating a game as it helps identify what players will want. The first step in the process of player centric experience is setting up player experience goals. What do I want the main parts of my game that keep players playing to be? In my case players will be tasked with killing enemies, collecting coins, making jumps, and reaching end goals. Focusing on fluent movement is also important so the game feels somewhat natural.

The first IGB220 Lecture outlined a set of questions which help identify varying aspects of the game. This is known as a high concept statement.

What is your gameplay?

-          My gameplay will focus on timing jumps to clear gaps, kill enemies and grab coins. This means the gameplay also heavily focuses on physics.

Why will it be compelling?

-          The game focuses primarily on the players ability to move and coincides with the other features in the game such as killing enemies and grabbing collectibles.

Who is the target audience?

-          The target audience is around the same as many other 2D platformers such as Super Mario, so the target audience is people aged 6 and up.

What is the players role?

-          The player will take on the role of the hero and is tasked with killing enemies, collecting coins, and ultimately reaching the treasure at the end of the level.

How will you motivate the player? How will you reward them?

-          Sound effects, background music, coins, and end goals for players to reach.

What genre is the game?

-          Action-Adventure/Platformer

What is the setting of the game?

-          The game is set in a deep forest where you the player hears there is bucketloads of treasure. However, you the player has to combat varying enemies in order to reach the treasure.

An elevator pitch is a three-sentence (or 30 second) long statement that tells someone the basics of the game, and why they should give you money to develop it. My elevator pitch goes as followed:

“Treasure Rush is an action-adventure platformer game where players must traverse through jungle terrain on the search to find the treasure of a long-lost civilisation, or so people thought. The original owners of the treasure will not give it up without a fight so players must fight their way through hoards of enemies in order to reach the treasure. In Treasure Rush players will utilise movement to kill enemies, collect items and traverse the harsh jungle.”

The game will be rated PG due to mild violence. The target audience is 6 and up due to mild violence and mature themes.

Concept Art:

In my next post I will be using GDevelop to begin developing the idea into a prototype stay tuned!

Google Images: Deep Jungle. Retrieved from: https://www.google.com/search?q=jungle%20concept%20art&tbm=isch&tbs=il:cl&client=opera-gx&hs=7Al&hl=en-GB&sa=X&ved=0CAAQ1vwEahcKEwjY9ov51sjyAhUAAAAAHQAAAAAQCA&biw=1864&bih=939#imgrc=kGXSBTYyIBBVQM

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

[laughingcamelzz]

Introduction

Welcome to my blog for IGB220. Here I will update you on the progress of my game development journey. My development of games will be shown here along with my progress along the unit. Varying posts will be made about my creations in there beta versions along with my final main game.