Left Field Games

Well, unfortunately, this post will certainly put the “mortem” in “postmortem”. As in, when Clinton Keith says “Reading... postmortems feels like passing a car wreck,” I understand what he means as it pertains to this particular prototype (2010).

That is to say, due to the frankly intense commitment of completing programming and development on Swashbuckler Seas, development of In the Nick of Time came to a screeching halt more or less immediately after a short period of playtesting.

In all honesty, I’m not all that sure on what to say regarding this prototype that I haven’t said in postmortems of some of my earlier prototypes, and I feel some frustration as to how the cookie has crumbled in general surrounding both of these assessment items.

Let me take this opportunity, therefore, to use the structure outlined by Keith in “Agile Game Development with Scrum” in guiding this postmortem (2010).

1. What went right?

Feasible idea

I feel the idea itself was reasonably sound for what it was (another simple, short-form game made for the purposes of refining my understanding of basic game design concepts as well as methodologies for workflow).

First round of feedback completed

Despite time-related setbacks, I was able to engage in quite a positive playtesting experience with a circle of three friends, where I had the opportunity to test the concepts of a playtesting script, a short questionnaire, a survey, followed by a deeper playtest. While the sample size was small, it was the acclimatization to the process and procedure of facilitating the playtest that was most instructive for me-- and provided me with some insights as to some playtesting approaches for Swashbuckler Seas, even though it was not strictly speaking part of my role on that project.

I was also able to reflect on playtester feedback and, for example, determine that the scoring system needed a little explanation-- perhaps a short, organic, wordless tutorial during the beginning of the game was in order.

2. What went wrong?

Conflict with other game development commitments; confusion regarding prioritisation

Uniquely, given that game development here is occurring within the context of completing a tertiary qualification, many of the factors surrounding the development of the game (such as the “ship date”, and other requirements, such as this journal!) are determined by the institution, rather than a smaller game studio with access to regular Scrum meetings. As such, the need to concurrently work on two games at once, as mentioned above, seriously hampered my ability to complete In the Nick of Time satisfactorily and further iterate on it after playtesting.

I am not blaming these external circumstances-- indeed, it, like everything else, has been interesting to observe and learn from. Something I know about myself-- given my neurodivergence-- is that simplification is the antidote to my tendency to overcomplicate things and subsequently become overwhelmed. Therefore, I will certainly be avoiding situations within the context of “real” game development that will require my fingers to be in too many pies at once.

Conclusion

When I look at the screenshots I have so far for In the Nick of Time, I’m quite happy with what the game looks like. As I watched my playtesters play the game, I garnered immense satisfaction from their delight with the game, too. As such, I can see that the concept-- like so many game development concepts-- is not without merit. However, I can also see that I still have much to learn in terms of the structuring of the game development process, streamlining the process of game development, and on a more minute level, more effective minute-to-minute approaches while working. I must further develop my insight into important vs. extraneous features so that the most essential elements of a game may be developed, playtested, and iterated upon.

REFERENCES

Throughout all stages of the game development process, I worked in a highly structured fashion reminiscent of my typical working approach combined with aspects of Agile/Scrum. I have always been a connoisseur of Lists, and either concluded the previous day or began the day in question by systematically thinking through which tasks needed to be addressed, and in what order. I then shared that with my team-mates on Discord, where priorities could be discussed and amended as needed.

On this smaller scale, I intended for this approach to be adjacent to the Agile approach whereby tasks are at first brainstormed and pooled (all the while avoiding overwhelming the list in what Keith terms “Feature Creep” (2010)), and from the list, the tasks are sorted by priority and then delegated and divided. I’ve reflected in the past regarding the Scrum technique of the “Task Board,” whereby tasks which need to be completed as part of a Sprint might actually be organised into a table similar to the following given in Keith’s book (2010).

In practice, it may end up looking like this:

This sort of approach actually comes relatively intuitively to me when I am given the resources (in terms of time and space) to organise and simplify my thoughts. (Which I realise, is not often the case within the culture of a game development studio. Let’s put that concern away just for now, shall we?)

Therefore, throughout my entire workflow, I always sorted tasks into at least two categories: “Urgent”, “Must Do,” or simply “To Do,” and then “Quality of Life” or “Nice to Have” or something along those lines.

I combined this with the Pomodoro method, which I have discovered this year (Sheldon, 2022). It is a study method whereby one works for twenty-five minutes, and then takes a dedicated five-minute break (Sheldon, 2022). It’s helped me instrumentally in completing large amounts of work in a way that is both efficient and kinder to my mental health. This is especially important to me as someone with ADHD and Anxiety.

In all, while not watertight, I feel this was an effective approach on balance.

When I say not watertight, something which might have increased the effectiveness of this workflow would have been to have communicated more with my team-mates, and requested that they undertake more of the tasks in the list. Many of the graphics and extraneous details might have been improved in this way, given that they were, to my understanding, secondary to my role as game programmer/developer.

Another similar roadblock was that it became clear that our preferred working hours did not quite line up, which sometimes created a feeling of being “out of sync”. While I prefer to commence work in the morning-- anywhere between 5.30am and 9am, depending on my movements in terms of the routine I undertake in managing my health-- and conclude at around 4-6pm, my team-mates preferred to work from the afternoons late into the night. This could be no surprise given the age discrepancy within the team, as much research since the 1990s has suggested that the phenomenon of “sleep phase delay” means that teenagers and young adults are more likely to fall asleep later and wake up later (Graham, 2000).

This is highly interesting to me at the moment, as observing and reflecting on my working habits over the year, I have come to realise that I am most productive when working remotely and when able to adjust my working hours flexibly around my health conditions. For this reason-- though I realise it will be monumentally difficult-- I will be seeking a professional role with a similar day-to-day rhythm as that which I have adopted for myself in this degree so far.

REFERENCES

Keith, C. (2020, December 16). Feature Boards. Agile Game Development. https://blog.agilegamedevelopment.com/2014/04/feature-boards.html

