Fynn's Epic Game Blog

Assignment 3 showed me loosely what it is like to work on a game in a development team. It also showed how to conduct playtests and the correct way to gather gameplay data from them. The assignment itself did require us to write a report of our findings from the playtests and communicate any adjustments that we needed to make as a result.

If I were to go about doing assignment 3 again, I would try and refine the death/coin loss system to give players more of a chance to recollect coins after loosing them. I would also try to refine the hit boxes on the spike traps and enemies as they seemed to have quite a few issues like players activating a spike trap without touching it and players bouncing off enemies without touching the.

Now that we had a working prototype of our game, it was time to get some user data. We had conducted a total of eight playtests. To do these playtests, our group member, Cane, made a pre-playtest survey, a general script, and a post-playtest survey.

These playtests consisted of a pre-play survey to understand how experienced the play tester was in gaming and what games they enjoy playing. Then we would conduct the silent playtest, where we would ask the play tester to communicate everything on their mind as they played through the game without us giving any hints. While the playtest was active, we would have two notetakers: one who would write down what the player was saying, and the other who would write at what times the player was encountering issues. We then got the player to do a deep playtest of the game in where we would explain how to go about certain aspects of the game and get them to re-try playing the game with the same note takers. After the two playtests were done, we got the play tester to fill out a response survey.

The playtests ended with varying results between the response and the difficulty that people found the game to be. For the majority, they found the game to be difficult yet enjoyable. The game did have a few notably frustrating aspects, one of which being the coin placement feeling unnatural or difficult compared to other games like Sonic or Mario. Although originally it was out intention to make the game difficult to collect every coin, some coins that we intended on making it easy to get were annoying to the players as they needed to jump to get a coin that was just above their head height. Another notable frustration players had were the goblins, as their walking pattern was inconsistent with the platform and their dash meant that if the players got hit by them when they were about to dash, they wouldn’t get a chance to pick up coins and got sent to the beginning with nothing. Even the more experienced players with platformers like ours got frustrated with the goblin’s movement patterns. Finally, players were also finding the traps to be frustrating as they blended in really well with the ground. Players would also forget that traps existed and stop looking for them, which caused most of our testers to get fairly annoyed. Overall, we got extremely valuable user data for our game prototype.

Now that I have finished my solo development games, it is time to work on assignment 3. This assignment is a group development assignment and is mainly revolved around the playtesting experience. As such, the first thing I needed to do was get into a group. I had already decided with two others (Winston and Ronan) that we were going to form a group together and decided to use Winston’s platformer prototype as our game development base. Another person in our workshop, Cane, liked the idea of the game we decided to work on and joined our group.

With our group formed and our game idea set, we could begin the further development of the game ‘Treasure Rush’. We started by splitting up the work between our group members, so everyone was contributing to the final design and to make the game development process much easier. We also set expectations as to when certain aspects of the final assignment were to be done to keep a somewhat timeline so we can get it all done on time.

My part of developing the game was to add the survival system and add the additional parts of the game created by my group members. First, I had to read through chapter 11 of Game Design Workshop: A Playcentric Approach to Creating Innovative Games, as it would help me design this part of the game to make it enjoyable. To make the survival system enjoyable, I tried to make it a challenge while stretching personal limits, where players do not need to retain all their coins but do so for the sake of completing the game with the highest score possible.

As the collation of all our individual work does not need to be created until the playtesting stage, I began work on the survival system. My idea of how the player will get hit and die will be similar to sonic, where once the player is hit, they lose their coins and need to pick them up again. However, if the player has no coins and gets hit, they will die and need to restart the level.

Adding this mechanic was easier said then done, as the previous code for the survival system was simply if the player got hit, they would be teleported to the beginning with a 1 frame animation of being hit. This was an issue as I needed an actual hit animation and death animation and, in the game’s current state, was difficult to find a viable solution. I ended up using a separate object for the death animation so when the player got hit with no coins, it would delete the player and create the death object where the player was. After the death object’s animation played, it would create another player at the beginning of the level. This was a simple solution to the problem of the player respawning one frame after being hit and not having a death animation.

