#final checkpoint

[alexgarnn]

Final checkpoint - the end

Thankyou for your help this semester Chris, much appreciated :)

[lilymakesgames]

Racing Postmortem

Inspiration from Readings

Fullerton (2018) addresses some of the common game objectives as well as player interaction patterns; this really inspired the design process for GCx2 as it helped me broaden my perspective on conventional racing games. I believed that competitiveness is the driving force behind racing games—much of gameplay experiences in racing game acts to heighten this and exploit it as a very powerful driving force for humans. In that respect, the readings challenged me to think of alternative experiences I could create that would work within the racing genre. That lead to the exploration of how I can contextualise formal elements to engage my players, as you would have seen in the development post.

Additionally, Fullerton’s (2018) words on outcomes in games intrigued me here again. In almost all racing games (GCx2 included), there are only 2 outcomes: first and not first. While there is merit to all the positions between first and last, the real victory comes from claiming first place and the rest that follow can only be “losses” if the objective is to place first. In GCx2 the two outcomes are escape or fail to escape. You either escape the police or they catch you. There’s nothing to predict regarding the pair of outcomes except the likelihood of which outcome you’ll achieve. This also guided my design of GCx2—what mechanics and obstacles in particular can I design to complicate the relationships and add a little uncertainty or conflict in the player’s path?

Finally, I was also personally interested in understanding + exploring feedback loops. There isn’t much else to say except reiterating Fullerton’s (2018) highlighting of the importance of feedback loops for designing complex and engaging, balanced games.

Changes to Prototype Development

After playtesting, it was quite evident that the game was lacking without the feedback loops. The M2M was there but without the feedback loops, the game was significantly…less. Less challenging, less engaging, less of a game. That is to be expected but the issue could have been ameliorated if I tried to implement some placeholder events for the feedback loops. They might not have been as detailed or have the intended functionality but it would have been sufficient for playtesting to better assess the pace of progression in the game.

Still, I think I was right to prioritize the M2M gameplay at this stage of development as it is the foundational gameplay that which all critical systems will build upon. It’s indicative that the game is heading towards the right direction which enables us to put our best foot forward for future development, as per Fullerton’s (2018) words on the importance of testing and getting the main gameplay loop right early.

Changes to Design

Another key issue identified during playtesting relates to the PX goal of challenging players regardless of their dexterity and experience. This might have been avoided if the feedback loops were implemented but I also wanted to discuss another potential solution of designing alternative gameplay.

So, I investigated the issue and determined that it’s probably due to some players having greater dexterity from playing games that require you to switch between entities quickly. As such, one solution is to introduce alternative gameplay that is secondary to and independent from the gear changing mechanic. Changing the GC mechanic itself isn’t a great idea since it would compromise the M2M gameplay so I’ll focus on the alternative mechanic which utilises dilemmas!

In this case, the dilemma would be a trident in the road. The player has 3 options: continue on the road, take the left path, or take the right path. This event places the player in a situation where they must make a decision from multiple choices that have a range of consequences (Fullerton, 2018). It increases the unpredictability of the game outcome making things more interesting for the player (Fullerton, 2018) Additionally, it should also increase tension, hopefully making the experience more engaging overall. As for what the consequences would be…Perhaps one road will be saturated with more obstacles, maybe another road will have allow players to select a new getaway car with added benefits. There are many things that could be introduced to create conflict or reward the player as a result of their risk taking.

Thanks for reading!

References

Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Forth Edition (4th ed.). CRC Press LLC.

End of post.

[lilymakesgames]

Assignment 3 Playtesting

Playtest Preparation

The team collectively prepared a script, questionnaire, and survey to facilitate fair and accurate playtesting sessions. Our goal was to efficiently and sufficiently gather the most useful data to later interpret and thus use to improve our game.

Some of the playtesting resources themselves (namely prototype and survey) were also iterated as part of the playtesting preparation. This would not compromise any of the results as each prototype version will have a respective survey version that most accurately reflects the new iterations.

Some of the resources created/iterated to facilitate playtesting.

Post-Playtesting