Keith, C. (2010). Agile Game Development with Scrum (1st ed.). Addison-Wesley Professional.

National Research Council (US) and Institute of Medicine (US) Forum on Adolescence; Graham MG, editor. Sleep Needs, Patterns, and Difficulties of Adolescents: Summary of a Workshop. Washington (DC): National Academies Press (US); 2000.  ADOLESCENT SLEEP PATTERNS AND DAYTIME SLEEPINESS. Available from: https://www.ncbi.nlm.nih.gov/books/NBK222804/

Let me begin by saying it’s one thing to be theoretically cognizant of the “defined... architecture for the overall game program” as:

“1. Initialisation (Init or Start)

2. Game Loop (Main or Update)

3. Termination (Cleanup or Quit)”

--and another thing altogether to develop a game large enough (ha!) to experience it and really get your hands dirty (CodeHS, 2022).

I’ve been using the following excellent flowchart from the blog Read Write Code as a general reference for this structure:

(CodeHS, 2022)

However, in truth, this is the structure that has intuitively arisen anyway in the development of Swashbuckler Seas, and I’m inclined to think that, as long as computers continue to work the way they do in terms of processing, this is how any and all games look as programs.

As the sole “programmer” on Swashbuckler Seas (if you can call looking up whatever arbitrary language GDevelop uses for otherwise standard conventions, “programming”) I’ve made it my business throughout this piece of assessment to refine my programming and coding practice. The benefit of using something so accessible and simplified as GDevelop, of course, is that this refining of good coding etiquette hasn’t become sidetracked by simply not being able to speak the programming language-- for the most part.

I’ll admit it-- I didn’t organise all the parts of the game program into appropriate groups until I was absolutely waist-deep in mechanics, both used and discarded, cherry-picked and adapted from all sorts of YouTube videos and GDevelop forum posts.

When I did, however, I think I actually realised satori.*

Moving on, the Start phase of the program runs as follows:

The music begins. Any relevant timers begin. Variables are set to their defaults. The camera is set.

Now, I have no doubt that to the experienced eye (i.e. not mine), literally none of this is new or particularly surprising. I also have no doubt that there is likely a best practice for what order in which these things should be initialised-- off hand, I wonder if it’s more prudent to have the timers begin before the music, for example. In a pragmatic sense, it probably doesn’t matter, but I wonder about these things in terms of keeping code clean and extending consideration toward anyone else who might also be handling the code.

(In this case, obviously, there was only me. Needless to say, what you won’t see in any of the “code” throughout this post is the struck-through remains of unused, omitted or disabled features and mechanics, which I cleaned up for the final version, and which would have definitely presented issues for any fellow programmers on the team).

Now here’s a “learning moment.” I should probably not begin the Game Loop proper with the health/firepower upgrades mechanic.That probably belongs after player controls, player health, scoring, etc. Chalk it up to something to bear in mind in future. Incidentally, this was one of the last things I added to the game, and I think in my search for a fresh start on a feature, I simply created a new event underneath the Start Phase, and the rest was history.

Being one of the last things implemented in the game, I’m proud to say that I actually required very little assistance from online sources in writing this “code.” I already knew how to set a condition for the player clicking on something, changing scene variables, the difference between a global variable and a scene variable, creating objects (and on the correct layer, too!), starting timers, and playing sound effects.

(The Score I had to change from a scene variable to a global variable when I wanted to carry it into the “Game Over” scene. That was an exciting “find and replace,” let me tell you.)

Upgrading the maximum health hearts was a struggle, actually. I was nervous to change the code around the hearts as I had adapted it from a tutorial and there were parts I didn’t fully understand. I experienced what I have no doubt is the classic programmer anxiety around pulling one block out of the proverbial Jenga stack and having the entire thing simply stop working unaccountably, creating an extra three hours’ work for me.

Nevertheless, I persevered and talked myself through the logic of the events (as I like to do while coding) and the entire thing turned out to be much simpler than I had anticipated.

Implementing the 360-degree spray of cannonballs was really fun. Again, I’m glad I didn’t try to implement it earlier, because in particular I needed to be able to manipulate object instance IDs in order to determine the angle of each of the six cannonballs. And I couldn’t do that until I had finalised the health hearts system.

My intuition as to the “cost” of these Upgrades in-game-- i.e. how much of the score the player must spend to earn each upgrade, turned out to be fairly spot-on. The exception was the multi-cannonball upgrade, which had to be nerfed by increasing its cost to 2000 points, as it rendered an already comically easy game positively braindead once you accessed it.

Now this is interesting. Originally, the game retained the original controls we were instructed on our “Asteroids” prototype: mouse only. This, to my thinking, was a boon, considering it made the game very accessible to mobile players, who represent an audience with a terrifying growth rate within the games market, to the point where some researchers have actually identified “a gradually shrinking traditional gaming market” (Cai, 2022).

However, during collaborative team discussions, we decided we wanted the player movement and the player fire to be more separated, and a little more nuanced. We wanted the player to have more control over on-screen elements using the cursor, while enabling them to continue to move around the map. This was especially important when considering the slide-up Upgrades menu.

Other than that, I would note that it was fun to learn how to manage a separate weapon sprite from a player sprite, and I remember thinking that this would be a useful thing to understand for future game development. In this case, it was made simple by the fact that, as reflected in the code, the cannon would “Always” need to be in the center of the ship. (This in itself meant that I had to get to grips with the Points on the sprites, learning that sometimes GDevelop considers certain “position” actions using the “Center” point, and others using the “Origin” point, and there’s no way of knowing in advance what the program will do).

This was frustrating. I found a YouTube tutorial on creating an arcade-style score with leading zeros. (Or at least, a demonstration of such a feature with, well, something to be desired in terms of explanation and detail), but no matter how hard I tried, I kept encountering an issue whereby the number of leading zeros at the beginning of the game changed once the player began earning points. I’m sure it’s actually a very easy fix, and if I set my mind to it, it’ll only take a maximum of half an hour. But it fell to the bottom of the bugfixing priorities.

