n10808515

[n10808515]

Week 13: Assignment 3 Post-mortem

The development of the Karen slayer was a lot more rewarding than the other games that I had made. I’m not one hundred percent sure what was particularly more appealing about the creation of the Karen Slayer, but I personally felt that it went a lot smoother. Maybe it was the extended period we had to work on the game, the extra play testing that we got to do as a group, the accumulation of game making experience over the semester or just the fact that it was in a group. What ever it was, I felt a lot happier with the end prototype for this game than any of the other games that I had made.

The team that I worked with had great communication and each member brought something unique to the table. For example, one of our members who created most of the assets was good at art which allowed me to implement more features into the game. By having someone designated to the design of the game not only was the art style more consistent but the other members were able to focus more on structuring the level design and the coding of the objects.

One downside about working in a team was that the GDevelop software that we were using was very friendly when it came to group work. We were not able to work on one game at the same time, we had to instead keep sharing an updated model between ourselves during our weekly meetings. This became especially tedious when the size of the game became bigger than the share limit for simple online file sharing platforms which meant we had to use USBs to distribute the contents that we had been working on.

With the group there was also a lot more perspectives and ideas on where to take the game after the prototype developments. As seen in the updated one page there were many directions that we wanted to take the game to such as implementing new flying enemy types and a boss level. If the game was to be worked on further, we would be able to implement a lot of the ideas in our original scope that didn’t make it into the final prototype.

In conclusion, I had a lot of fun on this journey through game design and I feel that this final game is a good testament to all that I have learnt and brought to the subject. I had a lot of fun creating all the games and game development in general allowed me to express a lot of ideas that I’ve wanted to see implemented into games. With this being the final blog post I just wanted to say thank you for reading

[n10808515]

Week 12: Assignment 3: Iteration and changes

Weekly Meeting:

-       In this week’s meeting we discussed and implemented:

-       The implementation of a visual and auditory indicators for damage of the player

-       Visual / auditory indication for the death of Karen enemies

-       Visual and auditory indicator for the players death

-       End flag transition to the next stage

-       Introduction screen where the player can choose to play or exit the game

Additions and Changes based on Playtesting Notes

Sword

The sword attack in our game received the majority of commentary from our play testers, and from the findings of the playtests, a number of changes and improvements have been devised.  

One issue that will be addressed was the dissatisfaction some of our play testers had with the quality of the sound effects tied to the sword. Some additional and more “fitting” sound effects will be sourced and implemented in order to reduce the rate at which the sound effects become repetitive and irritating to players, as well as improve the immersion with the game by using more appropriate sound effects which match the visuals of the sword. 

Another significant change to the sword will be balance changes. By listening to some suggestions made by our players, we have concluded that instead of the player having consistent access to the sword, it will act as a temporary powerup that the player can collect and use to progress through the levels of the game more easily. This should hopefully eliminate the balance issues our players encountered while using the sword, whilst also not eliminating the sword's presence in the game completely, resulting in an overall more challenging less simple experience. (Sword made the game too easy) 

 Content

The issues we had with our amount of content was somewhat expected, as we went into the playtesting session with simply a tutorial level and a single enemy type.

We are planning to make it so each level will have its own theme and style, but if the game were to ever be fully completed, each of these themes and styles would act as a full act of the final game Additionally, a boss level will be implemented at the conclusion of the additional playable levels. These changes should pat out the existing void in progression and challenge variation in our game. 

In addition to more levels, additional enemy variants will be added in order to give the player a bit of a variety in experience. As previously stated, a boss creature will be added, as well as some different variants of the normal enemies, such as a flying Karen, a ranged attack Karen or a Drop-Karen that drops down when the player goes underneath them.

The final content addition that we will look at implementing is additional player attacks that can act as temporary upgrades that came be found around the level. Making upgrades temporary will solve the issue of attacks like the sword making the game too easy. By making the sword and any other future upgrades temporary the game becomes a lot more difficult meaning the player is required to jump on the enemies which is more dangerous.

Some of our play testers found that a punch attack or an eye-beam attack was what they expected when they saw our player character sprite. Fortunately, some other play testers suggested that we add additional attacks, so why not make the attacks that others expected and wanted to see a reality. The eye beam would act as a ranged attack, whereas the punch would act as the baseline melee strike, since the sword is being repurposed as a powerup. Due to the nature of our game, the eye beam would also likely be a pickup, due to the general hard-to-balance nature of ranged attacks in GDevelop. 

[n10808515]

