Recent Posts

Pages: 1 ... 8 9 [10]
I've played some XCOM recently, and I was excited to see that its capacity for emergent, gameplay-driven storytelling was not lost on its creators:

With XCOM: Enemy Unknown, the development team saw the game as a platform for players to create their own stories -- they wanted to encourage an internal narrative to unfold each time they play.

Games like The Elder Scrolls series also support emergent narratives; DeAngelis remembers a moment in his experience of The Elder Scrolls III: Morrowind that affected him so profoundly he wrote about it in grad school: Short on cash, he was looting a regal armoire when he realized he wasn't alone in the room. He had to make quick work of the resident, but managed not to alert any guards.

"As I took his items, I discovered that he was a well-known aristocrat in the town," he describes. "I changed costumes and slowly made my way to the overworld, praying I could escape before anyone noticed. I was a dozen yards from the exit, when a guard made a beeline for me, sword still sheathed. He confronted me and whispered 'I've got my eye on you'... then he walked away."

Guards used random lines on players all the time in Morrowind. "In fact, they probably said that particular line to me before for no particular reason other than to sound dutiful, but because of the mini-narrative I was weaving in my head, that line of dialogue, at that exact moment, had an enormous impact on my experience," DeAngelis recalls.

Games naturally lend themselves to certain stories - stories of adventure, overcoming overwhelming odds, escaping by the skin of your teeth. My question is two-fold:

  • Can we - should we - get this kind of narrative in text-driven games? It rarely appears in most gamebooks and text adventures, because the story is so defined by the author's text.
  • How can we build a game that tells a story that's not traditional to a game?
General Discussion / Re: Hypothetical : New gamebook platform requirements
« Last post by Chris on October 25, 2013, 04:36:26 PM »
I should mention that we've had to do this to build DestinyQuest using some Twine components. I'm not sure I've mentioned that in this forum though!
General Discussion / Re: Hypothetical : New gamebook platform requirements
« Last post by Villain Mastermind on October 24, 2013, 08:56:50 AM »
That is essentially the plan...  :P

Build the final product (Digital Gamebook) first and then basic tools (an IDE) to produce said product. While I'm going to build the game-book components first, the planning is being done with the IDE and the development-process in mind.

There was some things I wanted to do that couldn't be easily accomplished in Twine/Twee without extensive modifications, so I started thinking about what would be needed to get what I needed done for these projects with the minimum amount of fuss. There are hundred different ways to go about it and many excellent sources of inspiration which I've been drawing from, but the challenge is making the structure as simple as possible without being "dumbed down". A clean interface, easy to understand code/markup, and an intuitive application structure is the goal.

Twine/Twee shows that a simple tool can inspire people to express themselves creatively that otherwise would be too intimidated to even try... Even if I fail horribly, maybe another brave soul will build upon the spiritual foundation of Twine and my ideas to create something even better.

What I am trying to glean from the community is their requirements for an MVP (Minimum Viable Product). That being said, I have no problem with wish-list features. Getting them sooner rather later is a boon because you can add design/api hooks for their inclusion at earlier stages in the process.
General Discussion / Re: Hypothetical : New gamebook platform requirements
« Last post by Chris on October 23, 2013, 12:21:26 PM »
Speaking from experience, the best way to come up with an architecture for a gamebook platform is to use that architecture to build a gamebook.  ;)
General Discussion / Re: Hypothetical : New gamebook platform requirements
« Last post by Villain Mastermind on October 22, 2013, 03:39:56 PM »
Here is an extremely brief overview of my favorite permutation of the web-components idea:

PixelBook - The root element of the application
  • Displays the designated "Page" element
  • Acts as the primary controller, handling the specifics of basic functions like "Page Turning" and most other logic
  • Stores various elements invisibly in storage-divs walled off from the user by hiding them in element's "Shadow DOM" (e.g. Page, ?VarData?, Pix, and Passage/Snippet elements not residing in a Page element)
  • Contains and manages a "Log" component that can be displayed for debugging purposes
