Assignment 3 Postmortem

Our third assignment is now completed and the game is in its final form, and ready for submission.

Tracy Fullerton's ideas on iterative video game design were extremely helpful when approaching our playtesting and changes. Her cycle of test, evaluate, and revise, perfectly encapsulate our approach to improving on our feedback. We went through around two cycles of this, beginning with our initial, informal testing - after which we iterated to a cleaner version of our Minimum Viable Product that we then utilised for our second round of formal playtesting. Making additions and iterations based on what players discovered.

The creation of our prototype was relatively smooth, thanks to the work of our teammate the game was already in a very playable state and the subsequent work made on the game was largely iterative. The largest issues with workflow actually came from limitations with the GDevelop platform, which made it very difficult to have multiple people working on the prototype. It essentially forced us to have only one person working on the project at once, which made it very difficult to have everyone contribute in any sort of meaningful way, or have someone simply decide to add new features on their own time because it required that they have the current version of the game.

This key limitation basically necessitated that we work in a more waterfall style management style as opposed to the much preferred and far more efficient SCRUM methodology. Although we incorporated the weekly meetings and progress updates of SCRUM, there could be no changes performed by multiple people - so when work was distributed out simultaneously it was usually pertaining to the written components of the assignment.

The design of the prototype has actually exceeded expectations as is. That being said there is always room for improvement, and there are numerous features and some issues that we could choose to rectify that would naturally improve the play of the game.

Issues still persist with the random enemy spawning in that they spawn in clusters as opposed to complete individual randomness. We also recieved a few complaints about the sheer number of obstacles being overwhelming. As it stands currently, there are three obstacles that can be dealt with through the players abilities and one (the log) which must be simply avoided.

I believe our playtesting has shown that expecting players to memorise the interactions between each of the different entities and also having to focus on dodging can be overwhelming for even experienced video game players (all of our naive playtesters rated their video game experience as above average). Possible removal of, or moving the log to a later level could help in pacing the difficulty more effectively.

References:

Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press.

Assignment 3 Playtesting

Our playtesting for our third assignment has now been completed. Not including the practice playtest, we have successfully finished the full playtesting process and documentation with 5 unique naive playtesters.

Three of these were performed in class and others were performed during the hosted session outside of tutorial time.

In addition to lending us valuable insight into some of the issues our game had, we also gathered data pertaining to the types of people that would enjoy our game in the form of the demographic data in the pre-playtesting questionaire.

Something I noticed specifically from this data was that all of our playtesters noted their experience with video game playing to be high (4-5 on a 5 point scale). This would likely mean that our playtesters performance and thus the data obtained from it would be heavily skewed in favour of those with a high knowledge of modern video game titles and conventions, which would have made it easier for them to understand some of the visual language and controls we employed in our game. I am curious about what we would learn if we had incorporated more inexperienced playtesters into our process.

Pertaining to the actual gameplay, there were many consistent notes made across several playtesters. Apart from bugs that obviously needed to be fixed such as one that broke the tutorial if the player performed an input too early - we noted for instance that many players gravitated towards the top of the screen, where they would then get hit by the oncoming obstacles.

The fix we ended up putting forward for this was making the pursuing monster's sprite a little bit smaller, to make the player feel as though they had more room to move - as previously it had been taking up a large portion of the bottom screen.

Assignment 3 Development Progress

The development of the game is progressing smoothly. As stated previously the initial build of the game provided by our teammate was already very close to the Minimum Viable Product outlined in Part A of our assignment.

The elements that had to be added to achieve the Minimum Viable Product from that version of the game included providing the player with feedback on the rock, paper, scissors-style mechanic with cooldown icons and implementation of visble health and stalker meters to provide the player feedback on their progress. Both of these elements have since been added.

We are currently sitting at our projected Minimum Viable Product and have also recorded some tentative feedback from the practice playtesting session which we intend to implement changes on at a later stage if it is corroborated with our formal testing, which is to be included in the second part of our assignment.

Group Formation and Assignment 3 Team Discussion

