Personal aims and objectives
For my final major project I chose to create a procedural narrative game – one that would attempt to stage a rehearsal of Chekhov’s The Seagull, but without the input of the writer or director – titled Chekhov’s Gone! This project was inspired by the work I had performed over the summer on my thesis, which looked at game dialogue design through the lenses of time, space and interface. By presenting a diverse number of dialogue designs and interfaces – summary vs scene, spatially segmented vs fixed perspective (Wei et al, 2010), integrated vs superimposed and ludic vs fictional (Jorgenson, 2013) – I hoped to create something that could be enjoyed by many types of player personae, not just those that enjoy reading a whole bunch.
As ever, I was keen to stretch my technical side by learning some new skills, and I set my sights on something that had intrigued me from earlier in the course: agent behaviour. This is a core part of one of my all-time favourite games, Dwarf Fortress, which also features heavy procedural generation and emergent narratives – I was excited to see what I could learn from it.
Playthrough of Final Prototype
Summary of development
My research into this project was mostly through my thesis – over the summer I had gathered a rich range of inspirational games that used dialogue in different ways, and I was excited to create something that repositioned a player’s understanding of dialogue design. I used tutor input to help me select my direction, which was for a Lemmings-style agent behaviour game based off a theatre rehearsal.
The project reminded me a lot of Dwarf Fortress – in a much simplified version – so I also performed a case study of that game, using the frames identified in my thesis to analyse its use of time, space and interface in communicating dialogic and narrative information to its players. Tarn Adams’ designs for dwarven thoughts and preferences, as well as Stanislavski’s work on actor training provided the framework for my initial designs for agent behaviour and interaction. However, by the time I had a clear idea of how to proceed with any of this, I had only seven weeks left to make the project!
In the first few weeks I focused on setting up an efficient pipeline for adding different agents and objects to the game. This involved understanding Scriptable Objects and how their data can be fed into class instances at runtime, as well as some .csv translation that would enable large amounts of objects to be created in an accessible spreadsheet format and loaded in batches. The learning curve for this was quite high, but I now feel a certain confidence in coding modular foundations for games in general, which is good.
The majority of my development work then went into designing and coding behaviour loops for the game’s agents. This was a more enjoyable challenge than the aforementioned more tools-based work, and I was surprised at how well some of the approaches from earlier MA projects fitted this one. Due to time pressures I wasn’t able to reach the level of behavioural complexity that I was seeking, nor was I able to implement much of a procedural text generator to connect to it, but the modularity of my loop leaves room for further iteration and expansion.
In the final stages of the project I began soliciting player feedback from friends, coursemates and tutors, and most of it drove me towards developing and sharpening the game’s UI. This synthesis of feedback and late-stage experimentation was a crucial step in reconnecting me to my original creative drive, and much of the game’s ‘game-iness’ came from these final buttons, sounds and animations. Game design, as ever, remains a highly holistic discipline – once I had even a sprinkling of visuals and audio, I could see how best to finish the final prototype.
Critical reflection
In terms of organisation, there are a lot of things I would improve. Waiting to reach the conclusion of my thesis before beginning my experimentation, as well as moving house a lot of times over the summer, cost me a lot of time. My initial work on making an efficient content delivery system in many ways distracted me from reaching the iteration part of my design. In retrospect, the way that I set up some of my classes would also prove difficult – although Actors and Items were happy to be serialized in the inspector, Areas were not. This is due to them containing lists of other Areas, which of course contain lists of other Areas – the level of recursion was too much for Unity to handle. This caused me difficulty when debugging – although it was far easier to access connections between these classes in the code itself, it might have been more valuable to be able to observe their behaviour more clearly in-game. If I had realised this earlier I also wouldn’t have burned three crucial days towards the end of the process trying to make an impossible-to-implement-given-my-data-structure rewind mechanic. When considering my work in the context of the game development life cycle (Widyani, 2013), I spent too much time in the foundational stage, and too little in the experimental and structural stages. This left me with an unbalanced product when I approached hand-in, and forced me to begin refining work that I didn’t necessarily consider to be finished.
While the idea behind Chekhov’s Gone! stood thematically and formally within my comfort zone, mechanically it required me to do a lot of learning. I think I was taken in by being able to talk cogently about how actors function on stage without really understanding the amount of work it would take to render that into a game, but this is itself a very good lesson, especially if I end up working on procedural narratives in the future! Also, going through the process of devlog reflection helped me keep the frames identified in my thesis in mind during the development period, not just in the design period – for works of this potential complexity it is very easy to get lost in the code, something I was definitely guilty of!
Chekhov’s Gone! itself functions at the most basic of its levels; most of its methods are still set to random outputs rather than being truly responsive. I have had to spend the majority of the last few weeks making it intuitive and grokkable for the player, rather than deepening or broadening any of its systems, as I would have preferred – however, this has refocused me on my original designs, and on the inspirations behind the game. Even if it’s not as complex as I had intended, I’m proud of its toy-like level of interactivity and feedback. I’m also reassured by the modularity of its underlying code – between submission and the showcase exhibition I plan to bring it closer to the product I had imagined.
In the future I will be sure to bring UI in a lot earlier, budget more time for design and content creation, and keep the tools designing to a minimum. If this project has been clear case of me playing into Derek Yu’s Inventor archetype, it has certainly been a valuable one.
References
Jorgenson, K. (2013) Gameworld Interfaces. Cambridge MA: MIT Press.
Stanislavski, C. (1937) An Actor Prepares. Translated by Hapgood, E. London: Methuen Drama.
“Thoughts and preferences.” <https://dwarffortresswiki.org/index.php/Thoughts_and_preferences> (Accessed on: October 15th, 2021)
Wei, H., Bizzocchi, J. & Calvert, T. (2010) “Time and Space in Digital Game Storytelling” in International Journal of Computer Games Technology, Vol 2010.
Widyani, Y. (2013) ‘Game Development Life Cycle Guidelines.’ Proceedings of ICACSIS 2013.
Yu, D. (2021). Indie Game Dev: Indie Archetypes. <https://www.derekyu.com/makegames/archetypes.html> (Accessed on: November 22nd, 2021)