Log - A normally hidden element that is activated when the application is running in debug-mode so it can store various "LogEntry" elements

LogEntry - Text messages that record debuging data like events, state changes, and error messages

Page - Primary display container for templated application content

Passage - A semantic extension of the "p" element (?additional funtionality?)... Can either exist directly in a Page element or be stored invisibly in the root element for dynamic insertion
Snippet - Serves a function analogous to the Passage element, but extends the "span" method instead for containing short chunks of inline text... Can also exist directly in a Page or be stored for dynamic insertion
I have about a dozen different ideas about how to implement variables... Still batting around the best way to do it. Suggestions and brainstorming is appreciated

Pix - An extension of the "img" element with addional functionality?
Tbox - A special extension to the "div" element for additional layout options along with extra functionality like a type-writer effect... Would be useful for "Visual Novel" applications or ones that need that old-school feel.  (Might make that also available on passages)
I dunno... Still playing around with different schemes.
Suggestions and/or Ideas, anyone?

* A Note on the state of the available polyfills *
X-Tags appears to be a partial implementation at best
Polymer requires a web-server, so a purely client-side web-app (which is exactly what I want at this stage) is impossible to build with it
General Discussion / Re: Hypothetical : New gamebook platform requirements
« Last post by Villain Mastermind on October 21, 2013, 09:15:37 PM »
After dreaming up several dozen different ideas and plans, I've settled on one that does exactly what I want in a way that isn't a tangled mess. Actually, it is so simple that I'm almost ashamed and humbled that it didn't occur to me sooner.

Web components! The only way to achieve what I want without a horrendous mess of divs and javascript hacks.

But there is a catch...

The technology is quite literally experimental, which makes prototyping a giant pain in the ass. The latest versions of Chrome Canary have the needed features after tweaking the application flags, but it still acts a bit oddly. There are polyfills and shims, but they are ugly as hell, but I may have to suck it up and use them even to get a proof-of-concept prototype up and running.

Oh, well... *sigh*

I originally started coding it in TypeScript, but the web component angle was such a delicious alternative that I dropped it on the spot.
General Discussion / Re: Hypothetical : New gamebook platform requirements
« Last post by Villain Mastermind on October 12, 2013, 07:57:26 AM »
I'm in the initial design stages, more or less.
My dayjob being a corporate slave and minor related life-events have been delaying progress, not to mention time spent researching and throwing out overly-complicated designs. The simpler the system, the easier it will be to learn, use, mantain, and modify to the user's needs.
Gonna use the "Chaos Model" for this particular project... I found it in one of my research missions and instantly fell in love with the idea.
I'll post more as my life permits.
Noticeably, interactive text doesn't have many of these problems. One good quote:

And emotion is carried fairly effectively through movement, too, which is why Bioware Face - the name I have for two characters standing stock still, facing each other, maintaining eye contact and making occasional gestures that are completely unrelated to what they're saying - seems so wooden and jarring.
General Discussion / Re: Hypothetical : New gamebook platform requirements
« Last post by Chris on September 30, 2013, 03:04:12 PM »
Well it's a good idea to define some stakeholders here:

  • Writers (probably want something easy to write with, with easy ways to manage standard gamebook logic/inventory/choices, as well as publishing options)
  • Programmers (probably want something extensible and easy to modify)
  • Readers (probably want something that looks good)

Are you building something?
General Discussion / Re: Hypothetical : New gamebook platform requirements
« Last post by Villain Mastermind on September 28, 2013, 09:10:34 AM »
Off to a good start... A little confusion as to which set of project stakeholders I wanted to gather requirements from, but I was going to ask for Dev-centric requirements next anyway.

No matter... Maybe I should have just asked for requirements for the Devs in the first place. Alls well that ends well...

Currently, I am researching software/API's similar to what I have in mind to take a survey of how they tackled various problems.
Pages: 1 ... 8 9 [10]