In deciding that the map of the game world would extend beyond the window, of course the issue arose of enemy spawning location. In its Per My Email days, this part of the events sheet simply had enemies spawning in random spots on the map. Simple!

However, now we needed enemies to spawn anywhere on the map, except in the field of view of the player. For the longest, most irritating while, it somehow slipped my mind to create variables representing the extreme sides of the map, and instead I had coded hard co-ordinates into the enemy spawning mechanic. When I finally saw sense, I was able to respond to team-member requests to alter the size of the map with much greater ease.

To further comment on enemy spawning, likely the most interesting feature to me at this point, yet also the smallest detail and also the most last-minute detail to be added, was the spawn rate.

One of the core pieces of feedback which was consistently raised by playtesters was the difficulty of the game. It was possible to sit in one spot, fire in all directions, and not see a single enemy for minutes on end, earn 1000 points shooting off-screen enemies, purchase the multi-cannonball upgrade, and then you could really grind up the score, rinse and repeat.

I had the rough idea of implementing a simple time-sensitive difficulty scale. The simple addition of a timer for “elapsed time” and tying it to the spawn rate of enemies actually added a rudimentary additional level of challenge to the game. It added, in fact, a sense of rising tension and urgency to gameplay.

Given more time on this game, I would have liked to have playtested this thoroughly and refined the specific values. 

Moving on:

Originally, the health restore item was a rum barrel, as I thought it fitted with the pirate theme. However, I created the sprite in a rush, and no playtesters were really sure what to do with it. It also created confusion whereby if playtesters learned it was a health restore item, they also thought they might pick up points by running into debris.

If I’d had the time, I would have added an animation whereby it rotated and behaved more like a barrel, and less like a badly-tweened Flash animation prop circa 2008.

There’s not a whole lot to say regarding the collisions in the game, other than the fact that it’s pretty clear at this point that I took Per My Email and built on it for this game. There was a lot of logic involved in ensuring objects were created and destroyed appropriately, and scene variables updated properly.

There is an unused variable/function in there called “Push,” which again, is from a tutorial I used to implement the hearts system. The idea was that there was some pushback to the player sprite on sustaining damage, however this was another minor “nice-to-have” bugfix that fell to the bottom of the priority list.

My gods, if someone had told me earlier that GDevelop had a “for each” function!

And I think I just spotted the issue with the “Push” function. I forgot to introduce the variable “Damage.” Cue head-smacking.

Need I say more here? The Health variable is equal to or less than zero, you die and we change to the “Game Over” scene. I should have probably removed the “death” sound effect, since: a) it’s me indecorously going “blegh” into a microphone, and b), it’s inaudible considering the louder “Game Over” jingle which plays on the scene change.

*The state of awakening in the Zen Buddhist tradition.

REFERENCES

Cai, X., Cebollada, J., & Cortiñas, M. (2022). From traditional gaming to mobile gaming: Video game players’ switching behaviour. Entertainment Computing, 40, 100445. https://doi.org/10.1016/j.entcom.2021.100445

CodeHS. (2022, March 3). Teaching the Game Loop. readwritecode.blog. https://readwritecode.blog/teaching-the-game-loop-4c264398384

GDEV in 60 Seconds. (2021, April 5). GDevelop 5 Score and Countdown Timer [Video]. YouTube. https://www.youtube.com/watch?v=qraa4xgvLmY

It is true that our group for Assignment 3, Part B, is something of a mixed bag. I must be continually mindful of the discrepancy between my own age and experience, and those of my fellow team members. I am likely almost a decade older, and have had experience in the full-time workforce as a classroom teacher, a role which requires collaboration on a variety of levels with an enormous range of people-- from students, to colleagues, to heads of departments, to parents, and the list goes on.

The picture I’m painting here is likely already setting me up for a perception as something of a control freak (possibly also with an enormous head), which in all honesty, is not one of my natural traits (and is indeed one of the reasons I left teaching). However, what I do mean to discuss in this context is that, in the course of completing this group assignment, I have needed to readjust to the conventions of collaboration within the context of undergraduate students not long out of high school. I do not say this disparagingly (I have my own thoughts on how the secondary education system sets up students in terms of collaborative skills) but simply in order to give context to some of the reflections I would like to make regarding the approach to playtesting and data collection on the part of our group.

On balance, the entire approach needed work. All three of us could have made improvements in our communication, and it’s worth noting that in this department our shortcomings may have been due to being too similar in communication strengths and weaknesses. That is, all three of us seemed to be peacemakers who didn’t want to “rock the boat,” which of course, can lead to unconstructive silences, a complete lack of communication, and an increased level of anxiety due to unclear expectations, goals, and unaired concerns.

This was not helped by our collaboration and communication occurring solely online through Discord-- and it’s just occurred to me that I would not recognise the faces of either of my team-members if I ran into them on-campus. That’s not to say that I believe online communication was to blame for our issues-- on the contrary, after completing my first year of this degree almost exclusively online due to chronic health issues, I am in fact something of a convert to the benefits of remote work.

However, the delicate art of trying to communicate clearly and directly in an online format, without communicating aggressively, was made complex by communicating over Discord.

I digress, and perhaps I’ll talk more about game development through online collaboration in a later post.

To get to the nuts and bolts of the issue, the fact is that after I had finished actually making the game in GDevelop, and implementing as many features as possible as the nominated programmer (and sometime visual artist), I came to take stock of the progress of the rest of the assignment, and was admittedly dissatisfied with the disorganisation of the data collected so far following playtesting. Playtesting questionnaires and surveys were either completely absent, or were otherwise posted ad-hoc on the Discord, or inserted immediately directly into the master “Part B” document.

Admittedly, I had been expecting my team members to go about their assigned tasks within the assignment in a certain way, and I had not communicated that. However, I was also loathe to serve as some sort of project manager for the whole thing, or worse, to have the teacher in me bubble to the surface and come across as if I was giving Explicit Instruction. I wasn’t sure, at the time, what the correct response was.