Week 11: Assignment 3 Playtesting

First Meeting:

What was developed:

-       Basic sword motion

-       Editing collision point to match the animation of the sword

-       Add a point on the player model where the sword can be held

Tutorial level:

-       What keys need to be told to the player and what is common sense

-       What obstacles act

-       Having the low roof so the player is encouraged to use the sword (can’t jump on the enemy)

Other notes:

-       Considering accessibility by having right-handed and left-handed controls

-       Need to swap the sword swing code from a changing angle to an animation with changing hitboxes

-       Need to decide what buttons are associated with what action

-       Need to start considering sound

-       Need to have store manager sprite

Play Testing Notes:

In order to improve our game we had numerous people play test so we could get multiple perspectives on our game. Due to the playtesting sessions happening in lectures a lot of participants were young adults that were 18+ years old. Most of the participants players over 15 hours of games per week meaning that they were experienced and familiar with core mechanics across games.

Play Tester 1:

-       Naïve player, hasn’t play tested before

-       Enjoys the background music

-       Enjoys the layout of the title screen, simple but effective

-       Animations are smooth

-       Good instruction for controls, very helpful

-       Already knew to jump on enemy

-       Ignores the 2nd group of Karens first time round

-       Knows to pick up the coins

-       Sword is too pixeled

-       “Is that it” (tutorial level may be too short, increase the length of other levels)

-       Didn’t initially know by instinct that he could jump through platforms (change design)

-       Likes the background

-       Sword makes the game too easy, removes any challenge

-       Having the sword as a temporary power up

-       Respawn system for the enemies

-       Enjoys the level design

-       Hasn’t taken damage the entire playtest (not challenging enough, boring)

-       Background moves is player is running into a wall

-       Likes the fading coins when picked up

-       Death screen for restart

-       Sword swings when you are dead

-       Wanted a force restart feature

-       Different Karen types (confused by different sized Karens not doing different things)

Play tester 2:

-       No trouble understanding intro screen

-       Didn’t know what the melee ability button was (not natural)

-       Controls for movement feel fine

-       Playing with 1 hand

-       Pick up sound for coins

-       Animation to make coins seem like collectables

-       Animation for sword feels a bit slow

-       Rather enter to be attack (called return)

-       Visual indicator to show that you have taken damage

-       Have more than just one enemy

-       Enjoyed the parallax scrolling of background

-       Wanted more content

-       Character looks like he wants to punch

-       Can just spam the sword (takes away difficulty)

-       Every instruction should be present at the front of the tutorial so they can play with all features throughout the whole level like a sandbox

-       No replay value outside of getting a higher score

-       Sword sound effect got repetitive after a couple of times

-       End flag should have a better visual than a cactus in terms of indicating the end of a level

Play Tester 3:

-       Likes the games intro screen already

-       Likes instruction

-       Feels like she can shoot robot lasers

-       Knows to jump on head

-       Thinks the bigger karens are different

-       Wants particle effects

-       Tried to jump on clouds in background

-       Tries to kill bigger karens once she knows about the sword

-       Wanted to know about the sword at the beginning of the stage

-       Jump seems very floaty (increase gravity, shorter jump, quicker fall?)

Play tester 4:

-       Loving the menu

-       Recognizes it as a tutorial

-       Basic type keys make sense

-       Parallax camera has a bit of a jiggle

-       No specific jump animation

-       Tried to run over smaller karen

-       Didn’t recognize the jump through platforms

-       No score bonus for killing karens

-       Collision of the ledges of platforms

-       No split functionality for arrow keys

-       Didn’t recognise the end flag

-       Has no benefit to killing karens, just ignored them

-       Cave backdrop instead of background

-       Didn’t see the end flag at all

-       Camera clips down when character dies

-       Can swing sword when character is dead

-       Would like to see more platforming challenges and longer levels

-       The gravity of the levels makes the platforming

-       No benefits to jumping on heads once you know the sword exists

-       Can jump on karens even with low roof

-       Can spin blade around when swinging to make pseudo invincible  

-       Music in contrast with other design elements

-       Very gritty sword animation and visual

Play tester 5

-       Menu is clear

-       Likes the art style

-       Doesn’t like the screen shaking

-       Enemies easily die

-       No instruction to say that you can jump on them

-       No reason for collecting the coins

-       Cactus is an odd end flag

-       No reason to be down with the 2nd group of karens

-       No damage indicator

-       Can walk through the karens

-       No death screens

-       Only took damage from one karen when multiple hitboxes were on him

