Zayben's Game Dev

For any game to end up being a fun, enjoyable experience, it must be playtested during development, and this is no different for Climb to Heaven.

To playtest the game, I had a friend of mine sit down with no prior explanation of the game and a 10 minute time limit. I took notes of how they reacted to certain interactions in the game, as well as their general body language and facial expressions while playing. Finally, I asked them a series of questions to get a direct opinion of the game.

The results of the playtest were enlightening. There were some obvious issues with the build of the game used for the playtest, including the vanishing platforms flickering randomly rather than becoming invisible, but generally the experience was well received, albeit rather frustrating. However, the essence of the game is that it is frustrating, although that should be due to the main mechanics themselves punishing the player, rather than bugs, control issues, etc. that hinder their ability to play the game. As far as problems of that nature, very few were experienced, although I did get feedback that the player movement felt slightly off. To remedy this, I took the values for the player deceleration and decreased them slightly, so the player took longer to stop moving, making the game less punishing, without the player feeling too slippery.

For the third assignment, the group we formed decided to continue development on the platformer I had made during the original 2 week sprint, Can't Stop Won't Stop. The name has since been changed to Climb to Heaven, and useful documentation such as the one page GDD was created to get everyone on the same page.

The One Page design doc I created for the game

As a majority of the key gameplay systems were already implemented from the original prototype, there hasn't been a considerable amount of development undergone. Primarily, new assets have been made to replace the placeholder ones used originally, and some new enemy types have been designed, which can be seen in the GDD. The key new enemy here is the flying enemy, which will target and move towards the player for as long as they're within a certain distance of the enemy. The main hook of the game still applies to them, where should the player collide with this flying enemy, they will still fall through the map for a set amount of time.

The biggest aspect of the game that needs work from the prototype is the design of the level itself. It still needs to be greatly expanded from the small prototype level used for testing and needs a larger variety of platform combinations and challenges for the player to try and overcome as they ascend towards their final goal, heaven.

While designing Bolt to the Finish!, my design process was primarily inspired by one specific aspect of the readings, player choice and how to improve it, from Chapter 11 of the textbook. The risk and reward of each decision the play makes can directly lead to fun, seeing the risky choices succeed beautifully and having to quickly recover situations where the risk did not provide enough reward. Especially for Bolt To The Finish!, where the majority of the player choice is in the hands of the player who isn't currently racing, making decisions with variable impact can directly affect how they feel about the gameplay. To really emphasise the risk vs reward of the decisions for the player making them, the cooldown time on the abilities is restricted based on the strength, however even the strong abilities are still situational. While they may provide the advantage required to win against the other player, if they're messed up even slightly the first player is quickly disadvantaged, having to wait a longer time before being able to further influence the racers gameplay.

If I had to change one thing about the development process, I would've fully implemented the traffic system before I tried to get the abilities working. Having a traffic system that can generate consistent traffic between races would've helped reduce any randomness that reduce the fairness of the game and feel frustrating to the players. Additionally, having it fully functional before starting on abilities would've allowed me to better integrate traffic based abilities into the game, so there could've been a larger variety of interesting abilities that affect the traffic around the player racing. Developing the features in this order would've allowed for improved player choice regarding the abilities one of the players can use, as well as reduce unnecessary points of frustration by having more consistent traffic between races.

For the design of the prototype, while I'm happy with a majority of it, there is one key area I would further adjust if I had the time to do so, this being the abilities. As the key gameplay system for one of the two players at any given time, I feel the abilities could be adjusted to be much more fun. While they give the player plenty of choice in how to try and obstruct the racer, to not make them completely overpowered, there's currently a big emphasis on global cooldowns, where the use of one ability restricts the use of all others until a cooldown, based on the strength of the used ability, has completed. While actually playing the game, this can actually quite detract from the fun the player is having as they often end up locked behind a timer and simply having to wait, rather than play. To improve this system, I would go back and redesign the abilities to have "tiers" of strength, and using an ability only locks abilities of the same tier behind the cooldown, while giving every other ability a short delay, just to prevent spam. Reducing the emphasis on global cooldowns means the player is able to consistently interact with the game, however it shouldn't become an unfair experience as they primarily can only use weaker abilities, with the stronger ones having longer cooldowns, both increasing the risk/reward of using them and emphasising smart combinations of abilities to reduce that risk as much as possible.