Fullerton (2018) advocates for frequent and early playtesting to ensure that the M2M gameplay is developing in the correct direction and to identify unexpected issues that are unforeseen to the developers. It is important to receive feedback from eyes that haven't been pouring over the design; objective perspectives are also crucial to make improvements to our game (Fullerton, 2018).

For structure and efficiency, we also discussed our approach to post-playtesting processes.

After each playtesting session, whether informal or structured, we ensured to keep a record of the results along with a brief analysis of issues and "where to next?" discussions.

This involved analysing the results and then categorising issues by severity and type. This helped decide who would be responsible for managing the issue and also helped with tracking all issues and bugs collectively. Moreover, "managing" the issue involves analysing the respective data by identifying trends, reflecting on design, considering potential factors/reasons for the issue, and brainstorming solutions.

All of the above enables us to safely and effectively prioritise certain implementations for the next prototype as the results inform the direction of development. Reflecting on the results lets us continuously improve our game.

Additionally, please note that the extent to and formality of this documentation depended on the type of playtesting conducted, i.e., light informal playtesting = light informal documentation. For the minimum 5 playtests; however, we will endeavour to have very formal and structured playtesting + documentation.

Week 11 Playtesting

Light and informal playtesting with the very first build.

Current state of game in week 11.

Some of the findings from week 11 playtesting.

Thanks for reading!

End of post.

[lilymakesgames]

Assignment 3 Development Progress

My team elected to develop my game, Rubber Duckie Hero (RDH) for assessment 3. The One Sheet and One Page below should hopefully convey the essence of the game + intentions of design.

The One Sheet and One Page documents respectively; my submissions for Assignment 2.

Moreover, much of the pre-production had already been complete from assessment 2 so we were able to proceed with development very quickly. Even so, there were still three key "stages" in this intermittent preparation period.

1. Team Logistics and Management: Roles and Responsibilities.

We chose to use Discord as our primary communication method and Trello as our primary task management tool. A shared google drive folder will be used to share assets and important documents between the team.

The team Discord, Trello, and Google Drive folder.

As for roles and responsibilities, everyone was happy to work in any role across any area. For efficiency and structure, each team member was given a role and the core responsibility of managing that respective area. However, development will still be highly collaborative and team members will have involvement in other/all areas outside of their roles.

Lily (me): Artist Ann: Programmer Cody: Designer Alex: Designer

2. Design Iterations, Scope, and MVP goal

Prior to developing the actual prototype, the team reflected on the current design presented in the One Page document. We identified key features that were vital for the MVP and iterated upon the design of existing mechanics. In respect to the scope of the project, we also identified several additions to the design that would improve the gameplay experience if time permits their implementation. These were colour coded by order of priority. Moreover, all of the above assisted with identifying our goal for the MVP and enabled us to further the existing vision: an energetic and frenzied player experience.

Iterated One Page document, ensuing team reflection on design.

Examples of the iterations, brainstorming, and prioritisation of certain features.

3. First Playable Prototype and Playtest Preparations

The very first build, playable here: Rubber Ducky Hero | Play on gd.games

For the first playable build we aimed to have the following actions/systems/mechanics implemented:

Sailing (movement)

Shoot bubbles

Collect ducks for RP

Health system - losing health

Sharks

Octopi

Nets

In Hot Water mode

The above constitutes the MVP at its complete base state with a few added mechanics (such as the octopi) to increase the challenge.

Gameplay of the very first build. Apologies, was unable to hide my mouse cursor in the gif.

Our next goal is to iterate upon these existing mechanics and introduce a sea snake enemy that is not reliant on the bubbles in order to make the regular game mode more challenging. In week 11 we conducted very informal and light playtesting which revealed that the regular mode, while interesting, was not very challenging. There were potential solutions which involved freeing the sharks from their bubbles without the player's permission; however, these weren't ideal as they compromised the challenge proposed by In Hot Water mode when all the bubbles pop and the sharks are released anyway. More of this will be discussed in the following blog post.

Regarding playtest preparation, the team focused on developing a more functional build and began preparing the playtesting resources (script, questionnaire, survey, etc.). Actual results and subsequent iterations will also be discussed in the following post.

Thanks for reading!

End of post.

[lilymakesgames]

Racing Game Development + Insights

Main Objectives

Design Goal