-       Ranged enemies, throwing something

-       Music is getting repetitive

-       No reason to go backwards

-       Wants larger groups of enemies

-       Menu shows the characters

-       More attacks of some sort, different abilities

-       More detail in character

-       More enemy variation

-       Sword sound effect seemed off

-       Got repetitive

-       Didn’t find a reason to get coins or get score

Using these notes, we were able to create a matrix that allowed us to see any glaring issues that were faced by multiple play testers during the sessions. From this we can make more effective improvements to our game.

[n10808515]

Week 10: Assignment 3 Development Progress

Elevator pitch: In this 2d platformer you take on the role of the Karenator. A cybernetically enhanced super soldier trained for the sole purpose of taking Karens down. You must battle your way through hordes of angry Karens and jump your way through various parkour elements in order to rescue the missing store managers and return them to safety. Throughout your quest you will come across power boosts that will temporarily give you God-like abilities. These abilities will give you the much-needed upper hand when fighting against the determined Karens!

Karen Slayer One sheet:

Brainstorming:

More levels:

- Mario level progression

- Shopping center (boss: KAREN SWARM)

- Suburbs ( boss: Steroids Karen cant be hit by ranged attacks)

- City ( boss: Karen Kong)

- Hell (boss: karen satan)

Sound effects:

- Karen death noise and animations

- Noise for when they hit you

Multiple Enemy types:

- Flying Karen (Whirling handbag helicopter blade)

- Ranged Karen (Throws children or high heels or yelling)

Power Ups:

- Mask launcher (Making the character have a ranged attack)

- Shield

Minimal viable product (MVP)

In order to create our minimal viable product (MVP), we are going to focus on implementing the key design elements that will engage our audience. Firstly, we will structure a base level design with a tutorial to introduce the player to mechanics, 3 base stages and a final boss at end the end of the area. The 3 stages and final boss will become a set area format for proceeding areas. Each base level will be concluded by rescuing a store employee who rewards them with coins to show that the player had completed the level. When defeating the area boss the player will rescue a store manager with a different graphic design to signify a greater achievement who rewards the player with more coins. Each employee saved will populate the store where you can purchase upgrades, each store manager saved will allow access to new upgrades.

The first stage being the tutorial will introduce the base mechanics of the game and conclude with you saving a store clerk. The store clerk will appear at the start of each stage and will allow you to buy upgrades using coins. Coins are collectables that can be gathered in levels by walking into them and by defeating Karens. Players can also obtain coins at the end of the level from employees that they save.

In the minimal viable product, we will have one enemy type and one boss. The enemy will be a standard Karen which will have a damage and death noise and animation. The Karen will not have any AI and will just walk between 2 fixed points. The boss will be a larger version of the standard Karen that will jump randomly and have more health.

The player mechanics will include running, jumping and a sword that the player can swing in a downwards arc to damage Karens. The player will be able to progress the stage with standard movement and jumping and fend off Karens by either hitting them with their sword or jumping on them.

Level Design Boards:

For the creation of our levels, we had some general design boards created to story board the level and area progression of the game:

[n10808515]

Week 9:

Background Colour:

After the level is started the background colour will change every 1.5 seconds. The colour changes randomly between red, green, and blue.

Blockade:

Blockades cover a random portion of the screen. A blockade can be red, green, blue, or grey. Initially, every 2 seconds a blockade will spawn. The colour of the blockade that is spawned is based on the colour of the background when that blockade spawns. Each blockade has a chance to be a grey blockade which is smaller than normal blockades however, they cannot be destroyed and have to be avoided.

Lives count:

                                      You start the level with 3 lives. Running into a barrier that is a different colour to your car will cause you to lose 1 life and reduces your speed. Having your speed reduced allows the Universe Devouring Worm to catch up. If the player touches the Universe Devouring worm, they instantly lose all remaining lives. Losing all your lives causes you to die meaning that you need to restart the level.

Points System:

Every time you destroy a barrier you gain 100 + 10 points per barriers destroy consecutively. Passively gain 10 points every second you are alive.

-       Introductory instructions at the start. Preventing the game from starting (colours changing/ barriers spawning)

 Rainbow Racer Sell Sheet

Rainbow Racer One Sheet

Rainbow Racer Post-mortem

The development process of Rainbow Racer didn’t go as smooth as the development for Dead Eye. This was mainly because a lot of the design elements from the original elevator pitch were more complicated to implemented than I originally thought when fleshing out the design. As a result, I had a less clear idea to base my game off and which made the development of the game less coherent and decisive.

