Monday, January 19, 2015
A Comic About Grace Hopper
Ramya from Udemy shared a neat little comic with me about Grace Hopper, and said I could share it here. You can look at the comic on their website, too, where you can also order a Grace Hopper sticker if you live in the US. Enjoy!
Tuesday, January 13, 2015
How Gameplay Affects Stories in Games
I am very interested in the role of storytelling in videogames. Although I do like games without stories as well, the story is often the part of a game that engages me the most. For my thesis proposal, I spent some time thinking about how stories integrate into games, and realized that some of the existing ways to analyze them didn't quite suit my needs. Below is an excerpt from my proposal discussing a spectrum I came up with instead.
We are interested in the application of interactive storytelling in videogames. In particular, we want to create a more satisfying story experience in open-world adventure and role-playing games. A game that features an open world allows its players to move freely in a large space with few or no artificial barriers, choosing what to do and when. The flexibility of an open world and the fact that adventure and role-playing games tend to have strong story components [1] make these genres an interesting place to explore interactive storytelling techniques.
Combining IS and games introduces a new challenge: a balance must be achieved between creating a satisfying story and maintaining a reasonable level of player control in both the story and gameplay. This is no easy task, as Costikyan points out: “Divergence from a story's path is likely to make for a less satisfying story; restricting a player's freedom of action is likely to make for a less satisfying game” [2]. It also brings an important difference between interactive storytelling and storytelling in games to the forefront. In traditional interactive storytelling, the IS system is primarily responsible for arranging the story being told, making adjustments according to user interactions. When telling interactive stories with games, however, it is the gameplay that drives the story forward and determines how it should unfold. Gameplay is what we call the interaction between players and a game system's rules [3]. Gameplay includes physically moving through an open world's space, fighting enemies, conversing with non-player characters, and collecting items.
Some gameplay actions might allow players to interact with the game's story elements, and others can indirectly affect the direction of the story. Viewed as a spectrum (Figure 1), the least interactive types of game stories come as a result of gameplay not having any effect on the story at all. The most interactive stories are directly affected by gameplay. In the middle, stories are affected by gameplay, but only indirectly. Many authors who wish to create compelling story experiences in games aim to create experiences as far right on the spectrum as possible, but several challenges make this more difficult than it may seem.
Lebowitz and Klug [1] also proposed a spectrum to analyze videogame stories (Figure 2). As presented, non-interactive stories are at the far left. The level of control that players have over the story increases to the right of the spectrum. Implicitly, the spectrum also captures how much control an author has over a story, with the largest level of control to the far left. Furthest right, the author has no control at all; games that Lebowitz and Klug call fully player-driven are highly emergent with no set plot.
We are more interested in how directly gameplay affects a story rather than the magnitude of control the player has, partly because gameplay and story often feel like separate activities. Furthermore, most open-world games we are interested in fit into the open-ended story category of Lebowitz and Klug’s spectrum, which they characterize as games that allow players to progress how they wish and that often (but not always) feature open worlds. Some open-world games allow players to explore and complete various tasks without any relation to the story. Others have similar tasks to complete, but doing so will cause the story to change in some way. We want to be able to distinguish games within the open-ended category, and we are able to do so with our spectrum.
In the following, we discuss the types of strategies used to implement game stories across our spectrum and discuss problems that arise for each. We begin at the far left of our spectrum, where gameplay has no effect on story. This does not necessarily mean that the game is not an example of interactive storytelling, as the player may be able to interact with the story in ways that do not change it. The player might choose which parts of the story to consume and when, explore the world the story is set in, or interact with the characters within. Games in the Zelda series, such as The Legend of Zelda: Skyward Sword, feature fixed stories but allow the player to converse with non-player characters and take on missions that have no story consequences. Not allowing gameplay to affect a story results in stronger authorial control over how the story unfolds. However, it also introduces a risk of creating gameplay that does not align well with the narrative being told, especially in games that offer much freedom in terms of how to approach gameplay. A story told about a hero that in gameplay can rob innocent citizens at will leads to ludonarrative dissonance, a term originally coined by Clint Hocking. Red Dead Redemption openly tracks the player's heroism, but it does not matter how heroic the player is deemed to be: non-player characters treat the player character the same way, and the same tasks are required of him. The worst case of a story not affected by gameplay is a “constipated story,” where strictly alternating presentations of gameplay and story fail to interact with each other at all [4].
Stories that are indirectly affected by gameplay lie in the middle of our spectrum. With such games, players do not directly make choices that alter the course of a story. Instead, players interact with the game system, resulting in changes to the game state. How the story is presented or arranged depends on the current game state. For example, a portion of a story might only be available if the player character has enough experience points. Many areas of Fallout 3 were technically available all the time, but the player could only survive long enough to explore them after gaining enough experience points through gameplay elsewhere. Alternatively, the outcome of a plot point might depend on how evil the player acted in previous encounters. In Fable II, the player has opportunities to be good or evil through various tasks. Which approach is chosen unlocks some new tasks, and changes the player character's appearance on screen. Some games with branching stories, including those with multiple endings, are also found near the middle of the spectrum. In BioShock, for example, gameplay actions indirectly cause the story to change. The game ends differently depending on what the player decides to do with certain characters that can either be spared or harvested for player benefit.
The structuralist approach of defining an implicit graph at run-time could be applied here; gameplay statistics can be used in scene preconditions, for example. Although players can only affect the story indirectly, most players will be satisfied. In two surveys of game players, Mallon and Webb [5] discovered that players actually prefer episodic and directed story experiences over unrestricted freedom, and Lebowitz and Klug [1] found that while the majority of players place great importance on a game’s story, they do not require full control over it.
Games with quests commonly feature gameplay that indirectly affects story [1, 6]. A quest system in a game is used to organize what quests are available and when. It will also take care of offering quests to the player, possibly through conversations with non-player characters or markers in the world the player interacts with to trigger a quest. Many games with open-ended stories feature quest systems. Each quest contains a fragmentary story and provides short-term gameplay goals [7, 8]. Story consistency is enhanced by making the quests self-contained and largely independent [8]. As a result, completing a quest reveals a portion of the game's story that the player would not otherwise see, but rarely affects any other part of the story. The only indirect effect of choosing a quest through gameplay is the addition of the non-essential bit of story contained within. The stories revealed in quests would likely be more interesting if they connected better with what happens in the core plot; instead, they often feel like busy work, or little more than a way to improve your character's statistics.
If quests were less task-based and more goal-oriented, they might lie closer to the right of our spectrum where gameplay directly affects story. Quests in videogames tend to focus on tasks such as fetching items or engaging in combat instead of higher-level goals that can be achieved in various ways [7, 9, 10]. Instead of asking players to complete tasks, quests could be used to introduce meaningful conflict between characters that the player must resolve through gameplay, allowing for more direct interaction with the story. Games in the Mass Effect series use quests to introduce conflict between characters. Sullivan's GrailGM framework [10], designed to work with game mechanics based on social moves, also allows for conflict-oriented quests. GrailGM makes quests available based on the current social dynamics between player and non-player characters in the story. Players have the choice to complete the quest as put forth by the quest giver, or to create conflict by going against the quest giver's wishes. If more quests were explicitly connected to the game's main storyline, the gameplay act of choosing a quest could give a stronger sense of affecting the story.
There are games that more clearly lie to the right of our spectrum. Some games make their core mechanic a direct interaction with the story, as in Telltale Games’ The Walking Dead series. In The Walking Dead, players are primarily asked to decide how the main character should respond to various situations. Heavy Rain offers similar gameplay with one interesting difference. When players fail to complete an action move, the game does not ask them to try again. Instead, the following scene or scenes continue, but the exact content is affected by whether the player has failed or succeeded. Sometimes gameplay as simple as which quests the player chooses to embark on can directly impact the story. For example, Fallout: New Vegas tracks statistics about who the player is most loyal to. Which quests the player completes can affect loyalty and, by extension, how certain parts of the story will play out.
A challenge of games whose gameplay directly affects the story is to find ways to allow players to make meaningful dramatic decisions. The Walking Dead is a game that almost entirely consists of what appears to be dramatically significant choices. However, most choices the player makes impact only the next line of dialog, nothing more. While perceived agency can be important [11], it is easy to have the effect wear off when few or none of your choices are dramatically relevant.
---
[1] J. Lebowitz and C. Klug. Interactive Storytelling for Video Games. Focal Press (2011).
[2] G. Costikyan. Second Person: Role-Playing and Story in Games and Playable Media, chapter Games, Storytelling, and Breaking the String, pages 5 13. MIT Press (2007).
[3] K. Salen and E. Zimmerman. Rules of Play: Game Design Fundamentals. The MIT Press (2003).
[4] C. Crawford. Chris Crawford on Interactive Storytelling. New Riders, 2nd edition (2012).
[5] B. Mallon and B.Webb. Stand up and take your place: identifying narrative elements in narrative adventure and role-play games. Computers in Entertainment (CIE) 3, 1 20 (2005).
[6] J. Howard. Quests: Design, Theory, and History in Games and Narratives. A K Peters, Ltd. (2008).
[7] E. Aarseth. From hunt the wumpus to everquest: Introduction to quest theory. In F. Kishino, Y. Kitamura, H. Kato, and N. Nagata, editors, Entertainment Computing - ICEC 2005, volume 3711 of Lecture Notes in Computer Science, pages 496 -506. Springer Berlin Heidelberg (2005).
[8] M. Trenton, D. Szafron, J. Friesen, and C. Onuczko. Quest patterns for story-based computer games. In Proceedings of the Sixth Arti cial Intelligence and Interactive Digital Entertainment Conference (AIIDE) (2010).
[9] C. Lindley. Developing Interactive Narrative Content: sagas/sagasnet reader, chapter Story and Narrative Structures in Computer Games. High Text Verlag (2005).
[10] A. Sullivan. The Grail Framework: Making Stories Playable on Three Levels in CRPGs. Ph.D. thesis, University of California Santa Cruz (2012).
[11] M. W. Fendt, B. Harrison, S. G. Ware, R. E. Cardona-Rivera, and D. L. Roberts. Achieving the illusion of agency. In D. Oyarzun, F. Peinado, R. Young, A. Elizalde, and G. Méndez, editors, Interactive Storytelling, volume 7648 of Lecture Notes in Computer Science, pages 114 -125. Springer Berlin Heidelberg. (2012).
We are interested in the application of interactive storytelling in videogames. In particular, we want to create a more satisfying story experience in open-world adventure and role-playing games. A game that features an open world allows its players to move freely in a large space with few or no artificial barriers, choosing what to do and when. The flexibility of an open world and the fact that adventure and role-playing games tend to have strong story components [1] make these genres an interesting place to explore interactive storytelling techniques.
Combining IS and games introduces a new challenge: a balance must be achieved between creating a satisfying story and maintaining a reasonable level of player control in both the story and gameplay. This is no easy task, as Costikyan points out: “Divergence from a story's path is likely to make for a less satisfying story; restricting a player's freedom of action is likely to make for a less satisfying game” [2]. It also brings an important difference between interactive storytelling and storytelling in games to the forefront. In traditional interactive storytelling, the IS system is primarily responsible for arranging the story being told, making adjustments according to user interactions. When telling interactive stories with games, however, it is the gameplay that drives the story forward and determines how it should unfold. Gameplay is what we call the interaction between players and a game system's rules [3]. Gameplay includes physically moving through an open world's space, fighting enemies, conversing with non-player characters, and collecting items.
Figure 1: Our spectrum of how storytelling integrates with gameplay
Some gameplay actions might allow players to interact with the game's story elements, and others can indirectly affect the direction of the story. Viewed as a spectrum (Figure 1), the least interactive types of game stories come as a result of gameplay not having any effect on the story at all. The most interactive stories are directly affected by gameplay. In the middle, stories are affected by gameplay, but only indirectly. Many authors who wish to create compelling story experiences in games aim to create experiences as far right on the spectrum as possible, but several challenges make this more difficult than it may seem.
Figure 2: Lebowitz and Klug's storytelling in games spectrum
Lebowitz and Klug [1] also proposed a spectrum to analyze videogame stories (Figure 2). As presented, non-interactive stories are at the far left. The level of control that players have over the story increases to the right of the spectrum. Implicitly, the spectrum also captures how much control an author has over a story, with the largest level of control to the far left. Furthest right, the author has no control at all; games that Lebowitz and Klug call fully player-driven are highly emergent with no set plot.
We are more interested in how directly gameplay affects a story rather than the magnitude of control the player has, partly because gameplay and story often feel like separate activities. Furthermore, most open-world games we are interested in fit into the open-ended story category of Lebowitz and Klug’s spectrum, which they characterize as games that allow players to progress how they wish and that often (but not always) feature open worlds. Some open-world games allow players to explore and complete various tasks without any relation to the story. Others have similar tasks to complete, but doing so will cause the story to change in some way. We want to be able to distinguish games within the open-ended category, and we are able to do so with our spectrum.
In the following, we discuss the types of strategies used to implement game stories across our spectrum and discuss problems that arise for each. We begin at the far left of our spectrum, where gameplay has no effect on story. This does not necessarily mean that the game is not an example of interactive storytelling, as the player may be able to interact with the story in ways that do not change it. The player might choose which parts of the story to consume and when, explore the world the story is set in, or interact with the characters within. Games in the Zelda series, such as The Legend of Zelda: Skyward Sword, feature fixed stories but allow the player to converse with non-player characters and take on missions that have no story consequences. Not allowing gameplay to affect a story results in stronger authorial control over how the story unfolds. However, it also introduces a risk of creating gameplay that does not align well with the narrative being told, especially in games that offer much freedom in terms of how to approach gameplay. A story told about a hero that in gameplay can rob innocent citizens at will leads to ludonarrative dissonance, a term originally coined by Clint Hocking. Red Dead Redemption openly tracks the player's heroism, but it does not matter how heroic the player is deemed to be: non-player characters treat the player character the same way, and the same tasks are required of him. The worst case of a story not affected by gameplay is a “constipated story,” where strictly alternating presentations of gameplay and story fail to interact with each other at all [4].
Stories that are indirectly affected by gameplay lie in the middle of our spectrum. With such games, players do not directly make choices that alter the course of a story. Instead, players interact with the game system, resulting in changes to the game state. How the story is presented or arranged depends on the current game state. For example, a portion of a story might only be available if the player character has enough experience points. Many areas of Fallout 3 were technically available all the time, but the player could only survive long enough to explore them after gaining enough experience points through gameplay elsewhere. Alternatively, the outcome of a plot point might depend on how evil the player acted in previous encounters. In Fable II, the player has opportunities to be good or evil through various tasks. Which approach is chosen unlocks some new tasks, and changes the player character's appearance on screen. Some games with branching stories, including those with multiple endings, are also found near the middle of the spectrum. In BioShock, for example, gameplay actions indirectly cause the story to change. The game ends differently depending on what the player decides to do with certain characters that can either be spared or harvested for player benefit.
The structuralist approach of defining an implicit graph at run-time could be applied here; gameplay statistics can be used in scene preconditions, for example. Although players can only affect the story indirectly, most players will be satisfied. In two surveys of game players, Mallon and Webb [5] discovered that players actually prefer episodic and directed story experiences over unrestricted freedom, and Lebowitz and Klug [1] found that while the majority of players place great importance on a game’s story, they do not require full control over it.
Games with quests commonly feature gameplay that indirectly affects story [1, 6]. A quest system in a game is used to organize what quests are available and when. It will also take care of offering quests to the player, possibly through conversations with non-player characters or markers in the world the player interacts with to trigger a quest. Many games with open-ended stories feature quest systems. Each quest contains a fragmentary story and provides short-term gameplay goals [7, 8]. Story consistency is enhanced by making the quests self-contained and largely independent [8]. As a result, completing a quest reveals a portion of the game's story that the player would not otherwise see, but rarely affects any other part of the story. The only indirect effect of choosing a quest through gameplay is the addition of the non-essential bit of story contained within. The stories revealed in quests would likely be more interesting if they connected better with what happens in the core plot; instead, they often feel like busy work, or little more than a way to improve your character's statistics.
If quests were less task-based and more goal-oriented, they might lie closer to the right of our spectrum where gameplay directly affects story. Quests in videogames tend to focus on tasks such as fetching items or engaging in combat instead of higher-level goals that can be achieved in various ways [7, 9, 10]. Instead of asking players to complete tasks, quests could be used to introduce meaningful conflict between characters that the player must resolve through gameplay, allowing for more direct interaction with the story. Games in the Mass Effect series use quests to introduce conflict between characters. Sullivan's GrailGM framework [10], designed to work with game mechanics based on social moves, also allows for conflict-oriented quests. GrailGM makes quests available based on the current social dynamics between player and non-player characters in the story. Players have the choice to complete the quest as put forth by the quest giver, or to create conflict by going against the quest giver's wishes. If more quests were explicitly connected to the game's main storyline, the gameplay act of choosing a quest could give a stronger sense of affecting the story.
There are games that more clearly lie to the right of our spectrum. Some games make their core mechanic a direct interaction with the story, as in Telltale Games’ The Walking Dead series. In The Walking Dead, players are primarily asked to decide how the main character should respond to various situations. Heavy Rain offers similar gameplay with one interesting difference. When players fail to complete an action move, the game does not ask them to try again. Instead, the following scene or scenes continue, but the exact content is affected by whether the player has failed or succeeded. Sometimes gameplay as simple as which quests the player chooses to embark on can directly impact the story. For example, Fallout: New Vegas tracks statistics about who the player is most loyal to. Which quests the player completes can affect loyalty and, by extension, how certain parts of the story will play out.
A challenge of games whose gameplay directly affects the story is to find ways to allow players to make meaningful dramatic decisions. The Walking Dead is a game that almost entirely consists of what appears to be dramatically significant choices. However, most choices the player makes impact only the next line of dialog, nothing more. While perceived agency can be important [11], it is easy to have the effect wear off when few or none of your choices are dramatically relevant.
---
[1] J. Lebowitz and C. Klug. Interactive Storytelling for Video Games. Focal Press (2011).
[2] G. Costikyan. Second Person: Role-Playing and Story in Games and Playable Media, chapter Games, Storytelling, and Breaking the String, pages 5 13. MIT Press (2007).
[3] K. Salen and E. Zimmerman. Rules of Play: Game Design Fundamentals. The MIT Press (2003).
[4] C. Crawford. Chris Crawford on Interactive Storytelling. New Riders, 2nd edition (2012).
[5] B. Mallon and B.Webb. Stand up and take your place: identifying narrative elements in narrative adventure and role-play games. Computers in Entertainment (CIE) 3, 1 20 (2005).
[6] J. Howard. Quests: Design, Theory, and History in Games and Narratives. A K Peters, Ltd. (2008).
[7] E. Aarseth. From hunt the wumpus to everquest: Introduction to quest theory. In F. Kishino, Y. Kitamura, H. Kato, and N. Nagata, editors, Entertainment Computing - ICEC 2005, volume 3711 of Lecture Notes in Computer Science, pages 496 -506. Springer Berlin Heidelberg (2005).
[8] M. Trenton, D. Szafron, J. Friesen, and C. Onuczko. Quest patterns for story-based computer games. In Proceedings of the Sixth Arti cial Intelligence and Interactive Digital Entertainment Conference (AIIDE) (2010).
[9] C. Lindley. Developing Interactive Narrative Content: sagas/sagasnet reader, chapter Story and Narrative Structures in Computer Games. High Text Verlag (2005).
[10] A. Sullivan. The Grail Framework: Making Stories Playable on Three Levels in CRPGs. Ph.D. thesis, University of California Santa Cruz (2012).
[11] M. W. Fendt, B. Harrison, S. G. Ware, R. E. Cardona-Rivera, and D. L. Roberts. Achieving the illusion of agency. In D. Oyarzun, F. Peinado, R. Young, A. Elizalde, and G. Méndez, editors, Interactive Storytelling, volume 7648 of Lecture Notes in Computer Science, pages 114 -125. Springer Berlin Heidelberg. (2012).
Friday, January 2, 2015
On Completing a PhD Proposal
In Mid-December, my PhD thesis proposal was accepted, leaving me ABD ("all but dissertation"). It was quite the journey to get there, and I have some hopefully useful insights to share from the experience.
if you've ever wondered... / toby
If you're curious, much of the information about the doctoral proposal for our School is likely widely applicable. We are supposed to finish the proposal within 6 terms of registration, but in reality that's not very common. Many students do their proposal much later in the process, after completing most of the work needed for the thesis. We tried to do my proposal a bit sooner so we could get some solid feedback earlier in the process. I'm really glad we did, but more on that later.
The Document
The first step of the proposal is to write the document. I started working on this during the summer while also developing a prototype game using my interactive storytelling framework, then part-time in the fall when I went back to teaching. However, several iterations were required, the first being on the general structure of the document. This is what we settled on in terms of chapter layout:
I put most of my effort into the second and third chapters. The background is where you have to not only show that you have a good grasp on what's out there, but also clearly show the gaps you are trying to fill. I used the Project Goals chapter to really spell out what I was trying to accomplish, and describe the storytelling framework we had published at Foundations of Digital Games.
Both of these chapters needed multiple iterations even after I fixed the overall structure of the document. We tried to bring them as close to final thesis-level quality as we could in the time we had, hoping we could reuse a lot of it again later. This is what I spent most of the fall doing.
My process for the background section is interesting to look back on: although I knew from the beginning what the text in that chapter had to accomplish, it still took me three to four iterations to get there. I fixed one problem each iteration. First, I improved the organization of the chapter so each major section had a clear organizing principle. Then I analyzed the literature more critically, then more effectively highlighted the gaps. I reorganized the sections again, and finally added better conclusions to tie up each section. The final product actually ended up being decent!
In some ways I would have liked to spend more time on the document. I noticed a few too many problems when re-reading it a few weeks after giving it to the proposal committee. For example, I cut back my introduction just before submitting, and later I realized just how... bad it was. But, to be honest, the end result — passing the proposal — would not have changed. Sometimes you have to know when to stop, even if that reason is that you simply can't spend any more time on it.
The Oral Examination
Three weeks after submitting the document to the committee, we had our proposal examination. It started with me giving a 15-20 minute talk, followed by two rounds of questions from the committee.
When preparing for the talk, I re-used a technique that helped me with a past conference presentation: I wrote a script to figure out what I wanted to say. After some feedback from my supervisor on that, , I ended up iterating on that, too. I ended up finishing my slides a little too close to the actual presentation time. I had originally hoped to run through the talk at home at least a few times (once with my husband), as well as take notes about my background section and key project information so I would be really well prepared for questions. I did none of that. Although I still passed, I think those with some more time might really benefit from trying these ideas.
These are the slides from my talk, which give a decent enough idea of how I structured it in the end. As you can see, I centred the organization around the proposed contributions of the thesis.
Because of my lack of planned practice, I ended up being pretty nervous for the talk, and it showed. Which is a shame, because I'm generally pretty good at presentations and keeping nerves in check. But I guess it turned out well anyway, since some of the committee understood what I was trying to do better after the presentation.
The question portion of the exam was... interesting. I feel like I was barely asked any questions at all. I mostly got feedback about the proposal document (lots of constructive criticism!) and suggestions for where to go from here. The committee suggested some ways to narrow the scope of our work and suggested ways to avoid having to make an entire game to test our designs. This was incredibly relieving! Nothing I've done so far has been wasted effort, and future plans now look more achievable somehow. The plan is to meet back up with the committee in six months to go over an updated plan since things are likely to change enough that we don't yet know what the final thesis will look like.
Based on this outcome, I am very glad we did an "early" proposal. I highly recommend biting the bullet and proposing your thesis as early as you can. Your supervisor should know if you've got enough to pass. Get valuable feedback early and perhaps even save yourself some work, as happened in my case.
if you've ever wondered... / toby
If you're curious, much of the information about the doctoral proposal for our School is likely widely applicable. We are supposed to finish the proposal within 6 terms of registration, but in reality that's not very common. Many students do their proposal much later in the process, after completing most of the work needed for the thesis. We tried to do my proposal a bit sooner so we could get some solid feedback earlier in the process. I'm really glad we did, but more on that later.
The Document
The first step of the proposal is to write the document. I started working on this during the summer while also developing a prototype game using my interactive storytelling framework, then part-time in the fall when I went back to teaching. However, several iterations were required, the first being on the general structure of the document. This is what we settled on in terms of chapter layout:
- Introduction
- Background
- Project Goals and Design
- Work Completed
- Future Work Plan
- Conclusion
I put most of my effort into the second and third chapters. The background is where you have to not only show that you have a good grasp on what's out there, but also clearly show the gaps you are trying to fill. I used the Project Goals chapter to really spell out what I was trying to accomplish, and describe the storytelling framework we had published at Foundations of Digital Games.
Both of these chapters needed multiple iterations even after I fixed the overall structure of the document. We tried to bring them as close to final thesis-level quality as we could in the time we had, hoping we could reuse a lot of it again later. This is what I spent most of the fall doing.
My process for the background section is interesting to look back on: although I knew from the beginning what the text in that chapter had to accomplish, it still took me three to four iterations to get there. I fixed one problem each iteration. First, I improved the organization of the chapter so each major section had a clear organizing principle. Then I analyzed the literature more critically, then more effectively highlighted the gaps. I reorganized the sections again, and finally added better conclusions to tie up each section. The final product actually ended up being decent!
In some ways I would have liked to spend more time on the document. I noticed a few too many problems when re-reading it a few weeks after giving it to the proposal committee. For example, I cut back my introduction just before submitting, and later I realized just how... bad it was. But, to be honest, the end result — passing the proposal — would not have changed. Sometimes you have to know when to stop, even if that reason is that you simply can't spend any more time on it.
The Oral Examination
Three weeks after submitting the document to the committee, we had our proposal examination. It started with me giving a 15-20 minute talk, followed by two rounds of questions from the committee.
When preparing for the talk, I re-used a technique that helped me with a past conference presentation: I wrote a script to figure out what I wanted to say. After some feedback from my supervisor on that, , I ended up iterating on that, too. I ended up finishing my slides a little too close to the actual presentation time. I had originally hoped to run through the talk at home at least a few times (once with my husband), as well as take notes about my background section and key project information so I would be really well prepared for questions. I did none of that. Although I still passed, I think those with some more time might really benefit from trying these ideas.
These are the slides from my talk, which give a decent enough idea of how I structured it in the end. As you can see, I centred the organization around the proposed contributions of the thesis.
Because of my lack of planned practice, I ended up being pretty nervous for the talk, and it showed. Which is a shame, because I'm generally pretty good at presentations and keeping nerves in check. But I guess it turned out well anyway, since some of the committee understood what I was trying to do better after the presentation.
The question portion of the exam was... interesting. I feel like I was barely asked any questions at all. I mostly got feedback about the proposal document (lots of constructive criticism!) and suggestions for where to go from here. The committee suggested some ways to narrow the scope of our work and suggested ways to avoid having to make an entire game to test our designs. This was incredibly relieving! Nothing I've done so far has been wasted effort, and future plans now look more achievable somehow. The plan is to meet back up with the committee in six months to go over an updated plan since things are likely to change enough that we don't yet know what the final thesis will look like.
Based on this outcome, I am very glad we did an "early" proposal. I highly recommend biting the bullet and proposing your thesis as early as you can. Your supervisor should know if you've got enough to pass. Get valuable feedback early and perhaps even save yourself some work, as happened in my case.