A reflective journal for the game development process.

This will be the last post I make for the IGB220 reflective journal assessment. We’ve successfully submitted our assignment 3 and I am immensely proud of our submission! Overall, it’s been an inspiring semester. I began the unit with zero experience in making games, and now I can say that I’ve made 4 games - whether or not they’re good is arguable! I’m motivated to take a step further from Gdevelop and try out more serious development using other game engines, and perhaps even participate in some game jams.

Below are the gameplay videos and links to the posts associated with the 4 games I’ve developed:

Boat Slalom

Click here to view posts associated with Boat Slalom

Fiend

Click here to view posts associated with Fiend. 

Glitchforce

Click here to view posts associated with Glitchforce.

Bopland

Click here to view posts associated with Bopland.

For the Boat Slalom prototype postmortem, I’ve outlined the feedback from our playtesters and also the changes we’d make to the prototype design in these previous posts. For this post, I want to reflect on our development process as a team.  

As uni students with other units running alongside this one, we can’t solely devote our time to this project. Without explicitly planning it, we naturally incorporated Agile methodology principles in our development but adjusted it to work with our busy schedules. As Fullerton outlines in chapter 13 of Game Design Workshop, the three critical principles in Agile methodology are working in sprints, holding scrum meetings, and prioritising features.

Sprints

Sprints are a fixed-length goal, measured in weeks, to complete an iteration of the game. In Boat Slalom, we essentially had one, roughly 2-week long sprint in which we determined the deliverables and developed the prototype to be ready for testing. I was the lead developer in this project, and although I was able to put aside 2 weeks to focus on this unit solely, it was definitely overwhelming at times. By the end of the sprint, the Boat Slalom prototype was complete including all initial deliverables and more.

Meetings

In the beginning stages of development, we would meet as a team in a voice call for a few hours. In this time, we’d flesh out our idea and discuss the list of features we want to implement. Later on, once we’d begun development, we would stay active in the discord text channel. I’d post major development updates, ask for feedback regarding certain implementations, and post about any issues I’d encountered and offer possible solutions. The team was engaged and messaged on a very regular basis. There weren’t strict meetings in a timeslot where each member would discuss their goals and completed tasks. It was far more casual but still on a consistent basis. Even multiple times a day. The positive things about this system were that each member was involved in the development process through the feedback they’d give. Often times I would miss a bug or not have time to test something properly, but the team would pick up on it. It’s preferable to doing larger updates spaced apart, missing something crucial and having to spend more time fixing it. The downsides are that with this consistent communication and testing, the list of tasks grew and grew.

Priorities

In more serious Agile development project, the project manager or producer would decide on which features would be prioritised. We’re a small team and didn’t have a single person acting as a producer. Instead, we all offered our input. The team had plenty of ideas. As the lead developer, I would give my input as to whether or not something was possible to implement (technically) given the resources and timeframe.  

In the beginning, we decided on a seemingly reasonable set of deliverables. As we developed, we’d do some casual in-house playtesting after each major update (the project ended with 30 versions, so there was quite a bit of testing). Each time we’d test, my list of tasks would grow as team members would suggest additional features to add. Although I was excited about adding more content, we did have a deadline and there’s only so much we can do within that timeframe. I was accommodating but transparent when I didn’t believe a feature could be implemented in that time frame. Some features which were a big task but could possibly be implemented became stretch goals.

Looking back, I think FAR too much time was spent on implementing the menus. Boat Slalom requires the user to select a boat and a race before they can play. They also need to create a username for the scoreboard. Players also unlock a new race after completing the first one. This means a lot of scenes, and checking the value of certain variables to activate other scenes. This list of scenes is necessary and each item is an important part of demonstrating the core functionality of Boat Slalom. Later on in development, when bugs and other enhancements to the menus were mentioned, they’d be placed lower on the priority list. After all, the focus of the assignment is to prototype the gameplay.

What would I change?

If we could restart this project, given our timeframe and objectives, I would highly prioritise gameplay from the start. I’d remind my team that the menus are still important, but that we should focus on the game elements. I feel like we didn’t focus on these elements enough, specifically conflict with our obstacles and level design.

I’d continue being accommodating but honest when a feature is out of scope. I was ambitious and accepted too many tasks, so I’d probably be a little less accommodating unless a feature was necessary.

I’d ask for more help. When deciding on deliverables, we somehow forgot to discuss menus. We knew what we needed menus for, but didn’t discuss navigation, appearance, etc. Most of this work fell on me to decide mid-development which resulted in a lot of extra work and wasted time. Towards the end, I asked Bree if she could create a skeleton scene for the tutorial and place the objects where she’d want them. I later readjusted and coded the page to function properly. This saved me some decent time, and since she had the time, she was happy to help out! I think next time, I’d like to recognise situations like this and seek help from my team instead of giving myself the extra work when there are other tasks to prioritise.

Overall, creating Boat Slalom was probably the most fun assignment I’ve done during my time at uni. The team was solid and communicative – not something you see often in uni group assignments. We had some great times and even some laughs. I’d be happy to work with my team again 😊

References

We made some small changes to the prototype before submission. Here’s a gameplay video that shows the final version of Boat Slalom!