Design an exhilarating escape the police in a getaway car game with a simple speed changing mechanic that relies on dexterity + utilize feedback loops to regulate the game’s pace & challenge so everyone can experience the thrill regardless of their skill level.

Implementation Goals

PX Goals

Key Ideas + Learnings

My favourite learning from the textbook that I explored in this cycle was feedback loops!

I’ll be referring to them as reinforcing and balancing feedback loops rather than positive and negative feedback loops in this post. In reinforcing loops, as the name might suggest, a change to one element directly causes a change in another element in the same direction which may force the system toward an extreme (Fullerton, 2018). Conversely, balancing loops may force the system toward equilibrium to counteract the changes (Fullerton, 2018).

I was interested in how I could use feedback loops to regulate challenge and the pace of my game, specifically to make it a challenging and thrilling experience regardless of the player’s skill level. Moreover, GCx2 is a “racing” game but there isn’t actually any racing involved. Nevertheless, I wanted to create the impression of thrill and momentum in the game so I looked to reinforcing feedback loops which can “promote divergence” (Fullerton, 2018). In this case, it would be rewarding players who are successfully changing gears by giving them an advantage, contributing to a sense of momentum from the player’s enhanced progress. But of course, balance is also required “to keep the game from resolving too quickly” (Fullerton, 2018). Maintaining player engagement involves regulating challenge and as fun as speedruns can be, GCx2 wouldn’t be very fun if it was too easy and fast to enjoy.

The three feedback loops in GCx2.

Below I’ll be further detailing my exploration of these concepts and how they influenced the design of PX goals, M2M gameplay, as well as the overall game.

PX Goals and M2M Gameplay

I’ll just quickly talk about the PX goals and how they influenced the design of the mechanics, specifically the M2M gameplay.

For GCx2, players will spend the majority of their time moving and changing speeds to avoid obstacles and escape the police. This gameplay should be exhilarating, thrilling, and allow for some level of momentum to be built but not to the point where the game is no longer challenging. That being said, the game should be challenging for everyone in the sense that it accommodates for different skill levels. The mechanics and gameplay described below should facilitate this (hopefully).

Speeds and Gear Changing

GCx2 has three gears and respective speeds that the player can switch between. First gear is slow, second gear is medium, and third gear is fast. Changing gears is the player’s prerogative; players can be punished or rewarded depending on their success with gear changing. This “success” is based on the obstacles encountered by the player as they drive—players must drive over the obstacle at 1st gear for a successful gear change. Driving over at 2nd gear minimally allows police to catch up faster driving at 3rd gear will significantly allow the police to catch up. These details will be further explained below but the general gist here is that players should be alert and ready to switch gears at any time if they want to win effectively.

Some possible scenarios…

Players thus cannot safely drive at any speed for the whole time as they will fail to escape the police.

Obstacles

The obstacles in GCx2 are mainly inspired by typical road hazards or things you shouldn’t drive over. Speedbumps, oil spills, traffic cones, etc. They all currently have the same effect though as the consequence of driving over them is inflicted by and dependent on the player’s gear upon collision.

I’ve thought about other potential “events” that could happen like traffic lights or animals crossing the road but I’ve decided to focus on the current ideas which should facilitate the PX goals quite nicely already :D

Moreover, obstacles should appear frequently so the player is forced to change gears frequently. This could lead to close calls for the player which could be scary if the police were hot on their tail.

These are some ideal placements that I kept in mind while developing the spawning system for the obstacles. I had the oil spills spawn as waves, similar to how you might use a wave spawner for an arcade shooter game. The player's goal would be to travel in 3rd gear as much possible so they should move left and right, avoiding the obstacles or changing gears to avoid allowing the police to make progress.

Progress Bar and Police

The progress bar is a visual representation of the player’s escape progress. It also shows the progress of the police as well. Progress increases by different increments depending on the player’s current gear/speed (1%, 5%, 7.5%). Failing gear changes will increase the police progression by 2.5% for semi-fails and 10% by complete fails. At the moment these numbers are all arbitrary guesses in respect to the game’s pace. They’ll have to be tested and iterated thoroughly until the ideal pace is found. When the player progression = 100%, the player has successfully escaped. IF the police progression is equal to or greater than player progression though…then it’s off to prison you go!