My process when developing Rainbow Racer was to focus more on the aesthetic design of the game. I wanted to make the game be more visually appealing and have a higher graphic quality. However, this task was still difficult because of the clashing quality of the assets that I was provided.

Importance of having available assets in terms of making and developing games as a lot of my features that I wanted to implement were limited by asset and design limitations. As someone with little design experience, it would take a long time to make create assets that are aesthetic and suitable to the overall design to the game.

In terms of gameplay design, I would’ve like there to be more substance to the game like what was described in the elevator pitch. Compiling all of these features together however became difficult and messy without proper art direction to make everything fit the space/ driving aesthetic.

With the current gameplay I did get to experiment with the collision rule. Usually in the other games a collision with an object resulted in it being deleted with unique circumstances. In the Rainbow Racer game, I wanted to add a more visual effect to the collisions, so I added an explosion affect that only took place when you were damaged. I believe that having these extra visual features makes the gameplay seem more streamline and as a result more enjoyable to play.

[n10808515]

Week 8: Racing game Development Post

Changing car sprite

In terms of keeping up consistent with the main gameplay feature of rainbow racer the first element I needed to program was the colour changing mechanic for the player-controlled car. I had a few ideas on how I wanted to implement the mechanic in terms of buttons and visual design such as:

Having a button to rotate through multiple different colours

Allows for there to be less required buttons to accommodate a larger range of colours. However, having to repeatedly click a button quickly and having to remember the set pattern for the colours might get tedious and frustrating.

Having a unique button to associated to a certain car colour

Easily access each of the potential colours that the car can turn into. Limits the number of colours as having too many keys would make the game too complicated.

Having the colour change be automatic and based on a timer

Adding an element of random number generator (RNG) to the game which has both positives and negatives. RNG can make each run of Rainbow Racer more unique and as a result more engaging. However, RNG could also make the game more frustrating by removing the players control over the colour of their car.

In the development I decided to go with the second option as having as I was originally going to have a maximum of 3 colours which can be easily fitted to 3 keys. As a result, I assigned a unique colour to the left, up and right arrow keys allowing the player to rest both of their hands comfortably on either side of the keyboard.

Rotation and movement of the car

The movement of the car when going left and right consisted of 2 motions. Firstly, was the displacement along the x axis which was dictated by using Gdevelop’s “top-down movement” object template. By binding the ‘a’ and ‘d’ key to left and right respectively we can create simple top-down object movement for the car. The second part of the motion of the car was rotating the angle of the car towards 30 or -30 degrees based on whether the car was moving left or right respectively. The car was given angular moment towards these angles at a rate of 60 degrees per second. As a result, the cars movement appears more fluent and cohesive when moving around the stage.

Generating the barriers

The barriers in rainbow racer act as the obstacle to prevent the player from getting further into the game and achieving a higher score. The barriers spawn at a constant rate and can be 3 different colours that match the 3 different colours that the car can change into. This visual design gives the player a hint towards how to gain points in Rainbow Racer. In order to gain points, the player must collide with a barrier of the same colour as their current car colour.

In order to generate the obstacles in the game I created a simple white rectangle object that spawns on a timer. By making the object white it allowed me to easily tint the colour of the object when they spawn.

In order to match the colour changing theme of the player-controlled car I wanted to have the background change colour. Making the background change colour will act as the indicator as to what colour blockades will be spawning. Therefore, in order to have the game not be stagnant and repetitive I would need to make the blockade spawn timer and colour changing timer different lengths.

Rainbow Racer Playtesting Notes:

Play tester 1:

-       Implementing progression (faster spawn rates and colour changing rates). Maybe result in a level system

-       Instructions to tell the player controls

-       Maximum and minimum x values to stop the player from going off screen

-       Able to go along the y axis

-       Different barrier types other than the colours such as a barrier that can has to be avoided

-       Enjoyed the spawn rate of barriers

Player tester 2:

-       Found the pace slow. Maybe implement a way to speed up the car

-       More obstacles

-       Key for instructions

-       Limit x movement

-       More clearly visually indicate that you can through barriers of the same colour by making the blockade more faded or cracked. As a result, the player can see that the barrier can be broken or drove through

-       Make the blockades spawn closer to the centre so they take up more room

Design Notes:

-       Background feels out of place

-       Car in space doesn’t make sense (maybe make it a spaceship)

-       Change the design of the road

Assignment 2 progress

At the current moment I have finished designing the sell sheet for the rainbow racer

