August E Game Dev Blog

This is my last post of the semester!

I've had a great time working on all of these games throughout the semester. It was great learning how to create games in GDevelop and having to experiment with making games in genres I normally wouldn't. I feel like all of my work this semester lead up to my group making our final game for assignment 3 which I think turned out really well.

Making each game and getting play testing for each game really helped me learn about how to take feedback and use it to improve upon games. I think my group's final assignment did a great job taking the knowledge we gained throughout the semester plus the feedback we received throughout play testing to make a game that was overall fun and accessible for most players, with a good tutorial that explained our combat mechanics well.

During week 2, when we were first learning about how to make platforming games in GDevelop, I decided to make a game as a test before I started working on my platforming prototype. I set up a platformer controller and starting working on a little level. My character was just a simple circle with some blobby animations, and the obstacles were red circles with exclamation marks. This project for me was more about getting to learn GDevelop so I wasn't too worried about the quality of the actual game. I added random mechanics that I felt would be enjoyable to create and play with.

I made it so that if you hold X, gravity lowers (your character flattens out, I tried to make it look like they were floating like an umbrella). This let the player do much higher jumps or fall much slower if they held X at the height of their jump. I used this to create some interesting platforming mechanics, such as low jumps you'd have to do where you need to make a really small jump then hold X near the peak of your jump to glide down to the next platform.

This system felt janky but fun. I also added some a secret area and some random fish characters that flop around a bit. This project wasn't a super high quality game, but I had a lot of fun making it, adding whatever I thought would be cool. It helped me learn how to use GDevelop, design fun 2d platforming levels and add creative mechanics to my games.

I didn't end up using this game for my platformer prototype because this game was only really designed with me in mind, not the player in mind at all. As was covered in the week 1 lecture, you need to design games for the player and think about what they would want and find fun. You can't just make games with mechanics you think would be neat, throwing stuff together that you'd enjoy but wouldn't make sense to other people. (Conroy, 2023, Slide 38).

Source:

I really enjoyed working on this final prototype. Our group's game was a 2d platformer inspired by games like Megaman and classic Castlevania. I mostly worked on the coding, parts of the level design and the final boss design for our game. I think our game turned out really good.

Chapter 5 of the Game Design Workshop books describes games as systems designed to entertain players. These systems are made up of objects that have unique properties and behaviors that allow them to interact with each other (Fullerton, 2018, p130).

I think our game was set up to be a really good system. Our system was made up of all of the player's weapons and the different enemy types. Each enemy and weapon behaved differently creating relationships between weapons and enemies where different weapons would be more effective at taking out different enemies. For example, the rail-gun weapon created an area of damage in front of the player, damaging all enemies standing in front of the player. This made it helpful against the shield enemy since it would pierce through the enemy shield and therefore was able to do damage to the front of the enemy.

Later, Fullerton explains that "Also, a system’s components must typically be arranged in a specific way for it to carry out its purpose, that is, to provide the intended challenge to the players. If that arrangement is changed, the results of the interaction will change." (Fullerton, 2018, p133). Our system was very deliberately coded so that health and damage values were set up to encourage players to use the best weapon for each situation. For example, the shotgun didn't do any extra damage to the bomber fish, it was just more effective because the bomber fish would run up to the player and be in closer range; plus the bomb fish had the exact amount of health where it could be killed in one shotgun blast if all the pellets hit. The flying fish has just enough health where it can be killed in one hit from a homing missile, and the shield and regular fish have health slightly above the homing missile's damage to encourage players to save their missiles for the flying fish.

On page 148, Fullerton talks about the importance of giving the right about of information to the player about your system, and sometimes games want to fully explain their systems from the start with an open system (Fullerton 2018, p148). We made our system very open for players with a clear tutorial we iterated on multiple times, hoping that they would understand the best weapons for each enemy from the start. We wanted our game to be more about giving the player all the tools they needed to fully engage with our game in the best way possible rather than have the game be about experimenting and slowly learning about our systems.

If I was going to develop this prototype again, I would develop it with the upgrades system in mind and planned out from the start so that it could be a more core part of the game. Originally we wanted to have an upgrade system in our game but we had to cut it because of time and because we didn't have many ideas for it that we felt needed to be in the game for it to fully function. If I was doing this from the start again I would come up with big upgrades for weapons that would really change how they worked for upgrades from the start, designing the game with the upgrades in mind.