This week we established our groups for our group assignment and determined which game we would be working on.

We determined that we would work on the game 'Howling Roads'; an infinite-runner style racing game where the player is pursued by a monster - with a unique mechanic that governs how close the monster is to catching the player called the 'Stalker bar', which is influenced by the player's actions throughout gameplay.

The game was initially pitched by one of our group members and this week we had our first meeting where we assigned roles and worked to complete Part A of Assignment 3.

In doing so we described the minimum viable product - thankfully the game was already in a state quite close to our projected M.V.P. and as such we can spend far less time getting the core functionality solidified and more time iterating on the data we gain from playtesting feedback.

For the second half of the assignment, I have been assigned the role of report editor - so the large portion of my work will be spent assisting the Playtest Coordinator and compiling the report based on the data acquired from playtesting.

Assignment 2 Final Design

Pictured above is the final design for my technical document AKA the one-sheet.

I feel as though I could have improved it further, namely including less text and providing further details on projected enemy types and puzzle interactables - however due to the game's genre (puzzle platformer), I found it very difficult to conceive of potential elements without spending time designing further levels and overall fleshing out the mechanics of the game more.

I am sure this one-page suffered greatly from the fact that I am still ultimately unsure about the viability of this game's central mechanic and have yet to experiment fully with how it can make for interesting puzzle design. I felt unsure as to how I would expand on the elements I had created because I was not entirely sure they were interesting or well-designed - especially in reference to the central death mechanic.

Racing Post Mortem

I have now successfully added most of the core functionality to the racing game.

The gameplay has evolved from what I initially outlined, in that I have added some additional aspects to its core gameplay. The most notable change that I have made from the intial design is the ability to shoot multidirectionally using the [Space] and [Shift] keys for shooting left and right of the player character respectively.

The game functions by having enemy vehicles spawn randomly and drive down towards the player - if the player is hit by, or collides with the enemy vehicle they receive a game over:

In Game Design Workshop, Tracy Fullerton discusses the use of objectives and procedures in motivating the player. This is something that has necessarily been an influencing factor in all my games, but it was something that I was forced to consider in this instance for the reason that there is no defined positive endpoint. Which is to say, the player cannot 'finish' the game with a positive outcome.

The objective of the game is to defeat or avoid enemies with the goal of staying alive as long as possible. In other words, the game cannot end in a 'win' besides that which is defined by the player themselves in terms of their own personal goals. The goal of the game is to prolong the game.

Fullerton describes what I have just outlined to be a procedure called the 'resolving action'. The specific resolving action in this game could be considered 'achieving a game over'. The 'core loop' (defined by Fullerton in the same chapter as 'progression of action') therefore consists of all actions taken to avoid the resolving action - dodging, shooting enemies, moving forwards and (although not present in the current version) increasing score.

At this stage, there is only a single enemy type that spawns at a random x-position and moves down the screen attacking the player. This makes gameplay particularly easy if the player simply chooses to position themselves at the bottom of the screen, as each enemy has the same speed. I would also like to have added a score system which dictates both the types of enemies that spawn and the frequency, though this proved to be out of scope given the timeframe.

I believe adding more variety to the game in the form of distinct enemy behaviours would have made the game far more interesting to play.

References:

Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press.

Assignment 2 Progress

Both my one-page and sell-sheet have been progressing swiftly. At this stage I have completed my sell-sheet - as it appears below, and have begun work on the more technical document. I am finding it difficult to begin work on the one-sheet as I am basing this assignment off my platformer (game 1) - a game which I only developed some of the projected functionality for.

Without knowing precisely how the rest of the game works I am finding it difficult to talk about all the necessary elements. Ultimately, I may opt to define the categories of gameplay elements as opposed to identifying every one of their variants.

I think the sell-sheet on the other hand accurately conveys the information it needs to, as well as the intended style of the game - the black and white hand-drawn style evokes to me the feeling of a game like 'Baba is You', which was one of the primary inspirations.

Racing Pitch