game but not filled out any of the information. The idea behind rainbow racer has changed a bit since the initial elevator pitch.

Notes on Assignment 2 progress

-       Likes the design and the layout of the sprites

-       Merges elements from the sell sheet and the one page. Redesign into one or the other

Need to worry about more important information on the sell sheet.

[n10808515]

Week 7: Racing Game

Asteroid’s post-mortemRacing Game Elevator Pitch

Rainbow racer:

You play as a racer who is trying to escape the star devourer in his all-terrain space car. In order to escape the star devourer, the racer must match the colour of the car to the environments by changing the space car’s colour to match the area around it. When matching the terrain colour to the car colour the car will move at a much faster pace allowing the player to escape the star devourer more easily.

Gameplay:

The player will drive along a colour changing track and must change the colour of the space car to match the track to move at a suitable speed. There are 3 colours that the player can rotate through, red, blue and green. As a result, the race can reach the star gate and temporarily escape the star devourer progressing the player to the next level. As the game progresses the colour of the track will change more frequently, and more obstacles will appear to halt the acceleration of the space car.

The camera pans upward at a speed relative to the velocity of the space car. The player can manoeuvre around the screen using w, a, s, d and use the left arrow, up arrow and right arrow keys to select the car’s colour.

Unique Selling points:

-         Mixes mouse, frog, lizard racing games with temple run features.

-         Has a low skill floor but high skill ceiling with its easy gameplay mechanic

Asteroid’s post-mortem

The development process of Dead Eye went a lot smoother than the development of the platformer game prototype. When developing the features of the game I had a clearer idea of what I wanted to implement and how I was going to implement it. The combo feature of Dead Eye which was the main selling point of the game and I believe that I implemented it better in the overall design of the game. The combo feature was able to be gelled better with the overall gameplay of the Asteroids template that the game was based off.

My process when creating Dead Eye had a greater focus on being iterative and encompassing the feedback that was received during the play testing phase. My initial plan was to increment the two unique selling points of Dead Eye in two separate development phases in order to have time to review how the iteration affected the games flow and play. I felt that this gave me a lot more time to decide how I wanted to implement the combo feature and as a result I could make the game more streamline.

If I was to change a gameplay feature in Dead Eye I would expand on the combo feature to include a scoring system. By implementing a permanent score system, the player will have a greater goal for to strive for rather than just destroying asteroids. The scoring system would allow players to compare their highest combo towards their local friends. This could be further iterated to include a regional leader board which could act as a gateway into multiplayer play.

In order to increase the fiero of the game I would implement an increasing spawn rate based on the duration of the level. As a result, the player would be required to keep up a high combo in order to manage the larger waves. The increasing difficult would make missing a bullet potentially fatal but also makes recovering from an error easier as the player gets more use to the physics. Another way to increase fiero could be to expand on the upgrade given at a certain combo threshold. Making more rewards of facility for the player will help increase engagement by filling the screen with asteroid destruction.

[n10808515]

Week 6: Asteroids Development Post

Development:

The development of Dead Eye had many features and assets that made it similar to the game Asteroids with some few distinct features to increase player engagement. The first new feature is that the ship that the player controls move towards the position of the players mouse rather than only facing the direction of the mouse. This allows the player to traverse around the whole stage. The decision to make the ship mobile has positives and negatives. One positive is that it allows the player to avoid asteroids in more ways than just destroying them increasing player engagement. A negative is that the mobility removes tension that comes with incoming asteroids. As a result, there was a possibility that the game became too easy and therefore boring.

In order to counteract the players high mobility, I decided to augment 2 features. The first feature involved the spawning the asteroids in a radius around the ship, moving at an angle in a range based on the position of the ship. Therefore, the player would still have to react to asteroids and be wary of asteroids that could spawn right in front of the ship. The second feature was a decrease to the angular velocity of the ships turning speed. As a result, it is more punishing to dodge the asteroids rather than shoot them. The reasoning for this is that the player would have to take a longer time to turn around before they can start shooting the asteroids that they just avoided. As a result, the player has less time to increase their combo after moving around.

The combo feature was one of the staple mechanics that were implemented similarly to fighting games. Players have a combo value that is based on how many consecutive hits that the player has made on asteroids. The players combo value is reset back to zero if they shoot a bullet and it hits no asteroids. In the elevator pitch I talked about making the player more powerful based on their combo which I implemented in 2 different ways. Firstly, as the players combo increases the speed of the bullets increase as well. The bullet speed per singular combo point is not noticeable but as they stack up a clear difference can be seen especially if a player loses a high combo. The second feature occurs when the player gets a combo that is higher than 10. At a combo of 10 the players bullet changes from a bullet to a missile that has a larger hit box making it easier to hit asteroids. By combining these two elements gaining more combos becomes exponentially easier as the speed and size of the projectiles increase.