Next, I needed to add the coins falling out system. This would be much more difficult than the death animation as the player would still need to be able to move and play after being hit. The way I intend to make this work is to make it so while the player is in the hit animation, all the coins will fly out until the player has no more. To make this work, I made a separate type of coin called a death coin that would despawn after 1 second. This death coin was then given the same properties as the normal coin so the player could pick it up and gain coins back. I then needed to make the coins fly out of the player, the two main issues being that the player currently was not staying in the hit animation for any longer than one frame and making the coins fly out of the player with a force and not just spawning on the ground.

I decided to work on the coins flying out first, as it was going to be much more difficult to make work. The first issue I encountered was that if I made the coins spawn on the player, they would immediately pick the coins up as it spawned. I made it so that the death coin, on spawn, would have a short timer in which they cannot be picked up, this seemed to do the trick. Now I am left with the player leaving one coin floating where they are once hit. Now I needed to make it so the coins were flying out. To do this, I made it so once the death coins spawned, they would get a random angle to fly out at between -30 and -150 at a speed of 80p/s. These angles have an upward angle to them so currently, the death coins were flying into the sky and then disappearing. To apply a pseudo-gravity effect, after 0.2 seconds I added an instant force of 90 degrees at 150p/s so the coins would fall down. This then caused the coins to have a nice-looking arc when spawned on the player but then would immediately fly through the ground. To counteract this, I made it so the coins would lose all force while colliding with the ground. This made the hit system work.

My next issue was that the player would only stay in the hit animation for one frame, and consequently, only one coin would fall out rather than all of them. To fix this, I made all the animations only occur if the player’s hit animation has finished, if the player had been in the hit animation. This allowed the hit animation to play to its full extent and allowed all the coins to fly out of the player and make these mechanics work.

The prototype ended up looking like this:

After finishing my final solo development game for this assignment, I have seen that creating games is a very tedious process. With that in mind, however, I was enjoying the development of creating the racing game more than the previous GDevelop projects. As it was a simple game, there was a limit to how much I could add without it being overwhelming to play, which is unfortunate as I wanted to add much more variants of obstacles and powerups. Understanding the limit only came after I had added the police car and noticing that even just keeping an eye on both the oncoming cars and the police whilst looking for powerups was enough as is. Overall, I would say my racing game was a successful game development attempt.

If I were to redevelop my prototype, I would make different variants of police cars to add different ways for the player to think while trying to avoid oncoming cars. I would have also liked to make the oncoming cars come down more frequently or faster as the game goes on, with an indicator as to where they are coming from so the player doesn’t immediately get hit later into the game.

If I were to change my original prototype, I would change the scene as the car gets further into the game, like a sand track or a city track that would have different police and different powerups. I also genuinely like the idea of a police helicopter chasing down the player after a certain point, where the player has to avoid ‘missiles’ that the helicopter will shoot on the road that the players can use to blow up oncoming and police cars.

The finished game ended up looking like this:

Creating the basis of my racing game was fairly simple. I had a basic highway road with a simple red car sitting on it. I then created the illusion that the player was actually racing down the highway by sending trees flying down each side if the highway.

Lane Changes:

The movement I wanted for the player’s car in this game was for the car to stick inside each of the 4 lanes, where tapping left and right would move the car into the lanes on each side. This was easier said than done, the car kept vibrating immensely whenever I tried to get it to move between lanes. This was because I was attempting to add force to the car until it hit a certain position on the X-axis. However, after I set up the add force then externally add a condition that stops applying an add force once the car into position, it seemed to fix the issue.

Speeding up and slowing down:

To add the effect of speeding up and slowing down, I just made the up and down keys slowly move the car up and down. This does, however, allow the player to drive directly off the screen. To counteract this, I had set up barriers that, once the car gets to the edge of the screen, will push them back at the same speed they are going, seeming like they are idling at the edge.

Other Cars:

Since this game is on the highway, there will be other cars on the road. These cars will come down from the top of the screen, slow on the left side that are ‘driving up the highway’ and fast on the left as they are ‘driving down the highway.’ These weren’t too difficult to implement. I needed to make something happen if they were to collide with the player’s car. The effect I chose was if the player hit a random car on the road, the car on the road would explode and the player car would get damaged. This allowed the player to hit cars a few times before exploding themselves.

Police Cars:

Contrary to the other cars on the road, Police cars come from the bottom of the screen and are able to change lanes. The police will spawn in line with the player’s car and will change lanes when the player does. This is simple as it has a fixed speed of moving up the screen but reads the players X-position and just follows it with a small delay. The player will defeat the police cars by causing them to crash into other cars on the road, which is simply reading when a police car and any other car are colliding with each other and causing them both to explode.