My current idea for the prototype of my racing game is to have the gameplay be akin to a sidescroller or an infinite runner - with either enemies or obstacles that the player needs to deal with or avoid throughout the moment to moment gameplay.

I am thinking of having the enemy types and frequency of obstacles/types of obstacles change as the player traverse farther and farther - utilising a score system. The game will end when they crash or take damage from enemies a set number of times.

The game will appeal to a wide range of audiences due to its arcade-like nature and replayability. The goal in creating this game will be to create an experience that is fun in short bursts - it would likely be a game played on mobile platforms and its closest analogue would be something like Temple Run.

Asteroids Post-Mortem

The game is now in a state where I feel the core gameplay has been established and any further work save for fundamental overhauls would be largely iterative.

As alluded to in my previous post, my primary goal in continuing development was to add a win condition to the game, thus creating a finite end point that propels the player through the gameplay - in keeping with the discussion of outcomes in the Game Design Workshop textbook.

I have now created a functioning final boss that appears after a set amount of score has been reached (it is set to an arbitrary amount in the picture below for ease of testing), and defeating the boss ends the game.

In the process of developing this game, especially after implementing the score system and thinking about the need to motivate the player using outcomes - my primary goal became ensuring that the game was, at the very least, internally complete. The book Game Design Workshop describes a game that is not internally complete as such:

"In software, it [incompleteness] leads to a loophole that players can exploit, a dead end in the player experience, or a complete breakdown of the system."

So to reiterate and slightly paraphrase this sentiment, my goal in the creation of this game was to create the fundamental elements of the game, and to have it be playable without my (the designers) input. The game was to have a definitive goal that would serve as an endpoint, and would function from the beginning to end in a logical progression. I believe I largely succeeded at doing this, although I don't think in this particular instance that enough time was spent allowing players to test - and those few that I did allow to play the game did so in a state where it was lacking this internal completeness. As a result, I don't feel as though the data I recieved from playtesting in those instances is useful outside of gauging game feel and general player experience. This is a personal failing stemming both out of time constraints and a lack of general organisation that I will need to reflect on when creating future projects.

Balance is one thing that I, admittedly, gave only cursory attention to in creating this game. My troubles (outlined in the previous post) regarding the ill-aligned distribution of points was only once such issue I encountered in this area. In creating the boss monster I went through multiple variations, some too difficult and many too easy. Still now I think that the difficulty curve of the game is warped in favour of too easy, though this could also be bias on my behalf after playing it so excessively. If I were to refine this game further, I would devote a good portion of time to testing and tweaking the difficulty curve and game balance to create a more satisfying level of challenge.

References:

Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press.

Asteroids Development Post

I have implemented a score system to the asteroids game - points are currently awarded based on the size of the asteroid destroyed in increments of 10 points (10, 20, 30). Due to the fact that each asteroid is equally difficult to destroy, this immediately raised the question of whether the health of each asteroid should be changed as at this stage, the biggest and thus easiest targets to hit also award the most points - which in terms of a natural difficulty curve seems counterintuitive.

I see two potential solutions to this problem. One and perhaps the simplest being to reverse the order of point gain - thus making the smallest targets award the most points. Alternatively, I could increase the health of the larger asteroids, making them take more time to destroy.

I see both solutions as viable and intend to playtest both approaches to determine which players find the most engaging and which provides the better game feel.

Something also to be considered, and which is covered by Tracy Fullerton in Game Design Workshop is what she describes as 'outcome'. In the instance of this game, there currently exists no discernible win or loss condition to propel the player through the game. Even (as she describes) if we choose to consider this game a non-zero sum - which is to say, a game where there is no definite winner (+1) or loser (-1) - there is currently no facilitated or measurable outcome that encourages the player to engage with the gameplay loop besides the arbitrary and self-defined goal of beating ones own score.

To this end and in the absence of a multiplayer component that would easily compel the player in a zero-sum capacity, I will be thinking about creating a discernible win condition with the intention of propelling the player through the gameplay towards a finite end-point.

References:

Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press.

Asteroids Pitch