In any case, data had been collected “manually” by manipulating Word documents (using the highlighter tool, etc) and the data had not been tabulated or otherwise recorded for easy access elsewhere.

As a last minute measure to more efficiently collect additional data, I converted both the questionnaire and survey into easy online forms using Microsoft Forms, with the hopes that we might more easily turn the data into more legible graphs. However, it was really too late and these forms didn’t end up being used.

Link to Questionnaire

Link to Survey

Subsequently, I manually tabulated all data and turned them into graphs using Canva.com. As it was the due date, I did this in something of a rush, and so obviously, there were some inconsistencies as my method was inefficient and prone to human error.

Eventually, a few hours before the due time, a team member with the appropriate skillset (that is, more familiarity with Excel than me, I’m embarrassed to say) offered to process the data more correctly through Excel. Overall, this was a task I felt I couldn’t have requested earlier as I felt the attitude would have been that it wasn’t a necessary step in completing the assignment.

I may have been wrong about this, but I also felt as if I had already been too assertive in the group already and couldn’t ask for anything further.

And yes, it is functionally true that displaying our data as graphs is not a required step of the assignment. However, the power of graphs in order to be able to precisely and accurately discuss trends, majorities, averages and medians, I feel was instrumental within the entire essence of Part B of Assignment 3. Not only that, but the assessment aside, the use of visualisation of data is a staple in “[discovering] unexpected paths... [identifying] possible design and balancing problems, or... [finding] common patterns in the behaviour of players” (Wallner & Kriglstein, 2015). It is essential to the effective functioning of the entire playtesting process, as well as the broader UX facet of game development. Making data more cogent and comprehensible “[assists] developers and players alike to understand, analyze and explore the data” (Wallner & Kriglstein, 2015).

Obviously, on the whole, this is a complex issue and one which does arise in professional life often: the dreaded combination of mismatched and uncommunicated expectations. In general, more discussion was needed. I should have requested more voice calls over Discord, and should not have assumed the expectations and responses of my fellow team members, treatment which I myself resent as a worker.

Therefore, I must challenge myself in future group work to be mindful of my expectations: whether or not I am making them clear, and to be willing to negotiate on those expectations in addition. However, I believe I would also benefit from some advice regarding what to do in this situation. Given my past experience, I do have convictions that I know the best way to complete certain tasks (for example, data collection). I need guidance on:

1. Whether that is actually correct, and

2. If it is correct, what I must “do” with this-- how to share my experience and knowledge in a peaceable and flexible manner.

At the end of the day, this is likely the resolving of the complementary (and often  conflicting) meeting of my desire to do my very best on an assignment, with my wish that everyone within a group context feels peaceful and relaxed all the time. (Which is, indeed, what I want for myself, and given the nature of collaboration, team-work, and humans in general, is unreasonable.)

It is clear that my approach to resolving this conflict on this assignment was not productive. In in my desire to both achieve a high mark, and not “rock the boat”, I simply silently took on much more work than needed, which has led to a feeling of exhaustion and unwarranted frustration.

Ultimately, following this experience, it is my goal to seek more productive ways of completing assignments in groups through effective communication, and to approach group tasks with an open mind, compassion, and flexibility.

Strangely enough, we’ve actually started playtesting our group project, “Swashbuckler Seas,” earlier than I started playtesting “In the Nick of Time.” Following some of our early feedback, we’ve already started to make adjustments to the fire-rate of the cannonballs and the spawn rates of the enemies.

Slowly but surely, we’re also adding our very own custom assets.

Coding and programming our group assignment, “Swashbuckler Seas,” has essentially involved re-jigging my code for “Per My Email.” So far, the predominant challenges have presented themselves in the forms of writing some appropriate enemy and ally AI.

To help organise my programming workflow, I created a checklist for myself:

and simply began working through the list.

The most fraught aspect of developing “In the Nick of Time” so far has been the countdown timer.

Having recently fallen in love with newly released Hyper Demon, the mind-bending, abstract “FPS” (you’ll see why I’ve put that in quotes if you watch this footage of the current world record high score), I’ve been doing a lot of thinking about the concept of racing against the clock in games.

To cut a long story short, the aim of Hyper Demon is to finish the game with a high score-- like many short-form action games-- however, combines this with the fact that your score is also the countdown timer. Meaning, there are certain situations within the game wherein it is better to “quit while you’re ahead”, rather than drag out your inevitable death and finish the game with a lower score. Because of this, there is an element of high-risk high-reward to persevering in the game.

Generally, skill-based, FPS, high-dexterity games are not my first choice. However Hyper Demon is unlike anything I’ve ever experienced before on so many levels. Rather than wax poetic about this masterpiece, however, I’ll simply mention that I’m absolutely compelled by its abovementioned scoring system, and wanted to experiment with a similar thing in my own Racing game.

 I started by experimenting with timers in general, and found a useful forum post with simple instructions for creating an additive timer, which would count the amount of time elapsed and display it in real time.

I thought it would be a relatively simple task to alter this so that it subtracted from the time, instead of adding to it. Oh, how wrong I was.

Eventually, however, I came across this tutorial on YouTube, which gave me what I was looking for. Inevitably, it was completely different to the former kind of timer and I would never have been able to eke out such a solution myself.

This was without even adding milliseconds to the timer.

TITLE OF GAME: “In the Nick of Time” -- possibly a working title, as it doesn’t exactly roll off the tongue!

THE PITCH: In space, no-one can hear you race against the clock! “In the Nick of Time” is an intergalactic take on a simple singleplayer racing game, with something of a gambling edge. The player-- the red spaceship, which of course, goes the fastest-- begins the race with ten seconds on the clock. The time on the clock also represents their score. (Time is money, don’t you know?) Acquiring “spare time” along the way increases the amount of time left, while colliding with obstacles or otherwise sustaining damage decreases it. The objective of the game is to conclude the race with the most time possible remaining on the clock. When does the race conclude? You decide-- that is, each race is divided into three “legs”, after which you have the opportunity to continue to increase your time/score, or “quit while you’re ahead”, so to speak. Should you decide to continue, beware: the legs also represent substantial hikes in difficulty in terms of your speed and the frequency of obstacles and enemies.