We didn’t make too many changes. Some of the changes we’d like to make simply require more time and we’re limited by the deadline. Below I’ve outlined the changes we did make and some other changes to consider in the future.

Health – Visual Cues and UI

Players struggled to recognise when they’d lose health. There were two approaches to fixing this issue – 1) modifying the UI so that health is more visible, and 2) making the visual cues more obvious when a player takes damage. The current version of Boat Slalom has only 2 damaging obstacles – rocks and sharks. When we conducted our formal playtesting, shark collision had no visual indicator that health was lost, and many players didn’t realise that they were damaging. Shark collision visual effects were not prioritised for the submission - we simply had more important features to work on.

To fix this, we temporarily added the same visual effect from rock collision. Bree created an asset that showed a shark head rising from the water. We were hoping to combine this with the current effect so that it’s even more of an obvious visual indicator, but simply didn’t have time.

Alongside visual indicators, we decided to alter the UI. A player said that they felt like they couldn’t look at the UI so as to not distract from the game. We increased the size of the health portion and also repositioned it. By increasing the size, it’s more visible and obvious in the player’s peripheral vision.

Here’s a comparison of the UI. This is before:

And here is after:

Difficulty

Players felt that Rivers Regatta track 3 was far too difficult compared to previous tracks. Unfortunately, we didn’t have precise data about the specific sections in part 3 that players struggled with. Initially when we were creating the level, we purposely wanted it to be difficult and added extra obstacles with a focus on creating tight lanes and sharp corners. To make the level less difficult, we removed some obstacles and created some extra space so that navigating through the level wasn’t so punishing. The screenshot below shows the same section before and after revising the level. It may not be immediately obvious, but the player doesn’t have to make as many sharp turns to successfully navigate through the section in the revised level.

Leaderboard

The prototype leaderboards use hardcoded, placeholder track times. Players felt unsatisfied when they’d complete the track, dodge all obstacles, but still achieve a poor time (compared to the hardcoded times) due to moving too much. We decided to increase the range of hardcoded times to cater to all types of players. The top time will still be competitive, but the remaining times are more “beatable” and not so punishing for moving too much. In further iterations, the leaderboard will be implemented properly online and also have more time slots to compare to.  

Hitboxes

The hitbox on boat 1 was larger than it should be. It was most noticeable in Beach Days 1 with the moving sharks. The player would obviously dodge them but still take damage. This hitbox has been appropriately modified to be in line with the art asset.

Menu

Menu fixes were the lowest priority - the actual game was more important. We changed the tutorial page background so that it’s more fitting with the rest of the game aesthetic. Some users also struggled with the username section, so we made that more intuitive.

Future Changes to Consider 

Movement

This was a common issue with our playtesters, as discussed in the previous post. We want to keep this mechanic as it is because it has plenty of benefits. It diversifies times, gives players an added resource to monitor, and creates more dynamic gameplay which can benefit more competitive players.

However, there are ways to make the movement FEEL less punishing. Perhaps this can be done through the art assets or particle effects. The animation could either look like it’s speeding up so that players don’t feel slower. Alternatively, the animation could have the person in the boat using their paddle to move and possibly create waves in the water – this would communicate to the player that the person is moving sideways, water acts as a resistance and therefore moving a little slower is bound to happen.

Alternatively, we could add some sort of stamina bar in the UI. When moving left or right, the bar resets. As it fills up, the player has slightly slower movement. When it’s full, the player is at full speed. This could be another way to visually communicate to players that this is a mechanic/resource that you need to consider.

It could also be something to include in the instructions page. A reminder that the player should manage their movement if they wish to achieve the best times.

UI Additions

We want to give players more information about their progress in the race. We’d like to implement a bar in the UI which acts sort of like a minimap and updates to show the players position in the track and how far they are from the finish line.

Arcade

As mentioned earlier, the group work was split such that I’d lead the technical implementation while the rest of the group would lead the playtesting and data analysis. As such, I wasn’t involved in formal playtesting. The only playtesting I personally engaged with was during development when myself and the team would test and adjust the prototype accordingly. I can’t say much about the formal playtesting process itself, but I can discuss the data we collected.

Our formal playtesting involved 6 participants, namely fellow students, family and friend. We used 3 methods to collect data about our players and their experience with Boat Slalom. These included:

Player survey. This was completed pre-testing to gather data about our participants. Notably their experience in games, preferred platforms, and favourite genres.

Questionnaire. This was used to gather player feedback after testing has been completed. These questions aim to understand the player perspective. Included is a section where the player rates the game elements such as controls, visuals, audio etc.

Playtesting notes. During the testing session, the team would take notes about the player and their interaction with the game. What are they doing and how are they interacting with the game elements? Are any parts of the game frustrating? Were any parts of the game unintuitive?

I’m not going to present all of our data in an effort to prevent this post from becoming an essay. However, there were some findings which I think are worth mentioning.  

Player Demographics

Below is a chart from our player survey which shows the gaming platforms our players most regularly use. Players could select multiple answers.