Sources used:

The major draw of this prototype is that both the players are interacting with the game world in completely different ways. The first is maneuvering a vehicle around the map trying to make it to the finish line, while the second is influencing the map by increasing traffic, adding road blocks, and even altering the controls for the first player. To make both players able to interact given the same camera, I had to make it so the influence of the second player is to some degree random. Instead of picking where exactly the barrier appears, or which lanes of the road it's blocking off, they simply choose to spawn a barrier, and the barrier randomly picks which lane will be left open instead. To achieve this, I essentially made multiple different barrier objects, which the game randomly picks from and spawns a set distance ahead of the racer when the second player chooses to spawn a barrier. The other powers act similarly, with the traffic increase simply spawning a greater number of passive vehicle objects. The biggest issue I had was with making an interesting level. I had initially wanted it to turn and keep the same perspective, however I was unable to get it working, so instead the highway is simply a straight line heading upwards.

While making this prototype, I learned quickly how difficult balancing can become with the addition of extra players. For the previous prototypes, they had all been fairly simple. Don't make it frustratingly difficult, ensure the player can succeed, even if it takes them a few attempts. However, when the main opponent for a player becomes another player, you can't simply reduce the skill of that player to make the game easier. To balance the game, I had to ensure the cooldown for the powers was low enough that they couldn't be constantly active, whilst not being so large that the second player felt there wasn't much to do. The powers themselves also couldn't have too great an effect, otherwise there would be no incentive to use weaker powers, or the strong powers could become excessively frustrating to play against as the racer.

The readings I had done earlier returned to me while I was experimenting with edge cases in the prototype I had developed. One such case was if both players, after each having their turns racing, had an equal fastest time. Before I had encountered this edge case, I hadn't even considered what should be done if both players best times were equal. Neither would be considered a winner, as neither had a faster time. This made me remember the idea of internal completeness of a game. This grey zone that the rules of the game had missed meant the game was incomplete, and this could be incredibly frustrating for players, as now there wasn't a winner in this competitive experience. To remedy this, I came up with two main ideas. Either whoever had gotten the time first would be the winner, or whoever had overcome more obstacles during their run with that time would be the winner. The first was simpler to implement, however it would naturally advantage whichever player got to be the racer first. The second would remove this advantage, but require much more time to implement. By this point, I didn't have the time to implement the second, so I simply implemented the first and called it a day.

My thoughts on the current readings mostly centered around one question posed during Chapter 10 of the textbook. What am I testing for? In most of my other projects, my playtesting has always been focused around finding bugs and ensuring the key gameplay systems worked seamlessly, as I was the lead programmer and that was my responsibility. However, for these prototypes, I've handled every role more in depth and have been responsible for every aspect of the prototype. So when it got to playtesting, I really had to ask myself, what did I want to achieve from this playtest? What questions did I have about the game, what were the answers I was expecting, and how was I going to implement the feedback given by playtesters? Now, the results I got from playtesting weren't simply, "This interaction is strange, is this a bug", but instead could be anything from "I'm feeling really frustrated by how quickly this happens", to "This game isn't fun".

Sources used:

Bolt to the Finish! is a competitive, one versus one racing game which pits two players head to head in a race to the finish line. Taking place down a highway, each player has a turn at controlling the car, weaving through traffic to try and make it to the finish line as fast as possible. However, while the other player isn't racing, they get to influence the obstacles that the first player is encountering. To try and slow the racer down, and thereby win with a better time, they can temporarily increase the quantity of traffic in one of the lanes, spawn a random roadblock, or even mirror the controls for the person in the car! After 3 rounds, whoever has the fastest time wins the game.

The genre for Bolt to the Finish! is a competitive, top down racing game, as the two players are competing head to head to complete the task in the fastest time possible.

The primary mechanics in the game are the vehicle controls for the first player, and the obstacle spawning for the second player. The racer is able to control where the car goes by using the arrow keys, while the second player can spawn various obstacles using the qwerty keys, with each key representing a different ability via icons on the screen. The mode of gameplay is a competitive, 1 versus 1 racer, with each player taking turns as each role.