Speaking of which, these chance elements such as passing planets with randomised gravitational pull, and spontaneously spawning hostile aliens with the power to drastically reduce your score. It’s Starfox meets the more recent Hyper Demon, taking the rail shooter elements of the former and combining them with the time-as-enemy aspect of the latter.

IMAGES:

 TARGET AUDIENCE AND PLATFORM:

Players aged 5+; families; predominantly consoles such as Nintendo Switch, Playstation, etc.

CONTROL DIAGRAM:

 3 UNIQUE SELLING POINTS:

1. A racing game with strategic elements wherein players assess risk and reward

2. Multiple ways to win rather than speed or dexterity alone

The tale as old as time for Per My Email, of course, is that I would have liked more time to work on it and flesh it out in a longer form. In particular, I believe there would have been considerable merit in playtesting the game's driving framing device of the silly romantic subplot-- the player experience I had been hoping for was for them to form an attachment (ironic or sincere) to the player character, and to become a little emotionally invested in helping them achieve the end-goal of romancing Water Cooler Crush at the conclusion of Level Four, or "Working Lunch”. This whole aspect of the game really started with me generating a “player story” per the approach outlined by Clinton Keith in “Agile Game Development with Scrum” (2010). The initial player story ran something like, “As a player, I want to see a version of Asteroids with multiple levels, and incentive to continue through all the levels.”

On a more moment-to-moment gameplay note, I'd have liked to have implemented the whole complement of weapon and chair upgrades I ended up listing on my One Page and Sell Sheet-- all concepts which also arose from generating “player stories” such as “As a player, I want an office chair that spins around continually and sprays bullets absolutely everywhere” and “As a player, I want to take a literal flaming torch to the emails” (Keith, 2010). Being able to test these player stories would have enabled me to better test for game balance, dramatic elements, and completeness (Fullerton, 2018).

Nevertheless, I feel it represented an improvement on KitsuKana in terms of design, completion, playability, and the playtesting process (Fullerton, 2018). I was particularly satisfied to have included almost an entire set of my own assets, which helped me to cultivate a greater sense of momentum in creating the game. Further, promptly making a playable prototype available to playtesters gave me a huge leg up in terms of the time spent playtesting, as well as the quantity of data to which I had access. 

In terms of playtesting in particular, as I mentioned above, Per My Email got a little more air time than KitsuKana, but there was certainly room for further improvement. I'd like to better structure and formalise my playtesting process according to Fullerton's suggestions, such as those he makes for controlling the testing environment, the use of especial questions and diagrams to better quantify and qualify feedback, and "[generating] data that shows trends" (Fullerton, 2018).

Following the feedback given during playtesting, changes I would make include: increasing the difficulty level, either by increasing the frequency or amount of emails spawned; increasing the variety of emails spawned both in terms of traits and cosmetic appearance; as well as adding some more physics-- particularly when it comes to the player character. I'd like the player character to actually push around on the office chair as one does with such a mode of transport, lending the character a much more comical, rowboat-like motion. I'd be very interested to learn how this would affect gameplay too. It might necessitate some more strategy on the part of the player in terms of actually timing their fire rate.

I did manage to do a little "bug-fixing"-- if you could call it that-- following playtesting. I did indeed find the error that was picked up by a playtester regarding small emails not disappearing after collision with the player. I improved the balance of some of the sounds, and implemented an additional sound effect for a lost life.

It's my aspiration in the Racing game to utterly prioritise the playable prototype, to allow for ample time to organise the collection (and my own processing!) of data, and subsequent feedback implementation. More than that, it would be nice to actually manage more than one or two iterations of the game to really test different iterations of the game.

SOURCES

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

To be honest, I was so chuffed by the hilarity that was instantly added to my prototype by my ridiculous sound effects, that I was insanely excited to show others. I started with my friends and family. Satisfyingly, all immediately agreed that the game was funny, as well as fun.

PLAYTESTER 1 (28, F, Casual gamer/ “non”-gamer)

Feedback:

Reflections:

I did anticipate issues with the player character’s life depletion-- an oversight of mine was not to include any sound effects or other tactile information (such as actual physics) when the player collides with emails.

TO IMPLEMENT:

Improve player collision with emails:

1. Sound

2. Physics

3. Potentially replace life counter with a depleting health bar

PLAYTESTER 2 (27, Nonbinary, regular gamer)

(Tested in a group context with other lookers-on)

Feedback:

Reflections:

Again, the life depletion and game over issues arose. “I didn’t catch it” pertained to the “Game Over” sound effect. I’ve had the same feedback about the character player a few times.

TO IMPLEMENT:

Improvement of visual and audio assets:

1. Improve/ clarify player sprite -- perhaps make a clear pixel sprite or increase general size

2. Increase volume of Game Over sound

3. Add more variety to emails

PLAYTESTER 3 (Unknown; regular gamer)

Reflections:

I’m not entirely sure what to do with the “small emails = hard to read” feedback, given that all of the emails are simply the same five repeated over and over again. In short, I’m not sure how much of the quality of play would be improved by increasing their size. I’ll need to think that over.

TO IMPLEMENT: Improve email AI-- ensure small emails are deleted when colliding with player.

PLAYTESTER 4 (25, M, casual gamer)

Reflections:

I haven’t, up until this point, really thought very hard about the level of difficulty or challenge-- and resultantly I do concede that it’s a ridiculously easy game to play thus far.

Quality of life and functionality in the game will certainly be improved by the addition of a title screen.

TO IMPLEMENT: 1. Consider difficulty of game

2. Add levels with increasing difficulty

3. More variety in emails!

4. Add a title screen

PLAYTESTER 5 (29, F, Complete non-gamer)