The player survey revealed that 50% of our participants regularly play computer games. From our 6 players, 66.7% play mobile games regularly and 33% of players selected mobile games exclusively. Boat Slalom is designed for PC so it’s possible that our mobile only players will have a different experience with controls or possibly a differentperception of difficulty.  

The next 2 charts show player enjoyment in other racing/runner games. The scale is 1 = Strongly Disagree and 5 = Strongly Agree.

Evidently our players do not enjoy games similar to Boat Slalom. Chapter 9 of Fullerton’s Game Design Workshop suggests that the ideal playtester identifies with the target audience and has an interest in this type of game. These players can compare Boat Slalom to other games in the genre and make relevant comparisons. The fact that most of our players do not belong to the target audience is not ideal but we didn’t have much choice for playtesters, most of which were fellow students and family/friends.

Playtesting – Common Issues

The playtesting notes are plain dot points written in a document as the tester is playing the game. These notes included what the player is actively doing and comments they make out loud. Here’s a snippet of the notes we took: 

We later highlighted certain notable points and colour-coded them according to the category they fit e.g. green = problems with movement, blue = perceptions of difficulty, purple = situations where perhaps visibility or the UI were unclear, and the player was left confused. The common issues we noticed were:

UI and Visual Identifiers

Often players would lose health without noticing. Common frustrations were that losing health was not obvious enough. The UI was not noticeable enough. One player said they feel like they will die if they look away from the screen.

Obstacles

Oil spill

Players expected the oil spill “slow effect” to clear once they’re no longer in collision with the object. Currently, collision will apply a slow effect for 4 seconds.

One player stated that the hitbox felt off. They were slowed down even when they didn’t touch the oil spill.

One player didn’t understand the function of this obstacle. Initially expected it to apply another speed boost.

Whirlpool

One player expected their health to decrease by hitting a whirlpool.

Sharks

Players didn’t realise that sharks decreased health (these did not have a visual indicator at the time).

Difficulty

Rivers Regatta track 3 was difficult for a lot of players. Some players tested RR3 with full visibility since the computers were not running a compatible version of Gdevelop that worked with lighting effects. The players that tested with the lighting effects applied would lose all health and need to restart the level. Some died multiple times. This became frustrating to them. One player noted that it was “a pain”. Another player said “I want it to end”. Although the tracks are supposed to increase in difficulty, our data shows that this track was definitely overtuned.

Movement

This was by far the most common issue and also the most perplexing to me. Players expressed frustration that moving side to side slowed them down. One player thought it was “unfair” that they “did everything right” but still achieved a slower time.

Despite the fact that this is how real world physics work, moving at a constant speed when turning is not common in competitive racing games. If this movement penalty didn’t exist then players would achieve identical times (assuming no obstacles were hit).

I believe this feedback to be the outcome of our playtester demographics and how they do not align with our target audience. Players that have experience with racing games understand that movement is another resource to manage. Instead, our testers considered this a flaw and it became a point of frustration for them.

Playtesting - Quantitative Data

I’d begun implementing a method of recording quantitative data during our playtests. Data such as chosen boat, times per tracks + overall times, and a recording of obstacles hit, their precise x,y coordinates and timestamps. Gdevelop would write the data into a plain text file as the game is being played. I believe this data could be beneficial when it comes to balancing our game.

Since our tracks are deterministic, it would be interesting to see if there were any specific obstacle positions that players would hit regularly. We’ve had major issues with River Regatta track 3 but have no record of which obstacles and locations were problematic for players and so balancing won’t be as specific.

Unfortunately this function was not top priority and was not completed. If we had more time, or if this were a larger development project, this data would be a valuable tool for balancing the game.

References

Throughout the development of Boat Slalom, i’ve not been fully satisfied with how the water looks. It’s proven to be quite difficult to make realistic looking water in a top-down, 2d space. I came across this video by Michael ‘Jasper’ Ashworth which explores how Nintendo created some incredible looking water effects using simple techniques, namely displacement maps and layering. I figured I’d try applying these techniques in Boat Slalom using Gdevelops layer effects.

I think it turned out pretty cool. For reference, here is how water normally looks:

Here is how it looks with the map displacement visual effects applied:

Maybe it’s a bit messy but it adds dimension to the water. I used a displacement map on a water texture, changed the opacity and then layered it over the river asset. The river asset also had a displacement map applied to create the dips and imperfect lines. Then to give the illusion of moving water, we need the scrolling aspect. I added a constant force to the texture and that’s it! I got a bit overexcited and tried my hand at some more dynamic oil spill animations while I was at it. I added a map displacement to these as well to make them look like they’re moving with the water.

I considered other ways to add some dimension and excitement to the tracks. I found some nice droplet animations and combined them with a particle object to give the effect of rain. I also tested the recently added light object, and was really happy with the results. I pitched the idea of having a night mode for one of the tracks to my team and they were really pleased with how it turned out. 

In fact, we liked this effect so much that we decided to incorporate light as an element to control difficulty in our final track of race 1. The player has a small radius of light around them which makes it harder to see the obstacles up ahead. Specifically oil spills.

This turned out to be my favourite level. It’s satisfying looking back at earlier versions of the prototype and seeing how far we’ve come in terms of gameplay but also the visual experience. This level is proof in my opinion. 

Initial Playtesting