The setting of the game is on a highway, exiting a small town and racing towards a gas station located in a forest outside the town. The style of the game is reminiscent of old arcade and retro racers, with a top down perspective and 8 bit sound effects.

The audience for Bolt for the Finish! is anyone who enjoys arcadey racing experiences and wants the challenge of proving their skill against another player, as well as those looking for a fun party game that pits players against each other. The demographics of these players would be casual and enthusiast gamers, aged between 12 and 55.

The readings I completed while working on the prototype for this asteroids games really influenced how I designed this game while making it. Especially the section on ideas vs designs. However, I hadn't read this until after I'd begun working on the prototype, so I couldn't incorporate it as fully as I would have liked to. As I usually do, I came up with an idea and jumped straight into prototyping the main mechanic of the game without too much extra thought, just wanting to find out how fun it would be. However, after reading this section and undergoing some introspection, I realised that I really should be expanding the idea a little more before jumping straight into the prototype so I could save time in the long run, making the base mechanics in a way that allowed expansion with new mechanics easily, rather than having to rewrite whole portions of the game to get it to function with new mechanics. By taking a step back and making more of a design from my initial idea, I would have a better understanding of what I want to create, both allowing me to make it more efficiently and with more flexibility for intended future additions.

There is one thing I would change about the process of making this prototype. While building it, I ended up trying to play test it myself a bunch, and didn't have a good idea of how the average player would end up seeing the game. I knew exactly how it functioned, how I intended certain mechanics to be used, that kind of thing. Next time, during the process of developing the prototype, I would try to get an external play tester with very little experience of the game to play it as early as possible, once just the key mechanics are in. This would have helped me to better understand which aspects of the gameplay are fun and what made some parts of the game a very frustrating experience. It would have saved me time trying to do it all myself, as well as creating a better game in the long run.

In trying to create the idea I had for an asteroids style game, there were many steps that had to be taken. Firstly, I quickly ran into problems with GDevelop while trying to make the three primary movement types. I had intended on doing more than just random movements, circular movements and horizontal movements, however implementing new movement types was very time consuming and didn't end up being worth the time it took to implement. Therefore, I stuck with just three main movement types. In the engine, I wasn't able to change how the asteroids that had already spawned moved, so I was only left with two options to change the movement type. Delete all of the asteroids currently spawned, or leave them and have the last of them still moving as the ones with the new movement type spawn. I ended up leaving them in, as testing with removing the old ones before spawning the new ones felt like a very jarring change, and while it could feel difficult having asteroids with two different types of movement simultaneously, it made for a smoother transition and better gameplay feel. Simply removing the old asteroids also had the side effect of unintentionally reducing the difficulty temporarily, as all the immediate threats vanished and took a moment to be replenished by the new asteroids. Keeping them in as the new ones spawn forces the player to remain vigilant through this transition period as there is no decrease in danger for the player.

Through the development of this prototype, I discovered the importance of a carefully tuned difficulty curve. To keep the player interested and wanting to continue playing, I had to pose a challenge, and this came through increasing the rate at which the asteroids changed movement type. However, the initial values I used for these rates proved far to difficult, and while playtesting was incredibly off-putting to the player, as it didn't end up being an interesting challenge, instead it was frustrating and made them want to stop playing. By reducing the rate at which the changes occur, it made the difficulty increase more gradual. This did mean that there were longer periods of lower interest, so I also had the change increase the speed of the asteroids. This ensured the player had to be continually focused, as even if the challenge of changing movement could be ignored temporarily, the faster asteroids became a more consistent moment to moment challenge. This led to reduced frustration overall for the player, and a greater desire to continue to play and attempt getting high scores.

From the reading, Tracy really shows how important good balance is in a fun game. This is what originally gave me the idea for increasing the speed of the asteroids periodically as well. When using just the time between movement changes as the primary basis for an increasing difficulty, it felt stale when the time was too long, and frustratingly difficult if it was too short. Increasing the speed gave an interesting sub-challenge that could alleviate the stale feeling with the slower rate of change of the movement timer.