Another counter on the screen is the lives counter which acts as a typical health bar. The player starts with 2 lives when a player gets hit by a small or medium asteroid, they lose 1 health point and 2 health points if they get hit by a large asteroid. When a player’s health points reach zero, they get transferred to a game over screen that is accompanied with a respawn countdown and the text “mission failed”.

Another feature that I got to experiment with during the development of Dead Eye was the use of audio files. I got a sample shooting noise and explosion noise for when the ship shoots or gets hit by an asteroid respectively. I also searched online for a free countdown noise to accompany the game over screen countdown to make it not feel so empty.

Play Testing Feedback:

In this play testing session, I got feedback from two people as well as a rating for some qualities of the game.

Play tester 1:

-       Implementing a pause feature

-       Invincibility frames for player and asteroids

-       Not much initial tension

-       Click to respawn instead of a timer

-       Way to shoot behind.

-       *Didn’t notice ethe ramping bullet speed until it was pointed out*

-       Doesn’t function well on a touch pad

-       Scaling movement speed?

Play tester 2:

-       Rockets sprites coming out sideways

-       Having the ship constantly move towards the cursor is inhibiting and makes the movement feel uncooperative. Maybe have a stop feature for the ship

-       No dynamic changes

-       No upgrade indicator to accompany combo

-       Dynamic enemy types with special abilities (unbreakable, explodes)

Textbook Research

In chapter 10 of my Game Design Workshop textbook, it discusses the engagement of the game and how “fun” it is. It elaborates on how different players enjoy the game and what aspects of the game should be refined in relation to the feedback. In the chapter they also show a graph to judge the aspects of the prototype based on its functionality.

In the workshop where I did my Asteroid game play testing, we also looked at a similar graph

These are survey results were retrieved during the play testing as a reference point to how much “fun” they experienced during the play testing session. There are certain biases that are not accounted for through this testing method however it is still a good reference point regardless.

 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

[n10808515]

Week 5: Asteroids

In my Week 4 workshop I was asked to create an elevator pitch designed around the Asteroids arcade game released in 1979 by Atari. The game has the player sit in the middle or the screen and shoot incoming asteroids to break them down before the collide with the ship.

The original Idea:

While playing the original game online I thought that the game could be a lot more interesting if the player couldn’t just spam bullets. As a result, I got the idea to implement an accuracy feature into the game. Furthermore, we were recently looking at fighting games in the lectures which gave me the idea to have a combo counter that rewards the player based on their accuracy.

Dead eye:

You are a young recruit at the bottom of the ranks in the space military. A large alien invasion has started with enemies and occasionally allies fly around you in the battlefield. To become stronger, you need to prove your ammo efficiency to the commanding chief (who is a cheapskate) by hitting consecutive while also fighting back the alien invasion.

Gameplay:

Alien ships will fly in linear directions around the screen until they’re hit and killed. Hitting consecutive shots in a row without missing grants the player a combo. The highest combo achieved that round gets converted into cash at the end of the round. Cash can be used to buy upgrades to increase the ships destructive abilities, accuracy or increase its survivability.

Why is it compelling:

Rewarding players for being more accurate with a better ability to clear the asteroids creates a risk reward for shooting. When the player shoots there is a chance to increase their combo which allows them to become stronger or there is a chance to miss which will make them lose their combo and all their accumulated power. As a result, being accurate relates to the difficulty to clear the asteroids and therefore the difficulty of the game. I believe that implementing accuracy in this way is beneficial to the games enjoyment as precision in games has a very high skill ceiling which makes it rewarding to practice and replay.

Platformer Post-mortem

I feel like the platformer game that I developed lacked in many areas. At its core, the gameplay was barebones only make use of a jumping mechanic to a limited degree. I believe that I spent too much time experimenting with the moving platforms and as a result it acted as a real time sink in the progress of my game for no visible results. As a result, I couldn’t implement the mechanic that was mentioned in the elevator pitch which made the gameplay feel lacking.

In order to improve my process, I would create a more iterative design plan that includes all the features that I want to integrate into the game. Despite the platformer being a prototype, I couldn’t implement any of the features that were discussed in my elevator pitch. However, I do believe that with more experience I will be able to dedicate more time to the creation of my features rather than experimentation.