We’ve officially completed the development of this first prototype and have started some playtesting with classmates during the W12 tutorial. Since I was mostly involved in the technical development, my teammates are taking the lead in the playtesting and analysis. We are currently still in the testing phase but our initial testing in class was really positive! I’m interested to see what other feedback we get and will discuss this in a blog post once we’ve finalised our playtesting.  

References

Deterministic Tracks

So pre-determined tracks turned out far easier than expected. Using Gdevelops grid system and temporarily adjusting the visibility of our assets, we were able to set up a pretty simple and adaptable environment for building a track. It honestly turned out to be far less tedious than the randomly generated tracks AND the tracks were now deterministic for the players – far more appropriate for a racing game. It was a win-win situation.

With the new system, we were now able to create some more complex and interesting sections in the race (as seen above). There’s suddenly more freedom to create paths and conflict for the player. One idea is to have 2 defined paths. At some point the player needs to choose – left or right? The player chooses left but a little further up, they learn that the set of flags was on the right path. Now they suddenly have a competitive edge for the next time they play this track. If they can remember which path to take, they’ll be rewarded with a speedboost which gives them a slightly better time. In a randomly generated track, this wouldn’t be an possible.

Movement Revisited

In the meantime, we’ve updated our assets, environments, added some nice UI elements, a countdown at the start of a race and even some animations when hitting rocks. The game is coming together. However, when doing testing amongst ourselves, we realised that this movement is feeling pretty unfun…

It’s alright, but not particularly challenging. Movement feels basic and is possibly too forgiving. The player can move around as much they want without consequences. The only action that ensures a worse time is hitting an obstacle. We decided to do a super quick mockup of the movement from the initial prototype – the player has more freedom and isn’t locked into 5 distinct positions.

Everybody instantly agreed that it just felt more fun. There’s suddenly an added element of challenge. To dodge an obstacle, you need to actually move out of the way of the obstacle. Previously, you just had to tap a single button and you’d be saved from hitting that obstacle. The act of moving left or right temporarily slows down the player, as they’re now moving at the same speed but at a diagonal. This punishes too much movement – the player has to think carefully about how much they want to move around an obstacle. It was overall a massive improvement and I think it’s noticeable when comparing the two gifs.

Durability 

The prototype is really starting to come together. With this update, we also added a durability system, similar to total health or lives, which can be seen in the UI beneath the flags counter. The player starts with 100% durability and each time a rock is hit, it’s -10% to durability. At 0% durability, the player loses the track and needs to start over. This is up for discussion – we’re considering going with lives instead and adjusting the durability for each boat. Currently the boat can take 10 hits before losing which is quite generous.

Menus and Navigation

We’ve got some general menus set up.

We’ve started developing our prototype. Gdevelop doesn’t have any satisfying answer for version control so having multiple people work on the game at the same time is frustrating. We decided to store our game files on google drive, while documenting any changes in a changelog. Each version we upload remains untouched which proved to be really handy later on.

Locked-on Lane Movement

We started with implementing basic movement. We wanted to create 5 lanes which the player can move through. Defining x-coordinates for each lane is necessary so that we can spawn obstacles appropriately without any overlap. Since we weren’t sure on how wide we wanted our lanes to be or where exactly to position them, we made 5 scene variables to store the x-coordinate for the center of each lane. All throughout our events, we’d refer to these lane values instead of hardcoding coords – it saves a lot of time if we decide to go back and change them around. Spoiler alert: we went back and changed them. 4 times.

This is how the movement looked in Lauren’s initial prototype.

This is the first version of our lock on lane movement.

Obstacle Spawns

With the lane system set up, implementing obstacles and flags was really simple. A random number (between 1-5) is chosen and the obstacle is spawned in the corresponding lane. Technically, the obstacles are moving at a constant rate down the screen while the boat is only moving left and right to avoid them. The boat looks like it’s moving upstream and that the obstacles are stationary, but it’s an illusion – the boat is only moving left and right. This means that when the boat is blocked by a rock or stunned by a whirlpool, we need to temporarily pause this movement. The problem comes when we have speed variations in the speed boost (increase) and the oil spill (decrease) where we need to change the rate at which these objects are moving (and also the rate at which they spawn - another issue). The most elegant solution is to change the time scale when the player interacts with these objects but we can’t do this. We have a timer that needs to precisely record a players track time and changing the time scale would affect this. As far as we know, there’s no way to exclude a specific timer from timescale changes. We introduced a “speed” variable and yet again more timers. If the player interacts with a speed boost/oil spill, the speed variable adjusts during the timer and then returns to normal at the end.

(Problematic) Obstacle Spawns

At this point we’re randomly spawning 3 obstacles and a set of flags. All of these run on their own timers, so we had to find a right balance in spawn timings. The problem with adding more randomly generated objects is that the timers need to be set in a way such that they don’t all reset close to each other or at the same time. We end up with situations like this:

We suddenly have a space packed with objects, followed by a lot of empty space before objects spawn again. There’s also something unnatural about this kind of spawn pattern – they’re almost perfectly aligned. A solution to this would be to add another level of randomness through the timer! For example, each obstacle can spawn anywhere between 1 and 3 seconds. This gives some extra variation to the spawns and doesn’t consistently group objects together.