If my last game prototype was too heavy on the concept and too light on the execution, I’m confident I’ve got a pretty good handle on the execution of “Per My Email.” Without further ado, I present my very first real, actual game prototype that has a discernible beginning and ending!

Obviously this version doesn’t include all the bells and whistles I promise in the Elevator Pitch (such as additional levels, weapons, enemies, and of course, a love interest!) however, I feel like it’s not far off.

Asteroid AI

To really get the game working like the classic Asteroids, I simply kept playing the original game itself in between looking up and subsequently implementing the appropriate functions and behaviours.

With the help of some YouTubers, I managed to get the emails spawning at a reasonable rate (rather than absolutely filling the screen immediately, which is what they initially did), multiplying as they were shot, and generally just moving around in a random manner.

Videos I found useful were:

How To Make A Game Without Coding - Asteroids - Part 1

How To Make A Game Without Coding - Asteroids - Part 2

How to make Asteroids in Unity (Complete Tutorial) (A Unity tutorial, but obviously approaches to writing code are translatable across platforms!)

In the end, the multiplying asteroids/emails looked like this in the level events:

Custom Assets

I churned out a few custom sprites for use in the game, mostly because entire appeal of my reskinning the game was to completely obliterate annoying emails.

Before deciding on phrases to use on my emails, however, a little research was in order.

The most annoying phrases you can use in an email, ranked (Ramsell, 2020).

The 9 most annoying phrases we all hate to read in emails (Johnson, 2021).

As per my last email-- can we just not use that phrase anymore? (Hinde, 2020).

From these articles, I distilled my own personal pet peeve emails into five phrases, though for a fully-featured, more fleshed out game, I’d love to include about twenty.

In the end, my emails read:

I also created a somewhat dubious player sprite depicting an office worker in a rolling chair from the top down. Several of my playtesters so far have confirmed what I’ve suspected the entire time-- it’s not easy to make it out.

Other assets which I included, but which were not mine, is this explosion animation by ansimuz on itch.io:

as well as this very generic office layout given as an example on this website:

Sound Effects:

Getting back to one of my pieces of inspiration, “Desktop Games”, it was quite a tactile game in terms of the bizarrely high fidelity sound effects, and I wanted to bring that to my take on “Asteroids”, so I opted to record the all the sound effects myself by making silly noises into my microphone.

To spice things up a little and ensure everything was nice and novel during gameplay, I ensured that there were several versions of each sound and that they would play randomly as applicable. To do that, I took a look at this forum post:

How would I set up a randomised sound effect array/list? (wOOtist, 2019)

In the end, that looked something like this in the game events to which it applied:

Somewhere between 2001-2003, our local Computer Man installed on our home PC a game whose official name I have only just learned: Desktop Games. This deceptively innocuously-titled game enabled you to absolutely trash your computer screen using your choice of a flamethrower, machine gun, termites, stamps, a paintball shooter, a hammer, a chainsaw, or a sci-fi phaser. At the tender age of seven, I had no concept of computer-induced stress-- indeed, programs such as Microsoft Word and Microsoft PowerPoint represented to me all the unbridled artistic potential of rainbow-coloured Word Art (the “sunset” preset was my favourite), page borders made up of cakes or globes or Keith Haring knock-off stick figures, and unlimited capacity to insert images from the Internet of my favourite characters from Pokémon.

Nevertheless, it seems the appeal of Making a Very Large Mess in Full Surround Sound transcends age, and Desktop Games was somehow on par with Wolfenstein 3D for me in terms of entertainment value. (I certainly should not have been playing Wolfenstein 3D at that age, but hey, it was the early 2000s.) I certainly was not included in Desktop Games’ target audience of technologically frustrated adults who were increasingly asked to incorporate the computer into their working lives.

Excitingly, it is available to download for free on the inestimable Internet Archive, which is where a solid 60% of the interesting things on the internet can be found.

“Desktop Games” does on a smaller, more mundane scale what most other games do with elaborately constructed fictional universes (Grand Theft Auto included): enable the player to engage in behaviours which they ordinarily couldn't in real life. The success of games which allow the player to engage in downright chaos, havoc and mayhem is demonstrable not only through titles like GTA, but through examples such as Untitled Goose Game, Goat Simulator, for which an especial genre has been coined: “Animal Mayhem Games” (Caracciolo, 2021). Arguably, things like Kandy Krush and Fruit Ninja also come under the category of games which facilitate the gleeful destruction of things for no other reason than sheer joie de vivre.

Indeed, I often used to boot up Skyrim for the sole reason of trashing everything in sight with my obscenely min-maxed werewolf character.

Another piece of inspiration was this classic Tumblr text post, which ranks among my favourites to drop in casual conversation with the intent of exposing any fellow Tumblr user in the vicinity.

There is also this, with which I deeply identify:

TITLE OF GAME: “Per My Email”

THE PITCH:

Emails. Every day, you receive emails. But today, you have had enough. You have had it with formulaic greetings, milquetoast memes from 2009 and Quotes of the Day. You have had it with "Go Team!" and "Living the dream" and whoever it is who doesn't know the difference between Reply and Reply All. Today you are transcendent. Today you are an animal. Today, you will take up your trusty peashooter, and not a single pedestrian enquiry about the quality of your weekend will perforate your zhuzh. Slough off this pesky correspondence and become chaos!

"Per My Email" is a reimagining of the classic "Asteroids" arcade game with a twist: you are an office worker propelling yourself on a rolling chair (and no small amount of anxiety) shooting down emails with a peashooter. Much as in real life, contact with an email will deplete your life force, and dealing with them will cause them to multiply. As you progress through four different levels with increasing difficulty, you will rise to the challenge by unlocking bigger and better ways to dispose of emails (such as crossbows and flamethrowers). But watch out for Meeting Invites! Distinct from their mindlessly screen-clogging brethren, they are homing, and will chase you down!

Amidst the confusing correspondence, take care not to shoot down emails from Water Cooler Crush, for whom you have harboured secret admiration ever since they offered to let you have the last Nestle espresso pod in the communal kitchenette.