Now I'll be highlighting some key ideas in GCx2...

Contextualizing the Formal Elements

In a racing game, the player’s main objective is to cross the finish line. There’s usually a secondary goal to this like “be the first to cross the finish line” or “cross the finish line as fast as possible”. Then there’s also the context of the race. Who’s racing? Where are they racing? Why are they racing, to win something? But that’s enough rambling for now, I just wanted to highlight the initial thoughts and guiding questions I had while brainstorming ideas. That actually brings us to my most important point—the challenge of designing a racing (objective) game with a single-player versus game player interaction pattern.

So, why was this a challenge? It comes back to the context of races and the feelings that should be aroused. Let’s talk about the two arguably most important aspects of the race: who is racing and why. First let’s consider the significance of the two aspects: together, they invite a very powerful feeling of competitiveness that’s truly characteristic of racing games. You’re racing against other people to cross that finish line first, to beat them. That’s why all good racing games either have a multiplayer mode or have sophisticated AI to tap into players’ competitiveness that gives racing games their thrill. The human intelligence and general unpredictability factor (or the supplementary sophisticated AI) make the outcome unpredictable. If the player knows that they’re going to win every time, then it’s not very fun or interesting at all which reiterates the importance of considering predictability in games (Fullerton, 2018). So yes, it’s difficult to evoke those competitive feelings so strongly associated with the racing genre. I can’t develop a multiplayer game and I can’t develop a sophisticated enough AI for CPU racers either. That’s when the other context elements come in, namely the “why”. If I can’t evoke competitiveness then maybe I can try inciting the thrill of an escape. Under this, I can design different conflicts that make the outcome unpredictable while also exploiting two very powerful elements of narrative and premise to make the experience more engaging.

In summary, the overall design goal here is to contextualize the formal elements of a race game to compensate for the lack of adequate competition. Inspire the thrill of a racing game outside the conventional race.

So how did I set out to accomplish this with my design? First I considered the objective of the game (and subsequent tone) as the main contextualizing formal element. Fullerton (2018) defines objectives as a means of giving “players something to strive for. They define what players are trying to accomplish within the rules of the game” and also highlights how objectives can set the game’s tone (Fullerton, 2018). With this in mind, I thought about escapes and their connotations, the common feelings surrounding escape games (and the general notion itself).

Emotions and words I associate with "escape".

…and many more. I believed there was significant overlap between a racing game and an escape game so why not utilize an escape objective that’s facilitated by a racing mechanic?

Considering the tone was also great for setting the PX goals as well. Additionally, it also prompted me to consider how “escaping” is the premise for my race game and my main method of contextualizing the race. I can’t effectively evoke competitiveness to engage my players so I’ll exploit the premise instead.

The general idea behind a premise in games is to create engagement by providing context to the formal elements and subsequently, the players’ actions (Fullerton, 2018). Moreover, this has a secondary benefit of allowing us to emotionally involve players “in the interaction of the formal elements” (Fullerton, 2018). This is incredibly important for the formal elements of GCx2. The “escape” premise heightens the consequential feelings behind the gear changes and the progress bar which would otherwise be quite insignificant and arbitrary.

The knowledge that you, the player, are on the run and escaping the police contextualises the progress bar and the gear changing mechanic; it manipulates the player to feel thrill and exhilaration. There is an intent behind the actions: you’re successfully getting away, you’re increasing the distance between you and the police…or maybe you’re doing the opposite, fear is blending with thrill as you fail to change gears and allow the police to catch up.

This also speaks again to the importance of obstacles in single-player versus game interaction patterns (Fullerton, 2018). These obstacles contextualise the gear change too! I need to complicate the escape for the thrill and exhilaration that will be missed from the lack of competition in this single player versus game.

2. Feedback Loops: Regulating Challenge and Pace

Note: These feedback loops weren’t implemented but the designs were very important to the game. They’re also interesting explorations of the theory so I really wanted to share them here.

The second key idea that I explored was the concept of feedback loops to regulate challenge and pace of progression. Feedback loops had mystified me prior to this unit. I knew they existed but without an in-depth exploration, I still struggled to understand the terms and effects of “positive and negative feedback loops”.  Here I’ll be discussing the three feedback loops I designed for GCx2 and why I thought they were necessary.