If I was going to redesign this prototype, I would try and re-balance the challenge to offer a better difficulty curve with a higher difficulty by the end. Chapter 4 of Game Design Workshop talks about the theory of flow, and how games need to find the perfect middle between being so easy that they're boring or so hard that they're frustrating (Fullerton, 2018, p97-98). I don't think our play testing put enough emphasis on asking about difficulty. I feel like our game was generally a little too easy, especially because checkpoints were very common and there was no punishment for dying other than going back to the last checkpoint. I also think the second level was a little easier than the first level which isn't good. I would redesign the game to gradually go from being easy as players get used to the controls and weapons to being much harder by the end, with a higher density of bomb and shield fish enemies.

Source:

I'm August, I like making games, for a long time it's been a hobby of mine. Throughout this unit I'm hoping to get better at making more polished expierences as well as being able to recieve feedback and update my game according to what people say.

In week 11 we did our first round of play testing, it was really interesting and helpful to see how players reacted to our game. I noticed that a lot of our mechanics would confuse players, for example, the homing missile wouldn't shoot if it didn't lock on to enemies, but there was no feedback it couldn't shoot because it didn't lock on to anything, so one of our play testers assumed the rocket wouldn't do anything at first. Another example was a player being confused about why the shield fish wasn't taking damage from the front, it took a while for him to figure out what to do.

According to the Game Design Workshop book, when play testing, you aren't supposed to give a big introduction or explanation for the game, you're supposed to just give play testers the game and observe how they play it. If they are making mistakes, you shouldn't stop them and tell them what to do, you should see what they try and take note of that, and let them figure out what to do on their own. (Fullerton, 2018, p281). During our play test, aside from giving a basic explanation of the controls, we didn't explain anything or offer advice on how to play our game during the play test. I think we got a lot of valuable information from where our players got stuck rather than where they didn't have any issues because of this.

Because of our play testing, we were able to create a tutorial at the start of the level that focused on the parts of the game that players got stuck on, like explaining how the shield fish worked and which weapons were the most effective. I also added a more obvious indicator that you were doing damage to the shield fish by increasing the size of a really small damage indicator that would show up when you shot an enemy.

Some other things I noticed during play testing is that at the start of our game when it's pretty easy, players would only use the small normal shot to kill everything, but as the game got harder players experimented with using all the weapons because harder fights pushed the players to experiment more to overcome the challenges. One play tester thought it was unclear which direction the player was facing, so we added two different animations depending on the direction the player was moving to make it more obvious which direction the player would shoot in.

Overall this play testing was very helpful to fix the more confusing parts of our game and to also get more insight on how to better balance the game to push players to experiment with all their weapons without making it too hard.

APA Citation:

Today my group worked on prototyping the first boss. According to chapter 7 of game design workshop we should create basic a visualization of our core gameplay to help us work out how the game will work (Fullerton, 2018, p217). My group drew up a prototype for the boss on a whiteboard, coming up with attacks that would work once we saw how the boss arena would be laid out.

According to chapter 8 of the Game Mechanics Workshop book, while prototyping Braid, Jonathan Blow tested out different time related mechanics to see what would be the most interested time based game mechanic (Fullerton, 2018, p. 242). My team also started digital prototyping different boss mechanics to see what felt the best for our game. We used simple squared with solid colours to represent the squid and show it's hitboxes.

(Grey box will the boss, yellow box will be the ground tentacle attack that will come out from the squid, the bright blue box will be the underground tentacle attack that will rise up from the ground and the black box will be the ink projectile attack)

APA Citation:

This project has been really fun to work on so far, I really like working with my group and we've made a ton of progress in the first few weeks. I've been doing most of the coding so far because we didn't know how to set up GitHub with Gdevelop until a week ago.

We took a lot of inspiration from games like Megaman and Evil West for our game, which is a 2d platformer focusing on ranged combat. Our main design idea was that we should have multiple weapons the player can use at any time, and have different enemies that would be weak to each weapon to encourage the player to mix up their approach. So far we have a lot of that down, with a bomb fish that is more easily killed with the shotgun that can quickly one hit kill it, the shield fish that is easily taken care of with a railgun that can shoot through their shield and a flying fish that is easily killed with a homing missile that can track it up into the sky. So far that core combat has been created but still needs some polishing and reworking.

Now we're working on creating the level designs, the boss designs and the upgrade system where the player can spend XP they earn (red orbs) between levels and before boss fights to upgrade their weapons and health.