Points:

As cars pass off the screen or explode due to police or player collision, the player will gain 200 points per car passed off screen or car exploded.

Phasing:

Phasing is a powerup that allows the player to well… phase. As well as cars coming down from the top of the screen, the powerup will also. When the player collides with the icon, a variable changes allowing the car to go straight through other cars. This required me to make it so when the phase variable was equal to 0, player collision related code would be active but once it became 1, it would not and a timer would start that reset the variable to 0, when the car is no longer able to phase.

Healing:

For my third game that I will create in GDevelop, it will be a racing game where the player has to drive down a highway while avoiding oncoming traffic. Using techniques stated by Tracy Fullerton in Game Design Workshop: A Playcentric Approach to Creating Innovative Games, I had to start by stating a challenge. This challenge I decided on was cars on the road, varying between traffic and police cars that the player must overcome. Now that I had an idea, I needed to explore the appeal of the game, which I concluded would be high-speed gameplay where the player will need to race past cars in order to gain points. The player would also need to avoid police cars by destroying them.

The title of the game: Highway Rider

Elevator Pitch: ‘Highway Rider is a top-down car racing game where the player will be driving down the highway while trying to outrun the cops. The player will gain powerups that will allow them to destroy cars in the way, get more health or even phase through cars. Among the high-speed gameplay, players will gain points based on how far they get and how many cars they destroy. While this is occurring, police will appear and attempt to stop the player’

The game will allow the player to move left, right, speed up the screen or slow down the screen to avoid cars. The unique selling points of the game comes from the powerups, the destruction of traffic and the constant threat of the police.Concept Image:

Google Images: https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.caranddriver.com%2Ffeatures%2Fg32019425%2Fbest-driving-games%2F&psig=AOvVaw0Oymqcmew6bvZbV2k694YK&ust=1631858820580000&source=images&cd=vfe&ved=0CAsQjRxqFwoTCNjGk4DqgvMCFQAAAAAdAAAAABAJ

My Asteroids Game has turned out to be pretty much how I had intended it to be, just without better looking sprites and a leader board for scores. The addition of different scenes and a tutorial at the beginning of the game, it became fair to say the overall development of this game was a success.

If I was able to redevelop the prototype, I would be sure to adjust a couple things that I had left out of my game in its current state. Mainly, the use of better sprites and a more immersive background, as currently the background is a solid grey colour, and my ship is a triangle with green at the nose of the ship. I would also be sure to add the ability to stack powerups to allow another style of play by waiting for powerups to spawn then taking multiple at once to feel like an all-powerful god.

Developing the basis of Meteor Rush was not too difficult, it was simply moving around a ship that can shoot bullets out of the front. Adding meteors was also fairly easy as it was just getting the game to spawn a large meteor randomly on the screen and getting that meteor to move in a direction. However before making too much more of the game, I needed to take into consideration some aspects of Tracy Fullerton’s Game Design Workshop: A Playcentric Approach to Creating Innovative Games. In which I needed to hone a core game mechanic to make sure the game is playable but will also be enjoyable. With that in mind, it was time to fix a couple bugs and work on enjoyable gameplay.

Player Score and Lives

The player needs to have a goal and a way to lose. Currently, the only thing the player can do is move around and shoot meteors for no gain, and if hit by a meteor, nothing happens. To combat the aimlessness, two variables are made: Lives and points. If a meteor gets shot, it will now be destroyed, and the player will gain points. Also, If the player would run into a meteor, they would lose lives and when the health reaches zero, the game will go to a game over screen.

Refining the Meteor

The meteor, in its current state, flies across the screen and, once shot, can be destroyed. In the current code, the meteor can spawn on top of the ship, causing the player to lose lives immediately due to a game bug. To fix this, the meteors just needed to, on spawn, make sure it is not in collision with the ship, and if they are, spawn somewhere else. This was a simple fix to the issue. The meteors also need to break into smaller meteors when shot, and so, when a bullet is colliding with a large meteor, it’ll break into medium sized meteors and those can be broken into smaller meteors. Destroying each type will grant points to the player and do different amounts of damage.

Powerup 1: Rapid Fire

