I haven't managed to get very far on my interactive story/game/whatever project. It's a combination of lack of time, procrastination (when I do have the time), and a handful of false starts.
My first instinct was to get an actual story pinned down -- something reminiscent of a text adventure/Choose Your Own Adventure type story -- and then take that story and re-interpret it in a visual/animated/game-type form. It all made sense in my head. At least it did before I started. And, in some way, I think it'd still be a decent methodology, if the end result were to basically stay in a mostly (hyper)text format. Maybe not so much, if you're in the gaming profession. Or not, I don't know. Shut up. I'm trying to think.
Initially, I'd been working with an open source program called Twine, which is designed pretty much specifically for creating interactive fiction and can be very handy if you're creating a non-linear story. Basically you can write a story in diagram form (it looks a little like Visio) and then export it (if you choose) to make an HTML version of your little adventure. I'm interested in it mainly for the diagram aspect (i.e. keeping track of where I want shit to go).
This is basically what a story written in Twine looks like (zoomed out). You can create hyperlinks in the boxes and then a line is created from one box to the other...so you can see where everything goes). If you're an interactive fiction writer, pretty much the only thing you have to do next is compile and export this bad boy into an HTML file and put it online.
Like I said, if that were the extent of this project, I'd probably be done already.
So here's the part where I've gotten a bit stuck. Every story idea that I've started on has eventually spiraled into something much, much bigger than what I want the scope of this project to be. I know I want to convey a story, but I'm not necessarily aiming for something epic. I want the actual words (if there are any that will ultimately be seen) to be kept to a minimum. Besides, the objective is supposed to address more of the game play & mechanics aspects. Right off the bat, this means that the bulk of what I would do in Twine would be (at least in my mind) superfluous.
I could also admit that I might be overthinking a bit. But I won't.
The point is that now I've moved to a different approach. It's still somewhat diagram-like in nature; however, instead of trying to fit the mechanics to the story, I'm working on mapping out how I want it to be played/experienced first and then tailoring the story to that.
This isn't anything remotely innovative or new in terms of game design. In fact, from what I've learned, it's one of the most basic (if not *the* most basic) questions in game design. What comes first: the story or the mechanics? And the majority of games choose the latter.
Not that being in the majority necessarily makes things better.
Mechanic over story is basically my daily narrative design battle. The majority of the time, narrative design isn't consulted until the system or feature has already been created. In these cases, there's little else to do, aside from writing flavor text or creating/fleshing out/retroactively inserting story. By that time, we're left with a lot less flexibility, since things are more or less set in stone at that point.
Still, I think it's interesting to experience a view from the "other side". I'm not giving up on story altogether, but a story-focused approach is not really the way that I want to go with my project. So, in that sense, I don't see it as a sacrifice...just a minor logistical setback.
Though, check back in a month...I may change my tune....
My first instinct was to get an actual story pinned down -- something reminiscent of a text adventure/Choose Your Own Adventure type story -- and then take that story and re-interpret it in a visual/animated/game-type form. It all made sense in my head. At least it did before I started. And, in some way, I think it'd still be a decent methodology, if the end result were to basically stay in a mostly (hyper)text format. Maybe not so much, if you're in the gaming profession. Or not, I don't know. Shut up. I'm trying to think.
Initially, I'd been working with an open source program called Twine, which is designed pretty much specifically for creating interactive fiction and can be very handy if you're creating a non-linear story. Basically you can write a story in diagram form (it looks a little like Visio) and then export it (if you choose) to make an HTML version of your little adventure. I'm interested in it mainly for the diagram aspect (i.e. keeping track of where I want shit to go).
This is basically what a story written in Twine looks like (zoomed out). You can create hyperlinks in the boxes and then a line is created from one box to the other...so you can see where everything goes). If you're an interactive fiction writer, pretty much the only thing you have to do next is compile and export this bad boy into an HTML file and put it online.
Like I said, if that were the extent of this project, I'd probably be done already.
So here's the part where I've gotten a bit stuck. Every story idea that I've started on has eventually spiraled into something much, much bigger than what I want the scope of this project to be. I know I want to convey a story, but I'm not necessarily aiming for something epic. I want the actual words (if there are any that will ultimately be seen) to be kept to a minimum. Besides, the objective is supposed to address more of the game play & mechanics aspects. Right off the bat, this means that the bulk of what I would do in Twine would be (at least in my mind) superfluous.
I could also admit that I might be overthinking a bit. But I won't.
The point is that now I've moved to a different approach. It's still somewhat diagram-like in nature; however, instead of trying to fit the mechanics to the story, I'm working on mapping out how I want it to be played/experienced first and then tailoring the story to that.
This isn't anything remotely innovative or new in terms of game design. In fact, from what I've learned, it's one of the most basic (if not *the* most basic) questions in game design. What comes first: the story or the mechanics? And the majority of games choose the latter.
Not that being in the majority necessarily makes things better.
Mechanic over story is basically my daily narrative design battle. The majority of the time, narrative design isn't consulted until the system or feature has already been created. In these cases, there's little else to do, aside from writing flavor text or creating/fleshing out/retroactively inserting story. By that time, we're left with a lot less flexibility, since things are more or less set in stone at that point.
Still, I think it's interesting to experience a view from the "other side". I'm not giving up on story altogether, but a story-focused approach is not really the way that I want to go with my project. So, in that sense, I don't see it as a sacrifice...just a minor logistical setback.
Though, check back in a month...I may change my tune....
Comments