My asteroid game concept consists of two primary core mechanics. Firstly, I would like to intertwine movement and attacking into one input. My current idea for implementing this is to have the engine be a laser beam that pushes you forward. In conjunction with this, I would like to add in interactions with the asteroids that cause them to break into smaller and smaller versions - creating bullet hell-like gameplay.

The genre is a science-fiction top-down shoot em' up/bullet hell game. The game is set in space and the player plays as a ship.

I see this game appealing to a wide range of demographics due to its extremely simple controls - however I can easily imagine a hardcore subset that focuses on getting the highest scores or staying alive for the longest, akin to something like Geometry Wars.

Platformer Postmortem

Here I will examine my platformer in its current state and disect it to figure out what went right, and what went wrong.

In the book Game Design Workshop, they define how designers can utilize certain resources to create and control conflict in their games. I was particularly taken when I began designing this by the resource of lives - as they provided me to inject an ironic twist on how games usually approach this system, in that the player is expected to die - so instead of appearing as a supplementary resource to control difficulty, management of the lives resource is one of, if not the core mechanic.

I feel as though being more inclined to test even at the stage of the first level would have helped a great deal with fleshing out the core mechanic - something I do not feel has been fully done yet. I first envisioned the game as a more opened ended experience, however as development came along it became clear that the game a more structured puzzle-game approach. Creating an optimal sense of rising challenge (explained in Game Design Workshop) in a puzzle game setting proved difficult for me and truly the level design did not really progress pass establishing some of the core mechanics.

I would definitely like to alter the amount of feedback the player gets and/or the amount of challenge - although that can largely be attributed to the simplicity of the early game levels. Although it can technically fall under the category of polish, Game Design Workshop does explain that if a certain level of animation or polish would help in conveying the core spirit of the game that it is justifiable to incorporate it into a prototype such as this. When watching playtesters and when playing the game myself, I can't help but feel that the lack of feedback makes the game feel slippery. I think increasing the visual or audio feedback the player recieves could make the game, even in this rudimentary state - feel far more enjoyable to play.

Platformer Playtesting Data

In playtesting my initial two levels of the platformer I set out with a few goals in mind:

1. Determine whether or not the core mechanic (changing level geometry on death) was intuitive or needed to be more clearly communicated through level design - or even tweaked substantially.

2. Gauging player comments to gain unbiased consensus on what doesn't work.

To this end, I playtested with multiple different people; with set approaches that differed between each tester.

Approach 1: To determine how intuitive the mechanic was, the first tester was given the smallest amount of information - equating to essentially the basic movement controls. Any information regarding the gameplay interactions was left out.

Approach 2: The game mechanic was explained, the main draw of this approach being to gauge player comments about the how the game feels to play and to examine how they approach the level.

Approach 1 Result: The first approach successfully demonstrated that the level design successfully got the player through the level, but it remains unclear whether the mechanic is successfully taught through the level as the tester remained unsure of how the mechanic exactly functioned.

Approach 2 Result: The approach 2 player had been told in advance how the game worked and found it quick to complete. He notably followed the exact thought-process that I projected in the second level - where he saw the button, attempted to jump on it then proceeded towards the box and pushed it onto the button, causing it to bounce.

We did also encounter a new quirk in this trial that was not found during my testing of the game, the box in the second level would under certain circumstances launch itself into the air far higher than intended, which would break the level. Thankfully, this wasn't too great an issue due to the restart button.

Game Development Post

The game has begun to take shape and I have started implementing some of the puzzle building blocks in GDevelop.

The implementation of falling boxes and bouncing objects has necessitated that I begin to use the engine's Physics 2.0 system - this has since forced me to essentially retool the entire movement system for the player due to difficulties with the 'platformer' behaviour and how it interacts with the physics system.

One benefit I have found that stemmed from this initial setback was the ability to tweak the movement values far more easily and precisely using the new system which I believe has resulted in a smoother experience.

This is the current design for the second level - the idea behind the design is that the player is forced to reach the box before the enemy and will likely accidentally push it on the way there, causing them to realise they can push it onto the button below which cause it to bounce and allows them to reach the goal. This felt like a natural way to introduce new mechanics without explicitly detailing their function.