The first powerup I want to add to my game is a rapid-fire power for the ship. The implementation of the power up is not difficult as it is simply adjusting the player’s shot speed when they pick up the powerup. Causing the powerup to spawn is also similar to the way asteroids spawn, just without the initial movement. The powerup will spawn once every 20-40 seconds to space out the power boosts. The powerup only lasts 10 seconds and has an internal timer that turns the powerup off after the timer ends.

Powerup 2: Triple Shot

This powerup was more difficult to implement. My initial idea was to just spawn 3 bullets at the nose of the ship, each with their own direction and speed. However, this proved to be difficult as the speed and direction, when applied to each bullet as they spawned, applied to the previous bullet as well. This caused the bullets to fly off at different speeds in the wrong direction. My next attempt was to create three different bullet objects and have them each shoot out of the ship. This worked however all the code used based around bullet collision had to be copied and pasted two more times for each different bullet object. Finally, I managed to make the design work by having the three bullets spawn each in their own sub events, meaning they all interact how they should be, and I don’t need to copy and paste the same chunks of code two more times. I also made the powerup spawn random between rapid fire and triple shot.

‘Powerup’ 3: Nuke

The nuke was fairly easy to implement as it was as simple as deleting all the asteroids on the screen and giving a flat number of points. To balance this, the spawn timer is somewhere random between 1-2 minutes. The spawner of the nuke is separate to the spawn timer of the basic powerups due to the power of the nuke.

Ability: Scatter Blast

Scatter Blast is the ability, where if the player right clicks, they will shoot out a ball that, once it hits an asteroid of any kind, will instantly destroy it and six bullets will fly out in a circle. The ability is on a 15 second cooldown and adds another way for the player to clear meteors without powerups or basic shots.

The final game ended up looking like this: 

My second game I will be having a try at making will be an asteroids style game, unique to the original asteroids in that there will be powerups and movement will be cursor based rather than keyboard.

I will once again be using a playcentric design process as it has allowed me to see the game from a more enjoyment/interactive style. I will also be using the same questions that I used when developing the previous platformer game.

What is your gameplay?

·         My game will be a ship following the mouse around, shooting asteroids to gain points and avoiding them as they fly around the screen to avoid taking damage.

Why will it be compelling?

·         The game will use powerups and a second shot type that the traditional asteroids game did not have as well as a different control scheme such that it feels like an upgrade from the original asteroids.

Who is the target audience?

·         Target Audience: 7+

What is the players role?

·         The player is taking the role of a ship navigating its way through space while avoiding and clearing out asteroids.

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

·         The player will be rewarded with points and motivation to beat their previous best scores.

What genre is the game?

·         A shoot-em-up game

What is the setting of the game?

·         You are a ship that is flying around space, fighting for your life against the harsh environments of space.

 Now that I have developed a concept of my game, an elevator pitch can be developed.

‘Meteor rush is a shoot-em-up, asteroids style game where the player takes control of a ship and has to avoid and clear out oncoming meteors by navigating around and shooting them. The player will be given multiple different powerups to help them clear out the meteors to gain points. They may also use a super shot less frequently to help clear the large amount of meteors that will spawn as the time goes on.’

Concept Image:

The main feature of the game will be the melee combat, and thus must be the next thing to develop in my platformer. First however, I needed specific sprites as the base models I was using do not have a sword swinging animation. These are the types of sprites I used for my character:

Now that I have an attack sprite for my character, I can work on the attacking feature of the game. With the way GDevelop works, I had to create conditions based on the animation that my character was currently in for specific interactions. For example, if the player was in the attack animation, and the sword’s collision mark was colliding with an enemy, the enemy would be labeled as ‘hit’ and change animation. The implementation of the melee combat was not too difficult however was very time consuming for all the conditions that needed to be in place in order to ensure the game ran how it was intended.

If I had to redevelop my game’s prototype, I would allow more than one style of combat and some form of aerial combat. I would also give the enemies more attacks than just colliding with the player when they aren’t attacking to add a more enjoyable, immersive gaming experience. I also think, for the design of the game, more parkour/maneuverability options should be added so the game isn’t all just hack and slash.