Looking back at my racing game, I don't really love how this one turned out. I feel like the core gameplay just wasn't very good from the start with the gameplay mostly just being dodging fast moving obstacles. At first the obstacles moved too fast so I slowed them down, but that made the game too easy so I added booster pads to speed the player up which just added a chance of hitting an obstacle you couldn't avoid after hitting a booster pad. I tried to remedy this by lowering the amount of normal obstacles and adding fallen trees that were larger and had warning signs to give the player the ability to go fast but still be able to go away, I think that was the main part of this game that worked well. Overall though, I just don't think that most of this game came together very well.

I think the biggest issue with this game was a lack of meaningful challenge for the player. I read over chapter 11 of Game Design Workshop which talked about Fun and Accessibility. The book talked about how to figure out if a game is fun or not. It said to ask the play testers if they think the game is fun. I asked someone who had played my game if it was fun and they said it was alright but it didn't feel like it had much challenge or consequences for the player when hitting an obstacle aside from losing time. They said they probably wouldn't want to replay it. Game Design Workshop chapter 11 talks about different ways that games can be challenging, such as "reaching and exceeding goals", "competing against opponents", "making interesting choices", "exercising difficult skills" and "stretching personal limits". (Fullerton, 2018, p349).

I don't think my game does a great job at any of these. There aren't any goals that players can fail at, all they need to do is reach the goal as fast as they can. They can set goals on how fast they'd like to reach the goal and they keep replaying the game to get faster and faster, but that's something the player has to think up themself. There's no competition against opponents in my game, real people or AI opponents. Players can't stretch their personal limits or exercise difficult skills since there isn't many skills you can improve at with my game, it's just dodging obstacles as you move down a hill. You can't make interesting choices while playing since everything is just a split second decision.

If I was going to re-do this game I would focus on redesigning the core game play to add more opportunities for challenge and complex skill expression from players. I would create a set level with different places on the level for players to do complex tricks by inputting a series of buttons, so that players could choose where they do tricks and what they do, offering more meaningful choices to players. I would also make inputting the tricks challenging with a series of button inputs to offer more challenge and places where the players could fail.

Source:

Looking back at my asteroids project, I had a lot of fun designing the game and I think it turned out to be pretty fun. I like the weird control scheme I came up with where holding space makes you move towards the mouse and holding W shoots forward, the button layout doesn't feel like any other games and I like how different it feels.

If I was going to do this game again, I would probably try and start with a stronger central gameplay idea though, I feel like I just kept adding mechanics and ideas to this game in a way that didn't fit together super well, like the ability to pick up ammo and health, with items that spawn around the arena, the different enemy types, the general theming of the game being you playing as a rat in what looks like a kitchen fighting shoes with strawberries. I'd probably try and focus on elements that work together better. Everything works on it's own but I feel like it didn't all come together to being the best asteroids game I could have made.

Chapter 6 of Game Design Workshop talks about creativity and coming up with concepts for a game. It talks about how creativity isn't a linear process, but more of a recursive process where you come up with ideas and continuously iterate on them and change them as you work on your game. (Fullerton, 2018, p. 170). My game started out with the basic idea of wanting to make the player feel like they were controlling a little rat scurrying around. As I kept working I thought of ideas like having the rat be in a kitchen avoiding people's shoes, so that the player would feel like they were a rat scurrying around a bunch of people. I added the idea of the rat throwing strawberries, taking inspiration from the scene in Ratatouille where Remy eats a strawberry. I like the idea I ended up with, I feel like I got it across well in the game and I'm happy with the way I built upon my starting idea.



Source:

Fullerton, T. (2018). Game design workshop : A playcentric approach to creating innovative games, fourth edition. CRC Press LLC.

I had a friend play test my racing game and give me some feedback. I was told that I should add knock back to obstacles so that when you hit an obstacle you don't just immediately come to a stop, you get bounced back a little bit. I was also told to add a game over screen for when you finish the race. I was told to add more visual elements like making the background move and adding more variety in the obstacles.

Racing Game Pitch

Name: Snowboarding Frenzy!

Audience: Infinite runner game players

Genre: Racing

Style: Snowboarding in nature

Primary Mechanics: Managing speed, dodging obstacles