We’ve added some assets as well as basic implementation for all 3 obstacles and flags. Here are a couple of screenshots that are very unfun.

And even worse:

Which leads me to the next notable section...

Intelligent Track Generation

With random generation, we need a set of rules to somewhat control the randomness. In the cases above, obstacles should not spawn right on top of flags, and flags should not spawn on obstacles. We started by implementing a check each time a new obstacle spawns. Is this object on a flag? If yes, reroll and respawn in one of the other 4 lanes. Is this object too close to another object? Yes - reroll and respawn. Eventually, we end up with multiple checks for spawns for multiple objects.

At the moment, obstacles are spawning sparsely. The track doesn’t feel particularly challenging. However, increasing the rate at which objects spawns does something unintended. We suspect that the problem lies in having multiple timers for creating objects, multiple collision checks, and simply too many variables adjusting these times. Increasing the rate at which everything spawns and moves is causing obstacles with bad initial spawns to not respawn correctly. I could foresee an issue where increasing the spawn rate in higher difficulties will cause completely impossible routes for the player – they’ll be stuck in an area confined by obstacles with no way out, and if we’re already having so many problems with controlling spawns, it’s just going to become even more problematic. 

We could change the spawn approach and recreate some traversal algorithm (in Gdevelop 🙄) to ensure that there’s always a safe route for the player to go through. This seemed like a lot of extra work for something that will potentially remain broken. We concluded that this was simply giving us a lot of extra, unanticipated work.

It’s time for Assignment 3! We’re forming a group and collectively deciding on a game idea to iterate on. Then for the next few weeks, we’ll work together to develop our prototype, conduct some playtesting and write up a report. Forming groups can be awkward but I ended up with a fun group of people and our skillsets balanced out.

We decided to go with Lauren’s game idea – Boat Slalom. Ultimately a racing game but you’re controlling a boat through water and need to avoid obstacles along the way. The goal is to compete the track in the shortest amount of time. The team collectively agreed that this game idea had the most room for growth. We spent the first meeting discussing the idea and how we want to expand on it. We decided to implement the following for our first prototype iteration:

Obstacles

Rocks - block the player from continuing down that lane. Must move around it

Oil Spill - temporarily slow down the player

Whirlpool - stuns the player and spins them around for a short duration

Flags

 Provide the player with a temporary speed boost

Boat Types

Two different boat types, each providing an advantage over the other. Stats to consider are movement speed, size (affects how easy it is to hit obstacles), recovery (affects duration of stuns and slows)

Level

  3 levels, each increasing in difficulty. 

Difficulty is increased by number of and positioning of obstacles throughout the track.

Leader board

Temporarily hardcode values to simulate a leaderboard. 

In later iterations, the leaderboard will be implemented using a proper solution.   

One major design decision is player movement throughout the track. Lauren’s prototype is using free movement for the boat. We all agreed on implementing a locked-lane style, similar to Subway Surfer, which restricts the player into a number of lanes. We decided that 5 lanes is a fair amount to start with.

At this point in the semester, I’ve completed 3 prototypes. Assignment 2 had us choose one of these prototypes (or come up with an entirely new game idea if we wished) and develop a set of design documents consisting of a one-sheet and a one-page. These documents will later be used for Assignment 3, where we pitch our idea to the rest of the class, form groups and work on one of the presented game ideas.

Out of the 3 prototypes I developed, Glitch Force was the most intriguing to me. I’m drawn to the idea of a fast-paced, top-down shooter and I felt that Glitch Force had the potential to become this. I chose to iterate on this idea as I felt the original premise was too simple. In hindsight, I regret doing this as the idea I’d built up in my mind wasn’t properly considered or communicated.

The purpose of the one-sheet is to communicate the vision of the game. It needs to capture the attention of the viewer but not overwhelm them with too many details. Most examples of one-sheets are filled with imagery as opposed to lots of text. This is the final one-sheet I included in my submission:

I struggled with communicating the idea of my game, visually. For one, Glitch Force employs a mostly abstract and simplistic art style. I wanted colours to be plain and sparse but to also utilise small, vivid pops of colour. Most one-sheet examples I’ve seen have been loud, bright, and full of imagery. Towards the end, I worried that the style was far too simplistic and didn’t communicate the game vision very well, especially compared with the one-sheets of other students. Some of them had drawn up custom art and they were very impressive!

The one-page felt more manageable since the content is instructional and descriptive, compared with the one-sheet where the chosen text was more about selling your game in a creative way. This document is given to the developers as a sort of “blueprint” to building the game. The idea is to describe the main elements to help the developers understand how to build the game. This was the final one-page in my submission:

Although I initially felt comfortable with the one-page, I quickly learned that I wasn’t confident in my game idea AT ALL. I had a vague understanding of my idea, but I hadn’t fleshed out some important aspects. I hadn’t considered the layout of the levels, specifically the enemies and how they’d interact with different obstacles. I kept thinking about incorporating the asteroids in some way because those were fun to shoot and the concept felt a bit plain at the moment, but it just didn’t make sense with the rest of the concept. In the end, I felt that my one-page communicated a game that didn’t seem fun. I kept wishing that I’d prototyped this version of Glitch Force since it was now an entirely different game from when it started.

