I just realized (well, ok, someone told me) that the game embedding has stopped working. I was hosting the game on my RIT home page, but since I graduated from RIT, the home page must have gotten removed. I will fix it shortly, after I find a good way of hosting a flash game distributed into multiple .swfs.
(And I'll also make a new clean final build of the game)
Monday, December 10, 2012
Monday, May 21, 2012
The almost kind of close to final game
Our capstone presentation is on Wednesday, and our game is pretty much done(except for bug fixes, minor changes, etc.) For my research hypothesis, I am once again looking for people to play the game and fill out a survey. There are actually two versions that I am comparing, so please remember what your "Test Number" is! It pops up after you start Story Mode. Oh yeah, the mode I'm testing is Story Mode.
After you play the game, please fill out this survey to let me know what you thought:
Tuesday, May 1, 2012
Theory: controlled nonsense is viral
Just a little more insight into my motivation for making a "connected mini-games game."
I think this phenomenon of viral nonsensical content is most prominent in video memes. Badger badger is one of the earlier examples of this; Narwhals is a newer, somewhat more nuanced song from the same author. In general, Weebl's Stuff is full of weird, surreal songs and videos that frequently go viral.
On YouTube, we find things like the Baman Piderman series, Don't Hug me I'm Scared, and almost anything by Don Hertzfeld (especially "Rejected").
In games, there are fewer examples, and almost all of them employ mini- or micro-games. Raving Rabbids raises a lot of unanswerable questions: Why are there crazy bunnies invading the world? And why are they obsessed with plungers?
Warrioware is a prime example of having a complete disconnect between the games and the events of the story, and both the story and the games are quite nonsensical. But I think that disconnecting the two completely takes away from the "controlled" part of "controlled nonsense," which seems important to me.
Perhaps the closest thing to what I'm trying to do in terms of nonsense/story balance is a free game called Keyboard Drumset Fucking Werewolf (gameplay video), which connects the crazy, weird mini-games into a crazy, weird story (that also matches the song the game is set to).
My theory about these "controlled nonsense" experiences is that they lure the brain into asking unanswerable questions. And since the questions have no real answer, your brain can't stop asking them, even if you do theoretically know that asking them is futile. Kind of like an earworm for the brain. The key, I think, is in the balance between the amount of nonsense to prompt questions like "but why?" and "but how?" and the feeling of underlying connectedness that keeps the player from dismissing the entire thing as, well, nonsense.
My goal is to make a game that keeps the player wondering not only "what the hell just happened?" but also "what caused this to happen?" and "what would happen if I did something different?" by providing many underlying systematic connections in a world that's on the surface divided into separate experiences. Hopefully, this will encourage them to keep re-playing the sequences in different ways to try to get a better feel for the systems that connect the mini-games.
I think this phenomenon of viral nonsensical content is most prominent in video memes. Badger badger is one of the earlier examples of this; Narwhals is a newer, somewhat more nuanced song from the same author. In general, Weebl's Stuff is full of weird, surreal songs and videos that frequently go viral.
On YouTube, we find things like the Baman Piderman series, Don't Hug me I'm Scared, and almost anything by Don Hertzfeld (especially "Rejected").
In games, there are fewer examples, and almost all of them employ mini- or micro-games. Raving Rabbids raises a lot of unanswerable questions: Why are there crazy bunnies invading the world? And why are they obsessed with plungers?
Warrioware is a prime example of having a complete disconnect between the games and the events of the story, and both the story and the games are quite nonsensical. But I think that disconnecting the two completely takes away from the "controlled" part of "controlled nonsense," which seems important to me.
Perhaps the closest thing to what I'm trying to do in terms of nonsense/story balance is a free game called Keyboard Drumset Fucking Werewolf (gameplay video), which connects the crazy, weird mini-games into a crazy, weird story (that also matches the song the game is set to).
My theory about these "controlled nonsense" experiences is that they lure the brain into asking unanswerable questions. And since the questions have no real answer, your brain can't stop asking them, even if you do theoretically know that asking them is futile. Kind of like an earworm for the brain. The key, I think, is in the balance between the amount of nonsense to prompt questions like "but why?" and "but how?" and the feeling of underlying connectedness that keeps the player from dismissing the entire thing as, well, nonsense.
My goal is to make a game that keeps the player wondering not only "what the hell just happened?" but also "what caused this to happen?" and "what would happen if I did something different?" by providing many underlying systematic connections in a world that's on the surface divided into separate experiences. Hopefully, this will encourage them to keep re-playing the sequences in different ways to try to get a better feel for the systems that connect the mini-games.
Story! - the long-overdue part 3 of the prototype analysis
A long time ago, I started a series of posts to analyze and record the things I learned from a playtest of the prototype of my game. However, I never finished the third post, which was meant to analyze the story of the game, and more importantly how the story was told and how people perceived it. This is that post.
I want Micro Missions to be able to tell stories in a very abstract, symbolic way, without using too many words or specific details about the story. This both helps the "controlled chaos" feeling of the game and makes generating dynamic stories much more feasible. But can I make stories abstract yet still basically understandable? Judging by the playtest, the answer seems to be: Yes, if I'm careful, and reinforce the right points of the stories in the right ways.
The last question on the playtest survey asked the respondents to "Describe what the game is about(story-wise)." I left this question intentionally vague to see not only how much people understood about the story, but how much they cared about it and wanted to write about it. The answers ranged from 3-word sentences starting with "idk" and mentioning a few prominent features like stick figures or chases to long, comical narratives which extrapolated the simple story into a true RPG epic. Most people, though, seemed to be content with understanding the gist of the story - chasing, defeating, finding treasure. This is exactly the kind of spread that I had hoped for, so I'm pretty happy with it.
I'm also extremely happy that more than one person was inspired to write down extrapolated stories. This shows not only that people's minds are working to actively fill in the details I left out, but also that people are having fun with the story aspect of the game.
Throughout playtesting different versions of the game, the most common points of confusion about the story surrounded the role of the mini-games themselves: why am I currently doing this thing? what did I just accomplish. So, the most important thing in terms of the story is to make sure the mini-games are book-ended by context: for most mini-games, there needs to be a cutscene that describes what's about to happen before the game, and another cutscene at the end that describes the outcome. The more these cutscenes are connected to the mini-game, the better.
For example, after defeating the bandit, the player is presented with a cutscene of a letter which gives clues as to the location of the leader. This confused some people, probably because not everyone is used to the somewhat typical RPG sequence of "defeat bad guy" -> "gain information(by looting his body for clues/letters)." Instead of implying that the letter was found on the bandit, it would have probably been better to show the bandit "dead" (or knocked out) explicitly before showing the letter.
When looking through the survey answers, I was pleasantly surprised by the number of people who identified the guy you fight as a "bandit." Pretty soon I realized that this was not because I was so great at drawing stick-figure bandits, but rather because I identified him as a bandit in the letter cutscene. Before this discovery, my goal for storytelling in Micro Missions was to use as few words as possible, to make the game more abstract and symbolic. But now I realize that words are very powerful symbols themselves, and being able to cause the player to associated a graphical symbol with a word is extremely useful for forming connections to the player's previous experiences. So now my goal is to use words in conjunction with visual symbols, and instead I'm going to try to avoid full sentences longer than 2-3 words.
I want Micro Missions to be able to tell stories in a very abstract, symbolic way, without using too many words or specific details about the story. This both helps the "controlled chaos" feeling of the game and makes generating dynamic stories much more feasible. But can I make stories abstract yet still basically understandable? Judging by the playtest, the answer seems to be: Yes, if I'm careful, and reinforce the right points of the stories in the right ways.
The last question on the playtest survey asked the respondents to "Describe what the game is about(story-wise)." I left this question intentionally vague to see not only how much people understood about the story, but how much they cared about it and wanted to write about it. The answers ranged from 3-word sentences starting with "idk" and mentioning a few prominent features like stick figures or chases to long, comical narratives which extrapolated the simple story into a true RPG epic. Most people, though, seemed to be content with understanding the gist of the story - chasing, defeating, finding treasure. This is exactly the kind of spread that I had hoped for, so I'm pretty happy with it.
I'm also extremely happy that more than one person was inspired to write down extrapolated stories. This shows not only that people's minds are working to actively fill in the details I left out, but also that people are having fun with the story aspect of the game.
Throughout playtesting different versions of the game, the most common points of confusion about the story surrounded the role of the mini-games themselves: why am I currently doing this thing? what did I just accomplish. So, the most important thing in terms of the story is to make sure the mini-games are book-ended by context: for most mini-games, there needs to be a cutscene that describes what's about to happen before the game, and another cutscene at the end that describes the outcome. The more these cutscenes are connected to the mini-game, the better.
For example, after defeating the bandit, the player is presented with a cutscene of a letter which gives clues as to the location of the leader. This confused some people, probably because not everyone is used to the somewhat typical RPG sequence of "defeat bad guy" -> "gain information(by looting his body for clues/letters)." Instead of implying that the letter was found on the bandit, it would have probably been better to show the bandit "dead" (or knocked out) explicitly before showing the letter.
When looking through the survey answers, I was pleasantly surprised by the number of people who identified the guy you fight as a "bandit." Pretty soon I realized that this was not because I was so great at drawing stick-figure bandits, but rather because I identified him as a bandit in the letter cutscene. Before this discovery, my goal for storytelling in Micro Missions was to use as few words as possible, to make the game more abstract and symbolic. But now I realize that words are very powerful symbols themselves, and being able to cause the player to associated a graphical symbol with a word is extremely useful for forming connections to the player's previous experiences. So now my goal is to use words in conjunction with visual symbols, and instead I'm going to try to avoid full sentences longer than 2-3 words.
Tuesday, April 10, 2012
Mini-game Jam mini-postmortem
A few weeks ago, we held a small Game Jam to encourage people to make mini-games for our project and test out the mini-games API that Geoff has developed for Micro Missions. The jam was quite successful: 10 people made 20 mini-games, and we tested the API pretty thoroughly along the way (and fixed a few bugs). A few other people who didn't have time for the whole jam stopped by and kept us company. It would have been even better if even more people could make it, but I really enjoyed the friendly, relaxed atmosphere that the small group of people working together for the whole weekend provided. We exchanged ideas freely, gave each other feedback on our works in progress, and had a lot of fun.
I plan on putting together a mini-game browser to show off all the mini-games we made, but for now, some details on how the organization of the game jam went.
I started talking to individual students who I thought might be interested last quarter, trying to get a feel for when they would be available, and what kinds of things they would like to see at the jam. I also wanted people to start planning for the jam early so that it wouldn't be a surprise to them when it happened. As soon as Spring Quarter started, I put up a note on the whiteboard in the main lab advertising the jam, which included an informal poll about which weekend would be best for it. Unfortunately, that note got erased almost right away despite my written request to not erase it. I was very surprised by that turn of events, since normally everyone just leaves notices like that alone unless they really need the space, and there was plenty of space on all the whiteboards, it being the beginning of the quarter.
A few days later, I settled on week 2 (since week 3 turned out to be taken for another game jam), and posted a facebook event on the RIT Game Design and Development facebook page. I chose not to mass-invite everyone to it though, mainly because I find it really annoying when people do that to me. I eventually invited all of my personal facebook friends who were also RIT GDD students. By the time of the Jam, there were 9-10 people on the "confirmed" list and 7 on the "maybe" list, although two of the confirmed people dropped out at the last moment because they had too much other work to worry about.
By the beginning of week 2 (so a week from the jam date) I had settled all the important details about the Jam, and made fliers, which I posted all around the main lab, and on the doors of a few other GDD labs.
Throughout this time, I also kept talking to individual students in person, making sure they could make it, and getting their opinion on what is needed to have a good game jam. Free food was one of the top suggestions, and some people also suggested awarding prizes at the end of the weekend. I took both of those suggestions, and I also decided that for the free food, we would avoid pizza if possible, since pizza is the go-to "free food for students" and I felt that I was getting sick of it. We did end up ordering pizza for one of the meals, because the people present at the time felt like pizza, but we also had sandwiches, cookies, and even Boston Market ("home-made dinner" style food) on Friday. I think the jammers appreciated the variety; at least I know I did!
One of my biggest concerns before the game jam was whether I could get a critical mass of people to attend and make mini-games. I think I succeeded in doing so, despite the two major factors that made it difficult to get more people to come: how soon I got all the information out there for people to make plans (I nailed everything down with about a week to go, which was too late for some people), and how busy everyone was already even this early into the quarter. Quite a few people wanted to help but couldn't, because they had too much work to do.
I plan on putting together a mini-game browser to show off all the mini-games we made, but for now, some details on how the organization of the game jam went.
I started talking to individual students who I thought might be interested last quarter, trying to get a feel for when they would be available, and what kinds of things they would like to see at the jam. I also wanted people to start planning for the jam early so that it wouldn't be a surprise to them when it happened. As soon as Spring Quarter started, I put up a note on the whiteboard in the main lab advertising the jam, which included an informal poll about which weekend would be best for it. Unfortunately, that note got erased almost right away despite my written request to not erase it. I was very surprised by that turn of events, since normally everyone just leaves notices like that alone unless they really need the space, and there was plenty of space on all the whiteboards, it being the beginning of the quarter.
A few days later, I settled on week 2 (since week 3 turned out to be taken for another game jam), and posted a facebook event on the RIT Game Design and Development facebook page. I chose not to mass-invite everyone to it though, mainly because I find it really annoying when people do that to me. I eventually invited all of my personal facebook friends who were also RIT GDD students. By the time of the Jam, there were 9-10 people on the "confirmed" list and 7 on the "maybe" list, although two of the confirmed people dropped out at the last moment because they had too much other work to worry about.
By the beginning of week 2 (so a week from the jam date) I had settled all the important details about the Jam, and made fliers, which I posted all around the main lab, and on the doors of a few other GDD labs.
Throughout this time, I also kept talking to individual students in person, making sure they could make it, and getting their opinion on what is needed to have a good game jam. Free food was one of the top suggestions, and some people also suggested awarding prizes at the end of the weekend. I took both of those suggestions, and I also decided that for the free food, we would avoid pizza if possible, since pizza is the go-to "free food for students" and I felt that I was getting sick of it. We did end up ordering pizza for one of the meals, because the people present at the time felt like pizza, but we also had sandwiches, cookies, and even Boston Market ("home-made dinner" style food) on Friday. I think the jammers appreciated the variety; at least I know I did!
One of my biggest concerns before the game jam was whether I could get a critical mass of people to attend and make mini-games. I think I succeeded in doing so, despite the two major factors that made it difficult to get more people to come: how soon I got all the information out there for people to make plans (I nailed everything down with about a week to go, which was too late for some people), and how busy everyone was already even this early into the quarter. Quite a few people wanted to help but couldn't, because they had too much work to do.
Tuesday, March 20, 2012
Slapfights, foot cars, and confusion - an analysis of the long-form survey answers
In the first installment of the analysis mini-series of the results of the playable prototype survey, I looked at the multiple-choice answers and tried to draw conclusions about what the players did, and whether that was what I wanted them to do. In part two, I will examine the written answers to the questions about what the players liked, disliked, and were confused about.
Good news:
None of the respondents seemed completely and utterly confused by the game and what is going on in it; In fact, a few of them said they weren't confused at all! This is actually a big deal: before I made a few minor modifications to this same prototype, people had a lot of trouble understanding what's going on and what they are supposed to do next. I think the most important modification I made was changing the duration of each cutscene and instruction frame from 1 second to 2 seconds. This allows people to take in everything that's being thrown at them and it still maintains a frantic, chaotic pace (which is one of my goals for the game). I also added more cutscenes, instructions, and clarifications before and after mini-games, which seems to have helped a lot, but there is still room for improvement on that front (more on that later)
More good news:
A lot of people liked a lot of the things I was hoping they would like! The crowd favorite was the slapfighting, with 7 people mentioning it as a favorite. The footprint-following mini-game was a close second, with 5 votes. This is really cool to me, because these two games are quite different: a really simple but funny game with really straightforward outcomes, and a game that offers strange new gameplay and outcomes that may or may not be desirable based on the context of the game (e.g. are you trying to chase someone or trail them?). And yet they both worked really well in this setting!
People also enjoyed the pac-man and searching for exit mini-games, the persistent items as exemplified by the sword you could find and use, and the whole "story progression and overworld made out of discrete minigames" deal.
The not so good:
There was a lot less agreement and a lot more variety in what people people found confusing or not enjoyable. One of the common sources of confusion seems to be the goal of the game, where one is supposed to go, and what is going on in general. This is partially by design - this is, after all, supposed to be a hectic, "controlled chaos"-style game with a fairly abstract storyline. But I feel like the game does still need more cutscenes, instructions, and cues in place so that it remains fun. I think that we need to have cutscenes at the beginning and end of each mini-game to create a frame of reference about what you just did and how it affected the world and story. We also need more clear instructions for each game, and more moment-to-moment feedback, like progress bars in mini-games and a "next goal" indicator on the overworld map.
The other big thing people were confused about or displeased with was the foot-car mini-game. It has two major problems, both of which I was already aware of, but did not have the time to fix. The first problem is that unlike all the other mini-games, there is not instruction screen before the foot-car game that prepares you and tells you what you're supposed to do. Instead, at the last moment, I put an animation of alternating right and left keys right into the game. (The way that I've hacked together the sequence of events in the demo prevented me from easily putting in a proper instruction screen)This actually helped a lot (before that, players had no clue at all what they were supposed to do there!), but there's still no consistency or time for players to get ready and find the right keys. For the final game, we'll make sure to add instructions to the mini-games themselves so that all of the games will have their own instructions before the game starts.
The second problem with that game is that there are no consequences to the game whatsoever. There is nothing the game accomplishes, and you move to the map location you were traveling to regardless of whether you actually get to the finish line. One of the players called it an "interactive loading screen", and that's pretty accurate. My plan for how travel is supposed to work is a little more elaborate than just making people press left and right for five seconds, though: if the player does not get to the finish line in time, he will have to make camp for the day in the middle of the road. This means playing another mini-game. The "camp" mini-games would include things like sword-sharpening, reading books, and inventory tetris. Playing these games should give the player some kind of bonus, so even though he took more time to get to his destination, he got something else out of it. I'd also like to add other events to the traveling mini-games itself, like being waylaid by enemies or finding random items in your path.
Surprisingly, only two people caught on to (or at least cared about) the fact that every time you fight a slime in the dungeon, you get placed in a new random dungeon afterwards instead of going back to the spot you were before. This was another hack to speed up the development of the prototype, since I didn't want to implement the functionality to pause an existing mini-game (the maze) and start a new one on top of it (the fight), so I just got rid of the old maze completely whenever you had to do something new like fight a slime. Sorry! We are putting that functionality in the "real" architecture.
So overall, I'm pretty happy with the feedback I got from the game. I feel like the proof-of-concept stage was pretty successful, and people are understanding and enjoying this weird "mini-game story" format. I got some valuable feedback about what works, what doesn't, and the kinds of things I need to be careful about to keep the game from getting too confusing.
In the next post, I will look at the story aspect of the prototype. How well this format works for storytelling, how people interpreted the story, and what kinds of things help or hinder the player's understanding of the narrative.
Good news:
None of the respondents seemed completely and utterly confused by the game and what is going on in it; In fact, a few of them said they weren't confused at all! This is actually a big deal: before I made a few minor modifications to this same prototype, people had a lot of trouble understanding what's going on and what they are supposed to do next. I think the most important modification I made was changing the duration of each cutscene and instruction frame from 1 second to 2 seconds. This allows people to take in everything that's being thrown at them and it still maintains a frantic, chaotic pace (which is one of my goals for the game). I also added more cutscenes, instructions, and clarifications before and after mini-games, which seems to have helped a lot, but there is still room for improvement on that front (more on that later)
More good news:
A lot of people liked a lot of the things I was hoping they would like! The crowd favorite was the slapfighting, with 7 people mentioning it as a favorite. The footprint-following mini-game was a close second, with 5 votes. This is really cool to me, because these two games are quite different: a really simple but funny game with really straightforward outcomes, and a game that offers strange new gameplay and outcomes that may or may not be desirable based on the context of the game (e.g. are you trying to chase someone or trail them?). And yet they both worked really well in this setting!
People also enjoyed the pac-man and searching for exit mini-games, the persistent items as exemplified by the sword you could find and use, and the whole "story progression and overworld made out of discrete minigames" deal.
The not so good:
There was a lot less agreement and a lot more variety in what people people found confusing or not enjoyable. One of the common sources of confusion seems to be the goal of the game, where one is supposed to go, and what is going on in general. This is partially by design - this is, after all, supposed to be a hectic, "controlled chaos"-style game with a fairly abstract storyline. But I feel like the game does still need more cutscenes, instructions, and cues in place so that it remains fun. I think that we need to have cutscenes at the beginning and end of each mini-game to create a frame of reference about what you just did and how it affected the world and story. We also need more clear instructions for each game, and more moment-to-moment feedback, like progress bars in mini-games and a "next goal" indicator on the overworld map.
The other big thing people were confused about or displeased with was the foot-car mini-game. It has two major problems, both of which I was already aware of, but did not have the time to fix. The first problem is that unlike all the other mini-games, there is not instruction screen before the foot-car game that prepares you and tells you what you're supposed to do. Instead, at the last moment, I put an animation of alternating right and left keys right into the game. (The way that I've hacked together the sequence of events in the demo prevented me from easily putting in a proper instruction screen)This actually helped a lot (before that, players had no clue at all what they were supposed to do there!), but there's still no consistency or time for players to get ready and find the right keys. For the final game, we'll make sure to add instructions to the mini-games themselves so that all of the games will have their own instructions before the game starts.
The second problem with that game is that there are no consequences to the game whatsoever. There is nothing the game accomplishes, and you move to the map location you were traveling to regardless of whether you actually get to the finish line. One of the players called it an "interactive loading screen", and that's pretty accurate. My plan for how travel is supposed to work is a little more elaborate than just making people press left and right for five seconds, though: if the player does not get to the finish line in time, he will have to make camp for the day in the middle of the road. This means playing another mini-game. The "camp" mini-games would include things like sword-sharpening, reading books, and inventory tetris. Playing these games should give the player some kind of bonus, so even though he took more time to get to his destination, he got something else out of it. I'd also like to add other events to the traveling mini-games itself, like being waylaid by enemies or finding random items in your path.
Surprisingly, only two people caught on to (or at least cared about) the fact that every time you fight a slime in the dungeon, you get placed in a new random dungeon afterwards instead of going back to the spot you were before. This was another hack to speed up the development of the prototype, since I didn't want to implement the functionality to pause an existing mini-game (the maze) and start a new one on top of it (the fight), so I just got rid of the old maze completely whenever you had to do something new like fight a slime. Sorry! We are putting that functionality in the "real" architecture.
So overall, I'm pretty happy with the feedback I got from the game. I feel like the proof-of-concept stage was pretty successful, and people are understanding and enjoying this weird "mini-game story" format. I got some valuable feedback about what works, what doesn't, and the kinds of things I need to be careful about to keep the game from getting too confusing.
In the next post, I will look at the story aspect of the prototype. How well this format works for storytelling, how people interpreted the story, and what kinds of things help or hinder the player's understanding of the narrative.
Friday, March 16, 2012
Research Hypothesis
As part of the capstone process, each graduate student (which for this project is just me!) has to have a research topic that is associated with the game. I've already talked a little bit about my general topic: dynamically generated stories using the Micro Missions architecture. Now, I think, the time has come to define more clearly my research hypothesis - what am I attempting to prove or disprove with my research?
So, without further ado, my research hypothesis is:
With a base architecture of modular, independent mini-games connected into cause-and-effect chains through discrete output, we can generate engaging and understandable semi-abstract stories using a "just-in-time" story generator which will choose and populate the next piece of content on-demand based on current story context and a basic model of narrative structure.
And here is what it means in the context of Micro Missions:
Most video game stories rely on the story designer anticipating and authoring every choice a player can make with respect to the story, and the consequences of these choices. With this method, the quality of the interactive aspect of the story depends in large part on whether the author anticipated a particular player's desired story-related choices. This method also places a great burden on the story designers, since they must author and test all the possible combination of player actions and story consequences.
The Micro Missions architecture allows a designer to create stories out of mini-games by connecting these mini-games through their inputs and outputs. Mini-games can take in a variety of variables that define the current context and environment; gameplay is adjusted using these variables, and after a mini-game ends, a series of values is output. Each of these values is in a discrete, pre-defined range. For each possible output value of each output, the designer of the story specifies what the next Interaction (mini-game, cutscene, or special event) should be.
The prototype developed at the end of Winter quarter served as a proof-of-concept to demonstrate that the described architecture can be used to hand-author stories that are understandable and fun to play through. The research question is whether we can build a story generator on top of that architecture that would generate stories which are comparably understandable and at least as engaging as the hand-created stories.
So, without further ado, my research hypothesis is:
With a base architecture of modular, independent mini-games connected into cause-and-effect chains through discrete output, we can generate engaging and understandable semi-abstract stories using a "just-in-time" story generator which will choose and populate the next piece of content on-demand based on current story context and a basic model of narrative structure.
And here is what it means in the context of Micro Missions:
Most video game stories rely on the story designer anticipating and authoring every choice a player can make with respect to the story, and the consequences of these choices. With this method, the quality of the interactive aspect of the story depends in large part on whether the author anticipated a particular player's desired story-related choices. This method also places a great burden on the story designers, since they must author and test all the possible combination of player actions and story consequences.
The Micro Missions architecture allows a designer to create stories out of mini-games by connecting these mini-games through their inputs and outputs. Mini-games can take in a variety of variables that define the current context and environment; gameplay is adjusted using these variables, and after a mini-game ends, a series of values is output. Each of these values is in a discrete, pre-defined range. For each possible output value of each output, the designer of the story specifies what the next Interaction (mini-game, cutscene, or special event) should be.
The prototype developed at the end of Winter quarter served as a proof-of-concept to demonstrate that the described architecture can be used to hand-author stories that are understandable and fun to play through. The research question is whether we can build a story generator on top of that architecture that would generate stories which are comparably understandable and at least as engaging as the hand-created stories.
Subscribe to:
Posts (Atom)