IMAGES (Actual gameplay footage from initial prototype!):

TARGET AUDIENCE and PLATFORM:

Adults between 18-40+. “Per My Email” is designed to be satisfying to play for short periods of time and works well on mobile, though can be played on PC too.

CONTROL DIAGRAM:

3 UNIQUE SELLING POINTS:

1. Appeals to nostalgia by reskinning an arcade classic for a similar audience to whom that classic was targeted-- i.e. the original target audience for “Asteroids” is now the target audience for “Per My Email.” As a result, they will be familiar with the game mechanics and grammar of the game, while being amused by its reimagining.

2. Includes just enough of a “side story” to add extra dimension while being “short and sweet” enough to avoid being tedious.

To the outside viewer, the prototypes for KitsuKana are probably fine and sound, but I must say, on reflection, I do wish I had had the time and energy to create iterations more representative of my original ideas. At the same time, my original ideas themselves probably should have been less ambitious in order to line up with the scale of the deadline and task at hand. I’m embarrassed to say I believe my emotional attachment to my own concept got in the way of being able to try a less ambitious concept!

Ironically, of course, one of the consequences of rolling with the Ambitious Idea, is that I had to make peace with the fact that the audience for my prototype, while seeing one of my Best Ideas, did not see my Best Work in terms of execution.

It wasn’t really necessary for me to put my eggs in the basket of a game mechanic that relied on dialogue. Add to this the fact that I became rather bogged down in Weeks 3 and 4 with other assessment items, leading to playing catch-up with weekly requirements-- and unfortunately I trundled much of both prototypes of KitsuKana out in a bit of a rush. I mention this not to make excuses, but by way of simply reflecting on reasons KitsuKana didn't nearly the attention it deserved during those weeks.

Something I did re-learn about myself as a creator during that process was that I am strong on the ideas/concepting side of things. It would be entirely straightforward for me to produce a completed “high concept document” for KitsuKana (Adams, 2010). I have always had a vivid imagination and am not afraid to toot my own horn here-- I find it extremely easy to come up with ideas almost instantly, such that I am completely undaunted by Ernest Adams’ admonition that “one idea isn’t enough... you should always look out for more. Make a note of each one and go on” (2010). Check!

I also learned that I am skilled at fleshing out a general idea into a concrete concept, and then into sub-concepts, such as “the player’s role(s) in the game... ...a few ideas for levels or missions and a synopsis of the storyline... a short description of the game world...” (Adams, 2010). It took me no time at all to devise the concept of picking up masks, which would facilitate the general “sequential” level progression system and resource unlocking system of the game, as well as the variety of NPCs the player would encounter-- as well as, of course, the “role” of the player (Adams, 2010). Synthesising ideas I’ve seen or experienced in other media into a new form or a compelling style has always come very naturally to me.

However-- as seems to often be the case for such people-- I easily encounter roadblocks in trying to bring those ideas to fruition. It’s not to do with motivation or the amount of work put in-- it’s more to do with, as I mentioned above, the appropriateness of the idea for the context. This is a skill I am committed to honing as I progress in this degree. Moving forward, my approach toward rapid game iteration will actually begin with the question, “What do I have in terms of time, energy, and resources?” and I’ll save my more ambitious projects for opportunities which afford more of the above (such as Capstone Projects!).

If I’d had even an extra week, I would have extended the length of the prototypes to two or three levels with at least ten minutes of gameplay in total, multiple NPCs (not just the Oni and the Okane mask), and thus a wider variety of phrases, to answer the core question I needed answering about my game:

Is the concept of a language-learning platformer:

1. viable, (i.e. practical) and

2. actually fun?

(I’m not sure I was able to answer these questions well with my existing prototypes.)