For the readings, the thing that has stuck most with me is the difference between an idea and a design. I've wanted to create games almost as long as I've been playing them, so naturally I've had many, many ideas for what I think could make a fun game. However, actually studying the theory of game design and reading about conceptualisation has forced me to realise that while the ideas I've had in the past may seem interesting, an idea alone isn't worth much. It must be expanded upon and delved deep into to truly become something a game can be created around. This has been reflected in my workflow when making these prototypes, as I usually have an idea whilst creating the workshop example and jump straight into building the prototype, excited to get it working and playable. However, this always leads to me having to rebuild certain aspects as what I thought would be an interesting idea turned out to be difficult to design as a game that would actually be fun to play.

Sources used:

For the next prototype to be made, it has to be an asteroids style game. The design I've come up with based on this restriction is similar to the classic top-down arcade shooter, however rather than trying to destroy as many asteroids as possible, the player has to survive as long as possible while the movement patterns of the asteroids change every ten seconds. They might originally start going in random directions, then after 10 seconds they all only move horizontally, repeating every 10 seconds with a different movement pattern

The game would be a survival action game, as the player is forced to constantly pay attention to the action occurring in order to survive as long as possible in an attempt to get the highest score they possibly can

The primary mechanics in the game are the player movement and the asteroid movement changes. The player is able to move around by having the ship automatically move towards the cursor. For the asteroid movement changes, they will initially change movement style every 10 seconds, however as the player continues to survive, the movement timer will reduce, e.g. down to 9 seconds after living 30 seconds etc.

The setting for the game is a neon-dystopia style setting, reminiscent of Cyberpunk and Cyberpunk: Edgerunners. To distinguish itself from the original asteroids games, the player is not a ship, but rather a neon drift car and is being chased down by peacekeepers both on foot and in vehicles.

The audience for the game is anyone who enjoys classic arcade experiences, but with a twist on the original experience. It's a game that only requires a minimal time commitment, so people with busy schedules are able to spend a few minutes at a time playing a run or two. Basically, it's perfect for anyone from 15 to 35 with enough time for a few short runs of the game

After reading through the assigned chapters and beginning the design process for my platformer prototype, I was mostly inspired by the sections on play testing and prior reading I'd done on Valve's game development process. I went into the creation of the game with a general idea around the key gameplay elements, such as the falling through platforms, but didn't plan anything too specific and focused on quickly prototyping a functional game with a basic level to get to playtesting as quickly as possible. Being able to playtest early on allowed me to really refine the key gameplay mechanics, such as how the movement ties in with the platform falling and how to really nail a good feel for movement to make playing it an enjoyable experience. This process helped me find a good balance with the main gameplay systems to achieve my original vision while allowing me the flexibility to pivot elements of the design from the original idea very early on to achieve the most fun I could.

When it comes to the process of development, one thing I'd do differently is focus on nailing down one aspect of the gameplay at a time. While building this prototype, I ended up prototyping multiple different mechanics early, first the movement, then almost immediately afterwards trying to get the falling system working. Due to this, I had to rebuild the testing level multiple times due to changing the values that drive the player movement making certain areas either impossible or far easier. Next time, I would focus on really nailing the feeling of the movement first, to ensure there's less time wasted having to rebuild level layouts. However, that would've been difficult for this project, as a key part of the movement was how it interacted with the falling mechanic, and even once I had the movement feeling good on its own, I had to continue to adjust it in tandem with the falling mechanic so that it didn't feel too frustrating to play.

During the past week since my last post, I've managed to make a fair bit of progress on the game. There were a few key things I wanted to knock off the list that I've achieved. Primarily, I wanted to ensure the movement felt fluid, responsive, and fun while moving around the environment. While playtesting with a friend, I repeatedly tuned the values for acceleration, jump height, deceleration, and coyote time. The values I was originally using when prototyping the main mechanic ended up feeling very floaty and unresponsive, while the high deceleration felt too unforgiving for the player to want to continue playing. To address this, I reduced the deceleration greatly, increased the acceleration and maximum speed, as well as reducing the threshold for coyote time and jump sustain. This led to the player movement feeling much snappier, whilst being slightly more forgiving should the player release the movement keys. Next, I implemented the main enemy, which causes the player to fall through platforms for the next two seconds on contact. It adds a nice bit of difficulty to the game and when used sparingly can create challenge without excess frustration. Finally, to improve the level, I created flashing platforms to go along with the timer platforms. The flashing platforms can be stood on at all times, however are only visible for a second and a half at a time, making it hard to know exactly where the edges are. Again, using these sparingly around the current, temporary level helps add to the challenge of the game and provide more opportunities for the falling mechanic to shine.