Here’s the final prototype. I didn’t get a chance to test it with my peers, but I did get some feedback from a friend.

For the playtesting process of this prototype, I reflected back on Chapter 9 from Fullerton’s Game Design Workshop – which I wrote a blog post about here. With this prototype in particular, a fresh perspective felt important. I took a more observational approach with this test.

Unclear Instructions

On first playthrough, the tester immediately ran into the structures and subsequently died. The player wasn’t sure what they were doing and mentioned that “the point of the game is unclear”. I explained the basic point of the game and they understood. For the next few playthroughs, the player would collect the pigs and then try and run head first into the structures again. It wasn’t completely clear that the head is vulnerable and can’t collide with anything – you have to position your tail to destroy the structures. Having to explain this to the player a few times solidified that the idea is convoluted.

Solutions:

Change the objective of the game. Instead of destroying structures, maybe simplify it so that the idea is to avoid structures altogether.

Keep the objectives but introduce the instructions in a menu, or in the beginning of the game through some kind of tutorial

Movement

The player initially complained that the movement felt awkward and uncomfortable. I asked if they could elaborate on this and they mentioned that it felt bad not being able to stop the “snake” from moving, that it just moves continuously. This didn’t sound right to me – this is something I definitely identified and specifically modified. It turns out that the player would press capslock occasionally which would break the movement of the snake and have it move continuously for the remainder of the game. Once we identified that this was an issue, the player played a few times without pressing capslock and said that it was an improvement.

The player voiced frustration that when you’re facing one direction and press the key for the opposite direction, you continue to move straight. This is a limitation of the “snake” movement implementation. This is an issue I encountered a few times as well, and it does feel awkward.

Solutions:

Identify cause of movement breaking bug.

Change the movement actions so that facing a direction and pressing the opposite key will move you backwards.

Game Pace

The player strongly believed that the pace of the game was too slow. I quickly changed the speed variable so that it was ~2x as fast, then had them try that one out. Interestingly enough the player preferred it, but would die far more often by crashing into the sides of the field.

Solutions:

Consider balancing speed variable. Increasing speed may require readjusting spawns, and possibly field width.

Consider balancing structure spawn frequency. Having structures spawn more often means that the player has more obstacles to keep in mind. A slower pace is beneficial in this situation.

Further Development Ideas

Remove “rhythm” type movement and have smoother, less jarring movement.

Let the player move upwards and go back through the level. However, this would eliminate the endless running part of the game.

Include archers or other projectile shooting enemies. The player would be required to shield themselves from the projectiles using their minions. (this was an idea I initially wanted to include, but I’d already spent too much time on this prototype)

Spawn structures in groups to act as little towns. Include archers and other enemy types within these groups.

Conclusion

Something went wrong with my original file and I couldn’t fix it. I decided to start over which was an arduous task, but I finally managed to get the game to the stage it was before it broke.

The core of the game is there. The level is procedurally generated and is able to self-moderate. The “snake” works as well as it can at the moment. After spending a few hours staring at the moving squares on the screen and having to adjust my eyes to the movement layered on movement, I developed a migraine 😡 No but seriously, I’m interested to see what my playtesters think. I believe the movement needs a bit of work.  

What’s left is adding some art so that the game actually fits the theme. I used the Urizen OneBit Tileset and the Abaddon font. The paths looked too plain with just a single square so I added some grass sprites to the field and played around with adding some randomly generated forest on the outsides of both paths.

This was also somewhat procedurally generated, but limited in the implementation. Basically, when creating a new square, a random number within a range is chosen and that many trees are created next to the square.

Next, I added the structures (houses and signs) and added a collision condition. If a “tail” object collides with a structure, destruction rating goes up. If the “head” collides with a structure, it’s game over. I wanted the structures to spawn in groups close to each other, to look like little towns, but I’d already spent too long on this prototype with the rebuilding and all. This is definitely something I’d leave for the next iteration!  

This week we were tasked with creating a racing game – essentially an endless running game. I don’t have much experience with these games which is the perfect excuse to experiment. All I knew was that I need to have some continuously moving, linear level. 

In summary, the game idea was this: imagine Snake but instead of being confined within 4 sides, the environment is constantly changing, and the player has to adapt while being mindful of their “tail”. The setting of this level is a town surrounded by forest. There are two, continuously moving paths that represent the bounds of the field. The player plays and moves in the field created by these two paths.

Procedural Generation

Straight off the bat, I wanted the level to be procedurally generated. The pace of the game is supposed to be almost rhythm-like, similar to traditional Snake where the snake moves one “square” at a time as opposed to moving smoothly. The entire environment will also move downwards one square at a time which creates the illusion of a continuously moving level. The entire level is essentially a massive grid and each of the environmental objects will move down one square each time. The cell dimensions are 24px by 24px and the timer is set to move everything every 0.3 seconds. Each square in the environment is made on the same y-axis which is -48 and appears offscreen.

