Self Esteam — Deliverable Report

Chris Stojkos
13 min readAug 13, 2019
Self Esteam — Preview Screenshot

My report for a published project, submitted as part of my master’s degree in Creative Media.

Published Project Link

https://duckpondfromscratch.itch.io/self-esteam

Simply click “Run Game” using (preferably) a Windows PC. It should run on a MAC perfectly fine, but it is untested. The playthrough is best enjoyed with clear volume and maximised to fullscreen.

A Google form is present on the published page, that has been gathering feedback — my data so far will reflect later in this report.

Have fun, and don’t mind the profanity. Chef Georgie means well.

Overview

Self Esteam is an alternate take on the visual novel (VN) genre in gaming. I set out to create a short, comical and light-hearted experience, with no skill-barrier entry requirements.

It is a text driven point-and-click game based in a restaurant setting that shows users a recipe to a food dish for a short amount of time. It proceeds to give multiple choice questions, to be answered in a flurry against a ticking clock, to concoct the recipe they had the brief chance to read. Players are then rated on their resulting dish and given commentary about their successes or — more likely — blunders.

The mechanics of this game are more about reading speed, attention to detail, and memory retention of said details, all under time constraints. They are less about being a ‘gamer’ with strong coordination skills, or having technical knowledge of game mechanics.

Self Esteam in its present form acts as a short slice of gameplay, closely resembling the tutorial of a game introducing itself to new players. It provides a vision and a strong foundation, with a wealth of room to grow into a full-fledged game, if pursued. Above all else, when you play my project, think about the potential it has in becoming a larger, marketable product.

Key Points

VN’s, by virtue of their mechanical simplicity, are a relatively easy-to-develop style of game. With the rise in indie game development however, this genre has rapidly become a saturated ‘quantity over quality’ market, rife with ‘asset flipping’ and ‘cookie-cutter’ style iterations. While this makes exposure and commercial competition a more difficult trial, it does elevate the cream-of-the-crop titles to an extraordinary regard, comparatively speaking.

During my initial pitch, I detailed that the VN genre has credibility, has been known to garner recognition, and that there is legitimate interest in particularly special titles that distance themselves from the pack. It was my conviction on this subject that spurred my inspiration for Self Esteam — to my knowledge its gameplay is quite unique when considering the standard-VN-development tool ‘Fungus’ (Gregan, O’ Kane & Pearce, 2019), that I used to create it.

Gameplay mechanics and general aesthetic aside, its other key feature lies in its fully voiced Australian narration (for better or for worse). Fully voiced narration can be crucial in bringing a game from mediocre to engaging — it brings a narrative and its characters out of the proverbial (or literal) pages, and breathes life into them. During testing, it would be the voicing feature that would receive the highest amount of positive feedback — I will be elaborating further on my feedback gathering process and results later in this report.

Though English voice casting would certainly complicate things if it came to be marketed internationally, for the scope and scale of this project in its current form it most definitely proved itself a boon.

Ideation

Throughout its development, the core design of Self Esteam changed significantly. Admittedly, it began with a foundation that was not solidified, and if anything it initially was a little directionless. To some degree however, this was by design — which sounds awfully convenient, so allow me to elaborate.

During my ideation process, when it comes to selecting an idea for a new project to develop, often times I will opt for a less-than-fleshed-out design. It is my ideology that the best ideas for games happen during development, and these are often unplanned. I call it emergent game design; and this idea is not one of originality.

Dormens (2008) and Sweetser (2006) both speak of emergence in games in differing contexts, but the general consensus remains the same. The player experience is more unique, ergo improved, as a result of emergence playing a role in a game’s design. Personally, I take the idea of emergence, and apply it to my ideation and design processes in their earliest stages. By forging ahead with incomplete designs, it leaves room for growth at every stage of development.

The resultant ideas and features that stem from this facilitated process, are guided by what feels better in a practical sense; they are less theory-based than their counterparts that began as products of pre-development brainstorming (Stojkos, 2019).

Simply put, if I leave space for ideas to spring up during development, the features that are born from this process are tailored by what feels right with what is in front of me in that moment. Most often I find spur of the moment additions fit the style and feel of the game better than the old ideas that came about during initial planning. Overly rigid adherence to planning can be a huge hindrance to creative freedom in game development.

A New Direction

As mentioned above, the design of my project took quite a turn as my ideas evolved during development. Originally the gameplay was much more freeform, almost like a sandbox-style kitchen. Picture an interface full of kitchen tools and ingredients, with the goal being to make a certain dish. Customise your method of cooking, what tools and ingredients you use, and so on. Selecting wrong or right choices would provoke reaction from the narrator watching over your shoulder, and you would progress through the game depending on your performance, and relationship with your in-game characters.