Throughout further prototyping the game, there were a few things that I quickly learnt for future projects. Primarily, when making platformers, it is essential to nail the feeling of the movement as early as possible. Having to adjust it after building out some of the play environment can be very problematic as even slight changes can make some areas inaccessible or far too easy to reach. Plus, being a platformer, movement feeling good is essential as it's the primary way the player has to interact with the game. If it doesn't feel fun and fluid, the player won't engage with the game. On a more personal note, I've discovered that while GDevelop is good for quickly prototyping 2D games with the variety of built in behaviours, for a proper project I'd much prefer the flexibility of actually coding in an engine like unity, rather than the events system of GDevelop.

For the first 3 weeks readings from the Game Design Workshop textbook, the main thing I've really taken away is to really focus on the design and implementation of the moment to moment (mtm) gameplay. A game can have an amazing story, however if the combat is tiresome and uninteresting, the player won't ever experience that story due to those frustrations. It's essential to ensure the mtm is enjoyable throughout so the player is enticed to continue playing. Also, especially for platformers and simple 2D games, I find paper prototyping to be somewhat unnecessary when using an engine like GDevelop. It allows for very fast prototyping, and especially with platformers, the movement feeling good is something that can't really be tested on paper, and so being able to quickly prototype it digitally and fine tune the values is much better, personally speaking.

Anyway, that's it for this week. Next week I want to further playtest the game after fleshing the play area out a little more, as well as improving the visuals for the game. Adding some new sprites for the different platform types is essential, as well as a background to replace the current white void. If you want to play the current prototype, a playable demo is available here. Enjoy the rest of your week, I'll see you all again soon

Sources used:

In order to truly understand how to design a game that is captivating and fun to play for various players, I'll be developing a number of small game prototypes throughout the semester to develop and demonstrate my skills as a game designer (despite being a programmer primarily)

The first prototype I'll be creating is for a simple platformer style game. It's a genre that is fairly saturated, so it can be difficult to come up with a game idea that is unique and fun, rather than just being unique for uniqueness's sake. I want to focus on a player experience that is frustrating, channeling the essence of rage games, while also making the player feel accomplished as they overcome challenges in the world they were unable to before.

The game idea I came up with based around these player experiences is Can't Stop Won't Stop, a vertical platformer where the player is trying to ascend to heaven, but stopping gets them dragged back towards hell by a devil. Essentially, they get pulled through the platform they’re currently on if they stop moving for more than a short amount of time, causing them to plunge back down and lose the progress they were making.

The player is only able to interact with the game through movement, there is no way to fight enemies or otherwise interact with other game components. The challenge in the game will come from enemies moving around the platforms that, should the player collide with them, force the player to stop moving for a period of time, quickly dropping them through one or more platforms. There will also be challenge areas the player has to pass through, such as doors that are only unlocked by standing on a specific platform for a set amount of time, with jumping or moving off the platform causing the timer to start counting back up.

The game is set in a modern world, with three distinct areas. Earth, the starting area, which appears like normal with a ground layer, and underground the player can be pulled into and a sky area they're attempting to ascend through. Then, there's the heavenly area above earth, which contains the win zone for the player. Finally, should the player fall beneath the underground area, they'll enter hell, where they can eventually lose by falling into a pit of lava at the bottom.

The target audience for the game is casual gamers, people who enjoy challenging platformers such as Getting Over It, variety streamers, and masochists. The demographics it's targeted at are primarily people aged 12-31, as they can keep up with the fast pace of the game easily and are likely looking for shorter experiences to kill some time when required.