Aligning with the playcentric approach outlined in Game Design Workshop the idea of feedback was very important in this level - pertaining specifically to the visual assets. Initially the button was static but I found that when the box started bouncing it was unclear whether this was a result of the interaction or simply something innate to the box. Adding a springy motion to the button I hope resolved this problem, although it requires further playtesting.

I found that due to the way the player could push the cube around, the level could technically be broken with no way to complete it if the player, for instance, pushed the cube off of the button before jumping on-top of it as intended. This inspired the creation of a pause menu as seen below - with an option to restart the current level.

My next post will outlign my approach to playtesting and a small update to the final design of the level.

GDevelop Experimentation

I have started prototyping the game and isolating its core mechanics in GDevelop. This type of prototype is to serve primarily in locating potential issues and solidifying the core gameplay.

I began by initially drawing up paper designs for levels and writing up some ideas for basic rulesets and interactions that would be useful in creating a multitude of puzzles. I found it difficult to conceive of a way to create a functional paper prototype (as outlined in Game Design Workshop), however being able to easily theorise about gameplay concepts on paper certainly made this initial design experience less painful. An example:

A core gameplay problem that needed to be reconciled immediately was how to provide stakes in a game where the primary interaction is for the player to die. The solution I have posited for now is the introduction of a lives system, which will serve as the primary limitation in the puzzles.

The player must solve the games puzzles by dying to alter the level geometry - and do so within a given life limit.

I created a very basic first level, to provide clarity to the core mechanic and ensure that it was technically feasible for me to implement it within the software. For now, I have limited the play to a single screen and an obvious goal to ensure the design remains focused.

The goal of the level being to reach the flag. The player must simply die to the enemy - removing the wall and allowing them to reach the goal.

The enemy starts in the pictured position moving towards the flag before doubling back, meaning the player must hit the wall and realise they cannot pass it before they can interact with the enemy, ensuring they grasp the central mechanic of the game.

My next step will be testing the efficacy of the core mechanic with potentially some other small puzzle elements to determine whether the mechanic can sustain interest over the course of multiple levels.

References:

Fullerton, T. (2019). Game Design Workshop : A Playcentric Approach to Creating Innovative Games. CRC Press.

Elevator Pitch

'Continue?' is a 2D puzzle-platformer where the level geometry changes upon the players death. Depending on how and who you die to, the level alters in predictable and reproducible ways - allowing the player to take different paths, and blocking off others.

The player has been placed in a labyrinth, overseen by an evil wizard. They are tasked with circumventing the wizard's puzzles to achieve their freedom.

Here in my initial brainstorming page, I outline the basic player experience goals and core mechanics that reinforce those goals - akin to the playcentric approach outlined in the book 'Game Design Workshop', as well as a brief overview of the basic inputs.

The appeal of the game largely stems from its open-endedness, and its systems that theoretically allow for a high-degree of experimentation and exploration. The player should ideally have multiple ways to approach the same problem, and multiple routes through each level.

The game is targeted towards a teenage/young adult audience due to its potentially more complicated level-design and open-endedness. The atmosphere of the game could be likened to that of 'Baba is You'.

References:

Fullerton, T. (2019). Game Design Workshop : A Playcentric Approach to Creating Innovative Games. CRC Press.

‌

Introduction

Hi, I'm Max.

I am a game design student fascinated with the way games can use the elements of interactivity to give the player a plethora of different experiences - from competition to high-quality storytelling.

Naturally adding an element as complex as interactivity changes the nature of what it means to 'create' altogether from its cousins in film and literature.

A game designer can still script sequences and plan interactions, but each time they do so it must be deliberate - because each time they risk undermining the agency of the player. In designing games, the experience of the player must be at the forefront of a designers mind.

Personally, I find a lot of satisfaction in designing and thinking about systems in design; and I believe that the playcentric approach provides an exciting method for creating systems that focus on creating engaging experiences for the player.