Also, please note that most of these numbers (duration of effect, conditions to trigger, etc.) are all arbitrary at the moment and would require much playtesting and iteration for sensible, effective choices.

Positive (Reinforcing) Feedback Loop

I was first inspired by the textbook’s example of a positive feedback loop. Fullerton (2018) gives the example of a player scoring a point and subsequently receiving a free turn; “this reinforces the positive effects of the scored point, creating an advantage for that player.”

I was really interested in this, particularly in how I might use it to build momentum for the player. Creating a larger gap between yourself and the other racers (or in this case, you and the police) is always satisfying in a thrilling way. To capitalise on that success and those feelings, building momentum and speeding up the pace a little could heighten that thrill.

If the player successfully changes gears 5 times in a row, it triggers Jesus take the Wheel Mode. The player is rewarded and can further the momentum of their progress with a 3 second shield + speed boost. This should also increase the pace and motivate players to successfully gear change since it feels good to be invincible.

Negative (Balancing) Feedback Loop

I added a balancing loop that should help players who are having more difficulty since the controls of the game require a level of dexterity that isn’t necessarily natural for inexperienced gamers. Fullerton (2018) asserts that negative feedback loops can have balancing effects and bring the game towards an equilibrium to negate changes that might give players advantages over others. GCx2 has a single player versus game interaction pattern, so in this case the game is “balanced” so the player isn’t constantly disadvantaged for their poorer skills.

Players who are having trouble can activate Cruise Control mode in which they’ll have to navigate left and right but will travel in 3rd gear and automatically change gears upon collision with obstacles for 5 seconds.

These feedback loops exist to account for the predicted skill gaps (due to required dexterity to play the game) Hence why they’ve been designed as feedback loops to regulate the pace and challenge of the game. I don’t think they’ll nullify each other, even if they have opposite conditions to be triggered (5 successful gear changes for positive loop, 3 unsuccessful gear changes for balancing loop) because I’m assuming that most players will fall into 3 categories:

In other words, I don’t think they’ll cancel each other out because the good players probably won’t trigger the balancing loop and the bad players probably won’t trigger the reinforcing loop.

Second Negative (Balancing) Feedback Loop

Now, I have made a very bold and significant assumption there that could severely compromise the “balanced” level of challenge presented by GCx2. In that respect, I think a second balancing loop could also be introduced to make things harder for those adept players. If they keep triggering the reinforcing loop then the pace of the game could be too fast and overall gameplay could be too easy to be enjoyable (Fullerton, 2018). If the player triggers Jesus Take the Wheel thrice consecutively, then the game will enter Hell on Wheels mode.

10 seconds Stuck in 3rd, must now narrowly avoid driving into all obstacles because you can’t safely drive over them anymore AND (just in case some players were already doing this) the police are now faster as well to add to the pressure so if you do crash into an obstacle, it’ll be more devastating since the police can catch up to you that much more easily.

Interesting strategies could be used by players who make note of the feedback loops, maybe players will start missing gear changes on purpose sometimes to avoid activating Hell on Wheels. Reminder that driving at 2nd gear isn’t advisable because even though it’s less severe than 3rd gear consequences, it’ll allow the police to catch up much more easily.

Playtesting

It was difficult to observe anything particularly interesting or receive feedback beyond "it was fun and it has potential" or "I'd love to see the feedback loops in the game" with how minimal the prototype was. Since this post was quite long, I'll refer back to the implementation goals:

For the sake of testing the M2M, the GCs would either increase or decrease the progress bar. The "police" were not implemented; the player simply had to keep playing until their progress hit 100%.

I was able to identify a potential issue in respect to the PX goal of the game being challenging for all players, regardless of skill. It seemed that experienced gamers, especially those who play games that require the player to use numbers to switch characters or weapons (same mechanic as changing gears essentially) found it quite easy to play. I'll speak more on this and discuss a solution to this problem (other than implementing the feedback loops) in the postmortem post.

That's all for now, thanks so much for reading!

References

Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Forth Edition (4th ed.). CRC Press LLC.

End of post.