In theory, this could be a fun game; many a player would find a great deal of enjoyment in exploring the variety of choices available to them, and experiencing the different reactions and results. Behind the scenes however, this posed a programming nightmare, and an exponentially increasing scope with even the smallest of modifications to the scene. Even adding a single tool or ingredient would mean needing to program the way that asset interacts with every other existing tool, and all of the potential results in a meal.

Maybe I could have presented a fairly conservative version of this method to some degree, but I remain doubtful it would have appeared ‘complete’ given the time available to me; I pride myself on presenting my projects with a relative amount of polish. It was at the point of sourcing my recipes from my late grandmother that the direction took a sharp turn into a much more well-rounded design.

Progression — Milestone (1)

The recipes used in Self Esteam were all handwritten in the 80s, and have lived in a small box that gets passed down my family tree. My personal investment towards this project changed quite significantly as a result from this, as one might expect. My intention was merely to source recipes that I would have the full rights to, simply to avoid needing to worry about the copyright issues and general politics of my project. The intent was to be able to focus on my creativity and follow my ideation process through. I did not account for the different mixture of feelings; ranging from inspiration, to a sense of responsibility, that would be invoked within me.

Fig1. First milestone of Self Esteam mechanics development

As soon as I had a (personally) real recipe, I discovered my desire to see it done right; the game’s design was suddenly much less about cooking whatever one could think of. It became about cooking this specific dish correctly in a fun and engaging way, with a low entry level so anyone is able to enjoy the experience.

When I read the (questionably-legible) recipes, the ideas of how I would concoct this more linear style of game quickly began to flood in and fall into place — multiple choice options directing players towards the same goal. The game would be ‘mean’ and attempt to trick players with very slightly differing options (IE: boil the rice & broil the rice), that may cause you to select the wrong options in a panic, given the time constraints. My uncertainty about the project quickly turned into myself having fun; I was projecting how I misread the recipes onto my users, now I was the ‘mean’ one. This was the turning point that took the game mechanics from an out-of-scope disaster, to the results you see in your playthrough.

The reason for the above screenshot being my first milestone is that there was not much to show prior to this. After discovering my inspiration, creating the beginnings of my system’s mechanics was all in a positive and inspired night’s work. It represents what was very much a mental ideation milestone.

Milestone (2)

Fig2. Second milestone, timer (red) and logic system behind multiple choice options programmed

I have marked this as a key point in my rapidly evolving progression; this was the point where I polished and debugged my logic system, to a point where it was ready to be replicated with minimal hassle. Though visibly the results would be the same; working the timer to trigger and accept a number of different choices took a lot of experimentation. One example of many, would be letting the timer run its course after clicking an option early, or if it should immediately jump to the next option with no pause. Should it be the option selection that triggers the next section, or should there be an overarching governing system, and so on; I would never finish explaining every variant I tried, tested, and subsequently trashed.

Once I had the first couple of multiple choice questions and answers functioning together with the timer and score tally — completely bug-free — the rest of development was more about repeating this process for each recipe. The first couple of questions & answer sections in the game were certainly the most grueling, and took the longest amount of time to get right; this is because they were to be the template to finish the rest of the game with.

This was also the stage where I finalised the script, which came as a huge relief; it took a lot of rewrites and refining, despite its harsh and dry humour! This mid-development milestone was also around the time my third party assets began to trickle in, such as the background art, and our completing the audio voice recording session at my local Perth SAE campus. It still amazes me how a game can jump from looking nowhere near complete, to a charming and polished model, once it achieves its aesthetic goals in a few clicks of a button.

Milestone (3)

Fig3. All mechanics and logic programmed, adding audio, feedback, and visual polish

My final marked milestone is a simple representation of how the logic and ‘narrative’ branched out and grew, once the largest initial blocks in creating perfect template mechanics were overcome. Most of the art was implemented, and from this point on it was a matter of perfecting audio and visual cues; largely polish aspects — my taking the time to appreciate the little things, which I believe makes a world of difference when it comes to rapid prototype style projects.

A small example of this would be my implementing the physical paper with your grade scrawled on it — originally this was purely text and voice from Chef Georgie, and did not feature the satisfying slap of your result on some shoddy paper. After much testing I felt this portion was lacking some ‘oomf’, and I drew up the A-F grades by hand (which is about as far as my own artistic drawing talent extends).

External Testing and Feedback

During the later stages of development I took an alpha version of my game down to my local campus. I organised with the game lecturers there whom I know quite well, to have my game played by students and staff alike, and to leave feedback on enjoyable and poor points to the playthrough. This was a bit of a new experience for me, as it can be hard to put oneself out in front of a scrutinising audience, but surely that is part of what our Graduate Studio has been about. In the same vein, I also gathered feedback post-publishing from both my peers in the MCI, and players from the general public who visited the website.

The voice acting received the highest praise, it was rated as well-executed, and that it very much helped with getting the comedy and intended feel of the game across to users. When compared to a non-voiced version, there was no contest. I agreed with all of this feedback and it justified my reasoning in having it fully voiced in the first place (my reasoning being that I felt it would deliver the comedy much more effectively).