In this game you snowboard down a mountain as quickly as you can, avoiding trees and rocks. There are booster panels that will speed you up faster than your top speed, but if you hit an obstacle you lose all of your speed. You need to get to the bottom of the mountain as fast as possible, so keeping up your speed is important.

To control the game, you use the left and right arrow keys to move left and right, and you use the up and down arrow keys to slow down and speed up.

Selling points:

-Randomly generated mountain

-Go really fast

-Replay to see if you can beat your past time

Image Sources:

Left Image:

Rogers, C. (2021, January 12th). Snowboarding Fundamentals Webinar with the AASI Team. The Snow Pros. https://www.thesnowpros.org/2021/01/12/8840/

Right Image:

Week 6 Asteroids Play Testing

I got feedback this week on my asteroids game. I got told the game was too easy and that you could keep playing forever. The playtester also didn't like that the health circle was something you could stand on to regain health/the ammo box was something you could stand on to regain ammo and said it would be better as a pickup that spawned around the map and changed locations when you touched it.

To respond to this feedback I made enemies spawn more often to make the game harder. I also made enemies spawn faster the higher your score was so that players couldn't keep going forever and would eventually have too many enemies to kill. I made the health circle an item pick-up instead of an object you could stand on forever to regenerate health. I made the ammo box a pick-up that you would touch to regain a random amount of ammo before the box moved again.

Working on this 2d platformer game was really fun. I usually make 3d games with Unity so it was nice to create something 2d for a change. Throughout this project I was learning the basics of GDevelop which I found surprisingly intuitive to use.

I'm happy with the very deliberately basic and hard drawn art style I chose, and I think the gameplay ended up being pretty fun if a bit unbalanced. Using hitboxes to allow for melee attacks was talked about in the week 4 lecture and that was a feature that I added to my game (Koren, 2023, Slide 32). The melee attack wasn't added until late into development, so none of the enemies or level design were made with the melee attack in mind. This made the game very easy because there were some walls where the melee hitbox could go through the wall and hit enemies on the other side, and enemies could never respond with their own melee attacks to punish the player for staying close for too long.

Chapter 10 of Game Design Workshop talks about the different stages of development, going from being a very basic working game to having more functionality to being complete. My game went from the "Foundation" stage of development where it was just a simple room with some enemies to the "Structure" stage with a simple level for players to go through. I think the game was really fun as I went from the foundation of it to building up a basic structure. A play tester of my game said that they thought the core game play of my game was good but the level design needed to be improved, so if I was to keep working on this game in the future I would move on to the refinement stage where I would work on improving the level design and changing some of the game mechanics. (Fullerton, 2018, pp. 311-313).

If I was going to make this game again, I would design it with the melee attack from the start, designing enemies and levels with that attack in mind so it feels more balanced (I would give enemies a powerful close range attack to punish the player for going close range and spamming the melee attack). I think I would also make it more of a wave based shooter in a small arena with more enemy variety rather than a game about completing a level, since the combat is the most fun part of the game and I'd like to spend more of my development time focusing on expanding on the combat rather than the level designs. I also think that the game would have greatly benefited from better enemy AI that was able to do more than just move towards the player and shoot, although I don't know how feasible that would be in GDevelop.

Sources:

Fullerton, T. (2018). Game design workshop : A playcentric approach to creating innovative games, fourth edition. CRC Press LLC.

Asteroids Development Post

Week 4 Asteroids Elevator Pitch

Rat vs Shoe

Audience: 2d top down shooter players, Asteroids fans

Genre: Top down arcade shooter

Style: Cartoon visuals

Primary Mechanics: Shooting, resource collection, running

In this game you play as a rat scurrying around the floor avoiding human's shoes. You have to shoot at the shoes to defeat them. Survive for as long as you can!

You use the mouse to control where the rat is looking, you hold space to scurry forward and you press w to shoot.

Selling points:

You play as a rat

Instead of a lives system, you have a health bar that slowly regenerates

Today I made some small changes to the game.

-I made the low health warning symbols flash -When enemies get hit they now flash white for one animation frame -Enemies no longer all shoot on the same frames, their random checks were moved to private variables individual to each enemy

I also added some bigger changes that affected more of the core gameplay. The game felt really hard to play because you could only shoot right and left. That didn't really make sense with how floaty the player's jump is and how the level design had multiple vertical levels and platforms. I added the ability to shoot up and down which I thought helped the game feel a lot better to play since you could shoot down in mid-air while jumping over enemies.