If I was to change a gameplay feature in the platforming prototype it would be the fly enemies. In the platformer the fly enemies could not be killed, allowing the player to jump on them infinitely. My reasoning for this was because I believed it was too difficult especially for a starting level. However, as a result I believe that this was a contributing factor to the game being boring. The fly enemies were usually used to allow the player to bridge large gaps by bouncing of them. Due to the flies not dying the players have infinite time to bounce on the fly before they had to cross making the only difficult part initially landing on the fly. As a result, there is no tension being built up resulting in there being little to no payout after crossing the gap. After review, I believe that changing the fly enemy to die after being jumped on would create a more fiero as the player would have to time their jumps and think on the fly to cross the gap.

In hindsight I would probably change the design of the stages to have better flow. When discussing the seeds of gameplay in my Week 3 lecture there were two seeds that I wanted to explore, mechanics and rhythm. The mechanical side of the platforming game weighed heavily on the jumping mechanic which was already implemented as a base behaviour in GDevelop. As a result, I believe that I should’ve spent more time experimenting with this core feature rather than throwing the settings on default when creating the game. Secondly, the rhythm of the game was meant to be slow as the original elevator pitch for the game was a puzzle/ platformer. However, upon reflection there was no aspects of the game that encouraged the player to slow down such as secrets or collectables or any puzzles that were needed to be solved in order to progress. As a result, the only feature slowing the rhythm was the movement of enemies and platforms hindering the players progression.

[n10808515]

Here are picture of the scene 1 (left) and scene 2 (right) scenes that were created in during week 3′s development phase. You can see the newly implemented features such as the fly enemy, the moving platforms and the cactus flagpole. 

[n10808515]

Week 3: Development

Platformer Development Post

I continued to develop my platformer game throughout the week and experimented with some more game elements that I could implement into a proper prototype. There was a bucket list of things that I wanted to achieve before the playtesting this week.

1.    Extend the first scene

2.    Implement the moving platform

3.    Have a second enemy

4.    Have a second scene that the player can transition to from the first scene

The first Item on the bucket list was to extend the length of the first scene. In order to do this, I needed to add more platforms so the player can get a feeling of progression. Although the level is short having the screen scroll to the side still gives the player a sense of exploration as they progress with new content appearing as they move around.

The second item was to add a second enemy to give the new level some diversity in the obstructions. I wanted to create a flying enemy as to make use of a fly sprite that was unused during last week’s workshop. Similarly, to the slime it a simple enemy that can damage the player, but it moves vertically and cannot be killed. The player can instead be bounce on the fly which allows for the unique interaction between the player and the enemies. Instead of incentivising killing the fly, the player can instead use the fly to progress further in the level by bouncing of its head to reach otherwise inaccessible areas.

In the first scene I want to implement the moving cloud platforms that I experimented with last week. I positioned the cloud so it would slide horizontally at the start of the stage at a somewhat slow speed. Considering this is the start of the game keeping things easy with a slow-moving platform helps set a simple pace. The platforms also move underneath another platform meaning that it cannot be jumped on all the time. Also, if the player doesn’t jump up to the next platform they will be pushed off as the moving platform slides underneath.

When adding a second scene I wanted it to be considered a different stage similarly to Mario. To visually depict to the player that they have changed stage I changed the environment from the first scene. Instead of using grass platforms they were brick platforms, instead of a dark grey background it was a light grey. These distinctions allow the player to recognise that they have progressed and associate that progression with environmental changes.

To achieve the scene change I used a cactus sprite to signify the end of the first scene. I wanted to use a more symbolic sprite like a flag, but I didn’t have one available to me at the time. When the player collides with the cactus, they are taken to the start of the second scene. In this scene the player must bounce of 3 flies to breach a large gap. If the gap

   Play Testing notes

The feedback that I received for my prototype game includes

-       Better syncing the movement of the platform with the movement of the enemy for better flow

-       The level change was too abrupt, maybe add in a transition so the player has time to adjust

-       The addition of a restart function so the player can retry if they fall are die

-       Better communicate what can be jumped on

-       Do not use yellow text

There were also a few bugs in the game that were recorded during playtesting. Considering there are a few bugs I want to start familiarising myself with the debug feature that is available in GDevelop. The noted bugs include:

-       Taking damage from squished enemies

-       The player animation not changing mid air

-       Health state not going down consistently