The more negative pieces of feedback received relate to the recipe layout. Players most often found themselves memorising the ingredient amounts at the top of the recipe pages; these do not actually play any part when it comes to selecting the multiple choice answers however. The result of this being that players felt they wasted their short time memorising unimportant details, which has a negative effect on their enjoyment factor — they may feel ‘cheated’ out of their win. By my theory and design this was intentional, that the recipe would be misleading, but it does not appear to have carried over in the manner I envisioned. If I were to continue development, I would either cut the ingredients out of the recipe pages, or more preferably, I would incorporate the recipe amounts into the answers. I only did not implement the latter as it would be an exponential workload increase — the amount of possible endings from getting the ingredients wrong as well as the method would skyrocket.

Other feedback was that Self Esteam has a charming aesthetic and a very strong and unexpected opening.

Direction should development continue

Self Esteam has real potential to grow; as each stage of development progressed, I found myself mulling over the wealth of features and differing styles of gameplay that could be implemented in a larger scaled version. Currently, the timer is the main factor in terms of current difficulty setting, and it is no doubt the focal point for new players. However, the time-allotted for each round can only get so low before the game actually becomes impossible. It should also be pointed out that over long-term play, the timer aspect would become second nature, and new ‘distractions’ that play on user’s attention to detail would need to be implemented. This will be a short discussion on experimental ideas for adding variety and natural difficulty should the scope of this project expand.

The difficulty curve naturally increases as players become accustomed to skipping passed reading the ingredients, and focusing on the method. There is potential to play on these expectations, and throw in a round where it simply queries the ingredients, rather than the method.

The alternating handwritten-style fonts also play a factor in the game’s current stages, this can be expanded upon by inserting more difficult to read fonts, differing colours, and more ragged quality of paper that the instructions are written on (IE a small part of the answer is omitted by a folded or torn-off corner).

An idea for a different round is one that relies purely on memory, retaining details on colour and shape. There could be differently coloured pieces of paper, with the text on each written in alternating colours as well — players would be required to remember as much as they could of the layout in a short time. They would then be asked to recall specific details on perhaps the order of the paper or text colours only. I would seek to incorporate existing styles of ‘brain games’ which require players to differentiate between the written text, and colours.

For example:

BLUE - GREEN - WHITE (each written and highlighted in colours different to their corresponding word)

Players would then be asked; what was the colour of the text / backgrounds, or, what words were written on each card?

In general, the aim of what the game tries to do to players is distract their attention even if only for a moment — this still translates to a precious amount of time when they only receive a handful of seconds to work with. Shaking / shuddering, drastic audio notifications, more urgent timer variants, differing colours, fonts, papers of varying quality, miscellaneous noises, multitasking; these are all aspects that would fit in with the current style of the game. Each would potentially be a contributing factor towards accomplishing the ultimate goal — to be a pest.

Reflection

I began this project frustrated and unmotivated. I felt pressure to forge ahead with a game idea that I was uncertain about, and had not considered thoroughly enough due to course time constraints; this led to frustration and delays in getting my project off the ground. Like always though, I trusted myself, believed in my ideation process — which is somewhat more about creative improvisation and working ‘on the fly’ — and I came out the other end of the tunnel with a product I am actually quite pleased with. I ended up sharing it quite widely, and it has given me a fun little project to link to people in casual conversation when discussing what exactly it is that I do.

The change in direction with the gameplay saved this project, and I truly believe it gets the message across that this is a foundation of a concept that holds a lot of potential to grow. In the end I quite enjoyed working on the game — the audio recording session we held was a hilarious and positive night for all involved. I widened my net of contacts as a result of my enlisting third parties to assist (art, audio, etc), and I got to see people enjoy this game for what it was always meant to be; a charming and funny little gem. Very early on in the Graduate Studio unit, I mentioned that I had written quite serious and emotional material prior, and it had become a bit draining, especially when it was voice acted! This was a therapeutic release of that built-up tension.

It is always reassuring to see positive feedback, and my ‘comedy’ material actually create laughter. To that end I owe much to the positive working environment that the MCI aims to facilitate, as I am sure others do as well, whether they realise it or not.

Bibliography

Arsenault, D. (2006). Narration in the video game. Montreal: Université de Montreal.

Dormans, J. (2008). Visualizing game dynamics and emergent gameplay. In Proceedings of the Meaningful Play conference.

Gregan, C., O’ Kane, J., & Pearce, R. (2019). Fungus (Version 3.11.5) [Unity]. Ireland: Snozbot.

Stojkos, C. (2019). Devlog-CreativeProcess. Retrieved 8 August 2019, from https://duckpondfromscratch.itch.io/devlog-creativeprocess

Sweetser, P. (2006). An emergent approach to game design: Development and play. PhD diss.: University of Queensland.

--

--

Chris Stojkos

This blog is part musings, part job stuff, part Master degree writing