If I had to change my platformer’s design, I would implement a more specific end goal, something making the journey worth it for the player, as well as some more explorative levels. The current end goal of my platformer was the generic ‘kill the big bad’ trope, which isn’t necessarily bad but could be more unique/worth going through the effort for. I have always liked the idea of an anti-hero over the self-righteous hero, so maybe more of a threat to the player like needing a cure to an alien corruption to him. This could also lead to unique ‘corrupted’ abilities the player can use rather than the current, generic sword combat. The addition of more exploration levels would also create a more immersive experience and allow players to play the game at a slower pace from time to time rather than rushing through every single level.

My final prototype, however, was an alright attempt at creating a unique player experience platformer game. It had helped me to understand the game development process in its essence and the amount of effort required to create such games.

An image of the game: 

I have begun production of my platformer prototype in order to put together the basics of what I want my game to become. Taking my elevator pitch I had made some of the necessary game mechanics within a sandbox using placeholder sprites and platforms.

The basic movement:

The first thing to look at when creating a primarily movement-based game is the movement of the player, which GDevelop already has set up for players to use so there was no hassle with implementation. However, GDevelop’s base movement speed is quite slow especially for the type of game I want to design so modified player speed and jump height to be a bit higher in order to give that high paced feel.

Double Jumping:

The double jumping mechanic is a large part of the game’s overall feel and thus needed to be added into the game early on to give the player a core mechanic that they require. The implementation was a bit difficult as I either had the character jumping an infinite amount of times or only able to jump once, however after messing around with the code blocks and variables I managed to add a double jump and create a few examples of how the player could use the double jump feature.

   Basic enemies:

Before creating a melee combat, enemies needed to be added in order to have something for the player to hit. The enemies added will need to be hit twice for them to be defeated and will have a basic left to right movement across platforms. To do this, the enemies have invisible objects on each side of the platform they reside on that will allow them to move around. They will also inherently have two lives each so the player can not one hit KO them.

Coins:

Coins will be used to show the player the right track to the end of the level and also provide a point system for the player to track how well they are playing. They were easy to implement as all they needed to do was disappear when the player touched them and add to the player’s coin count.

Boss enemies:

The boss enemy is going to operate very similar to the basic enemy, however they will have more lives and will be larger overall. A lot of the code for implementing a boss enemy was similar to a basic enemy however the health was changed from two to five so they player will need to attack five times in order to defeat the boss enemy. After defeating a boss enemy however, the final platform will appear allowing the player to progress to the next level.

The first game I will be attempting to create will be a platforming game that utilizes melee combat and double jumping as core game mechanics. However, before I start production of the game, I will need to have an elevator pitch.

Upon reading the first two chapters of The Game Design Workshop by Tracy Fullerton, I realised I would need to create my game using a playcentric design process. The first step of this process is setting player experience goals, which is recognising what I want the player of my game to experience while playing my game. I want my players to be experiencing an upbeat exploration type of experience. This is the most important aspect as allowing the player to experience flow throughout the game is essential to keeping them engaged and wanting to keep playing. In my game I want my main mechanics to be running, jumping, double jumping, and melee combat. I would also like my levels to have one obvious right path but another path that can lead to hidden tokens around the map.

A concept of my game was also necessary for me to be able to create my elevator pitch. As such, I have been given a list of questions to answer in my IGB220 lecture.

What is your gameplay?

·         My game will focus on mobility through running, jumping and double jumping with melee combat to fight enemies with an optional exploration aspect.

Why will it be compelling?

·         The game will use different enemies that will change how the player will approach certain combats. There will also be an exploration aspect allowing them to find hidden areas around the map.

Who is the target audience?

·         Target Audience: 13+

What is the players role?

·         The player is taking the role of the hero, where they need to fight off different enemies in order to stop them from getting to his home village.

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

·         The player will be rewarded with tokens for exploring the map or coins for defeating enemies and following the path.

 What genre is the game?

·         An action-adventure type

What is the setting of the game?

·         Monsters have invaded the players home village from unknown whereabouts. The player must fend of these monsters and find where they have come from in order to put a stop to them at their source.

With my game concept in mind, my elevator pitch will just be a short summary of the utter basics of my game and why it should be created. This is my elevator pitch:

‘Hand of Markus is an action-adventure platformer game where the player’s home village is attacked by monsters and he must fight them off, find where they came from and put them down at their source. The player must traverse through multiple different scenes and fight many different enemy types in order to save his village. The players must fight enemies using melee combat and traverse obstacles using running and double jumping to acquire tokens and coins to complete levels and defeat the monster king.

The game will be PG13+ due to some violence that is evident in the gameplay