I was particularly interested in the point about syncing of the platform and the slime. How they were now the platform and slime had a poor synergy as the player couldn’t jump and kill it because the platform was always above it. This point stood out to me because it got me considering not only the interaction that objects have with the player but how objects interact with each other.

Another important point would be the restart function. I feel like creating the function for the player is important considering the only way I can restart the game is by closing and reopening the game. Having a restart function would allow me to better test the game and its features and save me time when de bugging.

[n10808515]

Here is a picture of the slime that I programmed for the Week 2 of GDevelop. You can see the parameters signified with the arrows

[n10808515]

Week 2: GDevelop

Elevator Pitch

In the first workshop of the lesson, I was asked to create an elevator pitch for a game. There was a game idea that I have had for while which involves switching between a platformer and a puzzle game through the application of game

The Original Game Idea:

You play as the main character in a seemingly normal Mario like 2d platformer. However, throughout the stages there are missing textures and glitching voice lines. When the player interacts with the glitched textures it swaps them into the ‘back end’ which is a parallel world in which the player can move certain objects in the level around to traverse the level.

The story:

You play as a character who has been destined to die by the ‘original script’ of the story, told to you by the tutorial npc. After learning your inevitable doom, you find a glitch portal that lets you enter the ‘back end’ Interact with the back end of the program to redesign the game in order to access new areas and avoid your doom.

The gameplay:

Switches between a platformer and a puzzle game which allows the user to think about how they are going to manage their resources. When entering the glitch portals players can only access the objects in a limited space around them meaning that exploration is encouraged to smoothly progress the level.

Why is it compelling:

Being able to control your environment gives a unique spin on classic platformer games like Mario that have you go through a set path. I feel that the story, while not the focus of the game is also compelling as the concepts of changing fate to avoid the inevitable.

GDevelop basics

In today’s workshop for IGB220 we downloaded and began using GDevelop, a game development program that is beginner friendly. I have never interacted with game development software before despite wanting to develop games as a job, so this opportunity was very exciting. When beginning a new project, we started by creating some basic objects such as the player, a platform to stand on and an enemy to kill or be killed by. In order to achieve this, I used the sprites provided by the unit coordinators that gave animation to the player for walking, jumping, falling and standing idol. As a result, the player’s model had a livelier design allowing the animated response to the players movement to be more engaging.

In order to achieve movement for objects that didn’t rely on player input, I used two objects that were hidden from the player that acted as parameters. These objects were denoted using arrows that signified what direction I wanted the colliding object to go after hitting the arrow. Using the collision function, I was able to change the object’s ‘direction’ variable during a collision with the arrow parameters. Therefore, I could set the direction of the object to move in relation to the variable it had been assigned. As a result, I was able to give simple movements to objects such as up and down movements to the slime in the image below.

GDevelop Experimentation

After the workshop I continued to work on the GDevelop prototype game with the resources I had available. My first idea was to create a platform that moved. I wanted to see how far I could push my current knowledge, so I opted to make a platform that only moved when the player was standing on top of it.

My original idea involved 2 objects. The first, being the actual platform, which was going to use a cloud sprite. The second was an invisible black box which was going to stop the platforms movement when they collided. The design would have the platform sit on top of the black box keeping it still. When the player collides with the platform it will be given upwards movement but otherwise it will have downwards movement. As a result, the platform will be able to go infinitely high if a player is on top of it which could be a cool gimmick for a game or level.

Unfortunately, I was unable to get the moving platform to work because of a few issues. The platform would only move upwards when the player collides with the side of the platform. On top of that, once the platform when up it would proceed to phase through the stop box and continue going downwards infinitely. Since I couldn’t figure out how to solve these 2 issues I resulted to programming the platforms to move like the enemies.

[n10808515]

Week 1 Introduction:

I am a student at QUT who is currently studying and IT degree with a major in computer science. I am starting this blog to document my weekly progress through IGB220 which is a game development class I am taking this semester. I have always had an interest in programming and game development ever since I was a young and was playing flash games.

Video games has been a consistent hobby for me through my life and I have played through many different games. A couple of my favourite games that I have played include the Binding of Isaac, Dead by Daylight, Terraria, Minecraft and Geometry dash. When playing these games when growing up I always speculated about the process behind the creation of the game’s mechanics, design and story elements.

Each of these aforementioned games had unique gameplay elements that made me consider the games design elements. A big inspiration for me was the Binding of Isaac who had a lot of unique selling points that made me interested in the game such as its tear synergy, religious undertones and gruesome setting.