I would also have also created some more custom graphics, added more kinds of NPCs (featuring more figures from Japanese folklore, such as tengu, tanuki, kappa, etc., and just generally ironed out more of the creases.  It felt a bit cheap to use assets I hadn't made myself, that didn't look at all like what I was going for (though I am immensely grateful to the artists for creating these assets and making them freely available).

One thing is for sure, however. It’s not an idea with which I’m finished. Somewhere down the line, I’m sure I’ll resurrect this concept and prototype it to be able to answer those questions!

SOURCES:

Adams, E. (2010). Fundamentals of Game Design (2nd ed.). New Riders.

Last night, I had a chance to test my aforementioned paper prototype with my Mum-- which sounds like an odd choice, but in actual fact, she was the perfect playtester. This led to an impromptu playtest of the GDevelop prototype too-- which she actively wanted to test!

Important things about my Mum as a playtester:

1. She is functionally videogame-illiterate-- that is, she does not play video games at all, and therefore does not intuit videogame conventions. She asked straight off the bat which of the “pieces” was hers. A game designed for my mum must not assume that the nature of the “magic circle,” and its “special rules,” as Johan Huizinga puts it in “Homo Ludens,” is immediately or automatically clear to her (1980). This means that, particularly in the GDevelop prototype, I received important feedback regarding the intuitiveness of my controls and level layout;

2. She knows absolutely no Japanese, nor is she particularly interested in learning any Japanese-- meaning I was truly putting to the test the TPRS Language-Learning technique within this platforming context (Alley & Overfield, 2008);

3. She is very good at articulating why she finds something difficult, frustrating, or confusing. I’m not trying to be funny-- I mean that I didn’t need to prompt her to voice or narrate her experience.

As per the best practices outlined in Fullerton’s “Game Design Workshop” in Chapter 9, I attempted-- reluctantly-- to give the prototype over to my Mum without too much preamble, explanation, or guidance (I was truly invoking Fullerton’s maxim of playtesting “before you are ready”) (2018). I told her each of the purple squares represented “spaces” like a board game, and that she had to stop whenever she encountered another character, read the question, and answer the question.

The “flow” of the paper prototype was not something I really ironed out-- initially we tried with a six-sided die, but the fact that the player must stop at every NPC, combined with the absence of any other players, rendered the die immediately redundant. This didn’t worry me too much-- the real point was to test the question-and-answer aspect-- was it fun? Did it work?

Below are images of the NPC questions and player’s pool of possible answers. Their English translations are on the folded side-- as you can see on the printout later in this post.

And here are some relevant “gameplay” images...

PROTOTYPE PLAYTESTING TAKEAWAYS

Distilling Mum’s playtesting experience, here were my key notes:

1. The order in which I placed the questions was more intuitive and organic. For the paper prototype, I had the first Oni NPC ask “O-genki desu ka? (How are you?)” instead of “Hajimemashite! (Nice to meet you!)” (which is the first question in the digital prototype). From this, Mum was able to intuit that the answer was “Hai! Genki desu. (Yes, I’m well thanks)” due to the matching word. It was interesting to note that she felt this was a cheap way to arrive at the correct answer, when in actuality, this is precisely the TPRS language-learning method at work. That is, gap-filling and acquisition of meaning through contextualised use of language, especially within a story, and with minimal use of “translation” into the learner’s home language.

2. On the topic of “the context of a story”, Mum-- after getting past the first two questions without issue-- became stumped on the third question, and looked to the questions and answers for the first two questions for a clue. She seemed to be expecting the questions to follow an almost narrative order. I hadn’t considered anything of the sort, but I am now!

3. Mum preferred that she was able to check the English with greater immediacy than my original concept, which was that the player completed the entire level first in Japanese and then in English. She preferred to be able to check her answer immediately after submitting it, and on the whole, I realised this made for more satisfying and balanced gameplay, where the player experienced a reward at more appropriate intervals. This was also great feedback because it encouraged me to dig into the origin of my original concept, which stemmed from my desire to subvert the left to right platformer convention-- in particular, playing with the concept that Japanese is often traditionally written from right to left, etc. I’m not completely done with that idea quite yet, but I think it will need to manifest in a different manner to what I originally envisaged.

4. When testing the digital GDevelop prototype, Mum wanted to jump using the ‘up’ arrow, and I don’t blame her. I realised that I’d made that error on my own prototype more than once without thinking about it, and so I think I will alter those controls.

Taking into consideration, once again, that Mum is neither a gamer nor does she know or care to know a skerick of Japanese, I was really glad to find that she:

1. Actively enjoyed the game and was, dare I say, intellectually stimulated by it, and

2. Found it to have a satisfactory level of difficulty-- i.e. it was easy enough that she could experience success at appropriate intervals, but challenging enough that it held her attention and was not boring. This is something with which Tracy Fullerton goes into a lot of detail, but which he elegantly sums up on page 41: “Puzzles that are too easy are disappointing; puzzles that are too hard are discouraging.” Relevantly to my game, he goes on to say that his “favourite definition of ‘puzzle’” is: “1. A puzzle is fun, 2. And it has a right answer” (2018).

My only regret, once again, in testing both prototypes at this stage, is that they aren’t yet at a level where I can really test the interactions and relationships between the mechanics-- the systems-- of the game, as mentioned in the previous post.

SOURCES:

Alley, D., & Overfield, D. (2008). An analysis of the teaching proficiency through reading and storytelling (TPRS) method [Selected conference proceedings]. Southern Conference on Language Teaching. Southern Conference on Language Teaching.

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

The GDevelop prototype for my platformer, KitsuKana, has me feeling a bit foolish, if I'm to be truthful! I set out from the start with a somewhat ambitious concept-- just for a change-- and found out, the hard way, that my concept was a little too much to be quite appropriate for a two-week sprint (and the constraints of my as-yet undeveloped technical skillset as regards GDevelop).

Of course, biting off more than I can chew, in itself, has been a valuable learning experience (albeit one I apparently need to learn dozens of times). Trying to create a language-learning platformer straight off the bat, with no prior experience in GDevelop, has turned out to be a bit of a slog. I spent around six to seven hours yesterday learning how to implement a dialogue system-- which still doesn’t work the way it needs to in the prototype-- and haven’t had enough time to demonstrate some of the core mechanics in the depth I wanted to explore and test.

(I also don’t like its cosmetic appearance, but I completely acknowledge this is secondary to the need to actually test core game mechanics!)

The core questions I want to answer with my prototype/s for this game are:

Is the concept of a language-learning platformer:

1. viable, (i.e. practical), and

2. actually fun?

My solution to this, of course, has been to create a paper prototype too, as I felt it was the quickest way to try and get at the core game mechanics I wanted to really test.

Therefore, I’ve done up a board-game-style paper prototype, with counters, characters, etc etc. Incidentally, some of the materials I’ve created for this purpose, in a way, double as concept art.

Above: the Kitsune protagonist-- the player character

Above: an Oni NPC-- please pardon his lack of clothes. It’s very rough!

Above: a mask based on a traditional okane mask from Noh theatre.

My approach to the paper prototype was to create something vaguely tabletop-RPG like, and proved to be an extremely pragmatic way to hone and refine some of the moment-to-moment gameplay.

Developing a flashcard-style system for the various NPC phrases/questions and possible player responses gave rise to the following decisions:

1. The player, through the acquisition of the various masks, basically accumulates a “pool” of possible phrases from which they can draw to respond to the phrases/questions posed by NPCs

2. ...and therefore, each mask specifically represents a themed selection of these possible phrases. For example, in the prototype, acquisition of the okane mask will unlock phrases needed for Level 2, which I imagine will be the possible answers for “what is your name?” (Of course, the ins and outs of which mask represents which themes is more of a cosmetic, Production-phase set of decisions-- at this stage, I just want to test the idea of Masks = Phrases, regardless of which mask!)

3. Therefore, NPCs in and of themselves represent puzzles-- they will only let the player pass once they have selected an appropriate response/answer to the phrase/ question. (This was included in the game from the start, however the paper prototype helped me concretise this in my mind with a little more solidity.)

4. Each mask still, per my previous posts, confers upon the player various garden variety platformer abilities, such as varying kinds of jump or other movement, etc.