I started off with creating one of the path sides. I wanted to get the procedural generation aspect right before introducing the other path and the rest of the environment. I’m sure there’s a more sophisticated approach to this, but mine was quite simple using the RandomWithStep function.

A square is created, and its x value position is recorded in some variable “z”. The next square has 3 possible spawn options – same position (z), to the left (z – 24), or to the right (z + 24). The RandomWithStep function takes a minimum value, maximum value, and a step value. The minimum here would be z – 24, the maximum is z + 24. With the stepsize set to 24, the function can choose one of 3 options. This repeats itself and the result is a randomly generated path which can be seen here:

This path generation isn’t particularly intelligent. There are currently no rules in place to prevent the paths from merging, becoming impossibly narrow, or even from straying offscreen.

There are two main situations that could impact the intended functionality of the game and essentially break it.

The paths stray offscreen.

The paths merge.

Controlling the paths and preventing them from moving offscreen was simple. I chose two points on the screen to act as a boundary. If the square reaches this boundary, then 24 is added to the position variable “z”. This prevents the path from ever moving past this boundary.

Preventing the paths from merging was a bit different. The rule here is that the two paths must be greater than 12 squares (288px) apart. If the difference between the left and right path x values is 288, then 24 is subtracted from the left path and 24 is added to the right path. This temporarily widens the field on both sides and prevents the paths from creating a too narrow field or merging. I played around with different values, and 12 squares seemed appropriately challenging.

Movement and Player Control

Once I implemented an actual “snake” head and tail, the game started coming together. While doing some playtesting myself, I realised that this idea sounded interesting on paper, but actually feels really awkward to play. In traditional Snake, the snake is constantly moving. In a traditional endless running game, the background is constantly moving. When you have a constantly moving object on a constantly moving background, the forces don’t make much sense. The snake and environment move at the same rate, and the environment can ONLY move downwards. If the snake is also moving downwards, then it looks like it’s standing still. If the snake is moving upwards, it looks like it’s moving twice as fast. If the snake moves left or right, it looks like it’s moving diagonally. Not to mention, since the snake is constantly moving, it feels natural to move upwards. But there’s only so far you can go before you have to turn around and move downwards again. All of this combined felt awkward and unnatural to play.  

Traditional Snake and endless running didn’t quite work out, so I thoughts I’d try some modifications. The player doesn’t have much control in its’ current state. They can only control which direction they move in. It’s difficult to set themselves up for fruits and if they miss one, there’s no way to obtain it since the environment is moving against the snake. 

I tried a few things and decided to stick with them.

Removing the constant force on the snake. The player can decide when they move.

Giving a speed boost to the snake only.

Playtesting should be done throughout the entire design process to ensure the game is functioning as intended.

Consider development as a continual iterative process:

 playtesting --> evaluating -->  revising

If you wait until end of the development cycle to test, it’ll be too late to make any fundamental changes to the game.

Self playtesting is beneficial in the early stages of development when you’re setting up the fundamental mechanics. Having others test your game brings about a fresh perspective and can help identify any aspects that the designer may not have considered.

Having friends or family playtest the game can affect results. Typically, the people you have relationships with could be either too harsh or too forgiving. Playtesting with strangers removes these personal ties and offers potentially more genuine criticisms.

The ideal play tester is someone that identifies with the target audience of the game and actually has an interest in this type of game. Someone who may have experience with other games in the genre and can provide relevant feedback through comparisons.

To get a completely fresh perspective, it’s ideal to begin the playtest without revealing too much information. An interesting way to approach this is to remember that if the game goes public, you (the developer) won’t be there to explain it to each player. It’s important to observe the testers and their natural impression of the game. If rules seem too convoluted, confusing, unintuitive, then consider changing those elements in future iterations.

References

To ensure the game is functional, complete, and balanced, the playtesting process can be broken down into several phases. The foundation phase is concerned with making sure the game is engaging and has the potential to reach player experience goals. The idea is to test the core system of the game to ensure that it makes a solid foundation for further development. Next is the structure phase - introduce enough structure to make the prototype functional for playtesting. This includes introducing rules and other procedures so that playtesters can have some understanding of the game without knowing the full extent of the game vision. Following that is the formal details phase. If the structure phase seems promising, then the next phase is to focus on making the game functional, internally complete and balanced. These can be summarised as:

Functional

Can the player interact with the game without aid? Ultimately, it depends on what the goals are for that specific playtest. If we’re testing a specific feature, can the player meaningfully interact with this feature? If the player can make progress in the game without guidance from the developer, then the game can be considered functional.

Completeness

If a player reaches a point in the game where the rules are questioned or there’s a dead end, that section is considered incomplete. Rules and procedures that are defined on paper can sometimes lead to grey areas when implemented. These are identified through playtesting and can be hard to anticipate otherwise. Ultimately, if the players can play the game without the intended functionality of the game being compromised, then it can be considered complete. Realistically though, it’s difficult to say a game is ever complete, or rather, it’s complete until a flaw is identified.  

Balancing

Balancing is the process of ensuring that the system elements work together to meet the goals set for the player experience. This involves making sure that the complexity of the game is in line with the game vision. Issues of balance can be a very difficult aspect of game design.

Changing game variables can ultimately change how the game is played, how engaging it is, how difficult it is. An example is a game in which you start with a set of lives. Starting with 1 life means the game can be too hard. Starting with 10 lives can weaken the feeling of challenge – maybe the game feels too easy. The ultimate idea behind altering and manipulating these variables is to create the player experience you’re trying to achieve.

A game system is made up of many smaller, interconnected systems. Changing one system can affect another system. That’s why when it comes to balancing, it’s important to consider a modular approach and change one element at a time. It may seem inconvenient, but changing multiple elements at a time can make it harder to understand the effects on the system.

References

When I was working on the asteroids prototype (Glitchforce), I decided to map out the formal elements of the game. I found this pretty helpful when I was moving from the conceptualisation stage to actually implementing things. I decided to do the same for this prototype:

Fiend - Formal Elements

Players: Single-player.

Objectives: Destroy as much of humanity (houses and other structures along the path) as you can. Each structure destroyed adds to the overall player destruction rating.

Procedures:

Player controls the movement of the Devil (WASD).

The players’ army of minions increases each time they collect a pig.

Player destroys the structures by positioning their minions such that they collide with the structure. Destroying a structure increases overall player destruction rating.

Rules:

Minions get lost in the forest. If a minion collides with the inner forest path, the size of your army decreases by 1.

The Devil is weak. Colliding head-first with a structure or the inner forest path results in instant death.

Colliding with any part of your minion army is acceptable and even encouraged in certain situations e.g. when the player is too close to the forest path and needs to move inwards to protect their minions.

The Devil can hide behind his minions to protect himself from incoming damage.

Resources:

Pigs (collect to increase army)

Minions (manage appropriately to protect yourself and destroy structures)

Conflict: Obstacles – forest path.

Boundaries: The player is visually bound by the changing size of the forest path.

Outcome: The player accumulates as high a destruction rating as possible.

References

Game Title

Fiend

Pitch

Play as the Devil and build an army of minions to do your bidding. Use them to destroy the structures around you, or to shield you from incoming damage. You’ve been sent here to wreak havoc. Destroy at your will!

Unique Selling Points

Procedurally generated path and terrain

Experimental gameplay – a mix between the endless runner (racing game) and the classic Snake game types

Old-school, roguelike dungeon type of aesthetic

Control Scheme

WASD - to move

Here is the final prototype I submitted for playtesting. There’s still a lot to be done in terms of balancing, but I’m happy with the prototype overall. I think it successfully captures the essence of a somewhat bullet-hell type asteroids game that I was going for. 

Like last time, I didn’t get much play testing done. I was hoping to get more feedback regarding the pace and difficulty of the game since I still need to work on balancing, but all of my playtesters have been so polite with their comments!

I got a lot of positive comments about the theme and aesthetic design choices. There was some confusion over the function of the bullets and the missiles. The initial idea was that explosions would award less points per asteroids since they can hit more asteroids at once than the bullets. I forgot to actually code that in, and one of the playtesters that was primarily using the rockets commented that they weren’t getting any points, oops 👀.

I was able to spectate one of my play testers as they played. Initially, they kept trying to shoot at the enemies with their bullets but they quickly realised that the enemies could only be destroyed with the missiles. Another one of my play testers commented that they also didn’t realise this immediately. This is a concept I would introduce to the player in a tutorial, or on the main menu before the game starts, but I didn’t have time to create that. 

Here’s one piece of feedback I wanted to highlight: 

The bullet trails were an awesome addition that made the bullets ‘feel better’? 

This is absolutely why I added the bullet trails! The visual feedback for the player makes their shots possibly feel more powerful. My previous post here goes into a bit more detail behind this design choice. 

On Balancing

Regarding balancing, one of my playtesters said that they liked the fast-paced nature of the game and the incremental speed upgrades. However, they reached a point where they had fully upgraded their damage (5 projectiles) and kept collecting speed upgrades (which I hadn’t put a limit on in the prototype). They were clearing the entire screen VERY quickly. 

This was where I realised that to properly balance my game, I’d need to test it considerably. With different types of players. In its current state, the game doesn’t actually increase in difficulty fast enough to align with the power upgrades.Every 60 seconds or so, the enemy spawn rate increases but they’re too easily destroyed. If I were to further iterate on this prototype, i’d definitely increase asteroid spawn rate and asteroid movement speed as time increases (this shouldn’t be complicated). Ideally, i’d introduce health to these objects so that they’re not destroyed in one hit. Alternatively, the power progression could be slowed down. I did play around with this on my own, and I feel like it’s at a good spot right now.

Further Development Ideas

With all the base mechanics in place, my next steps in exploring this game would be:

Introducing health to asteroids/enemies. This would mean that an object would have to be hit more than once to be destroyed. Perhaps health could scale with time - as time goes on, objects have more health and require more damage/speed upgrades to destroy. 

Another powerup which adds a turret to your ship. Each turret would fire additional projectiles and essentially be a damage upgrade to the player. The turrets be destroyed by enemy projectiles so the player has to be careful with their movement. 

Adding more asteroid types: alternate sizes, speeds, health values. Maybe some asteroids could be invulnerable and must be avoided by the player. This could act as an alternate type of obstacle.