A high level feature-set
0 views
Skip to first unread message
Dinehart
Jun 5, 2008, 3:58:06 PM6/5/08
to GW SIG Tools Initiative
Here is a laundry list of a feature sets:
* endorsed by the IGDA
* co-designed by the WSIG
* Built around a secure hosted database
* is extensible and modular (open source)
* outputs ubiquitous formats (XL, Word, pdf, txt, rtf)
* tracks writing elements and subsequent meta-data such as scene
headings, patheticals , and dialog
* Correlates visual script formats with written
* Multiple input styles and sorting functions (plain text,
spreadsheet, screenplay)
* Multiple sorting functions (character, location, localization
number, scene, etc.)
* Custom visual script creation tool set
* endorsed by the IGDA
* co-designed by the WSIG
* Built around a secure hosted database
* is extensible and modular (open source)
* outputs ubiquitous formats (XL, Word, pdf, txt, rtf)
* tracks writing elements and subsequent meta-data such as scene
headings, patheticals , and dialog
* Correlates visual script formats with written
* Multiple input styles and sorting functions (plain text,
spreadsheet, screenplay)
* Multiple sorting functions (character, location, localization
number, scene, etc.)
* Custom visual script creation tool set
Ron Toland
Jun 5, 2008, 4:15:09 PM6/5/08
to GW SIG Tools Initiative
Could you go into a little more detail here? I understand the first
two, but why do you need our tools to be built around a secure hosted
database? Are you assuming users will never need to work off-line?
When you say "track writing elements," why do you need that (what does
it help you do)? Does "correlates visual..with written" mean WYSIWYG
editing, or something else? What do you mean by "sorting functions,"
and how does having multiple ones help you with your work? And what
would a "custom visual script creation tool set" be for?
Note I'm not knocking your list, I'm just trying to understand it
better. And for me, knowing what your goals are helps me understand
why you want the things you do :)
Ron
two, but why do you need our tools to be built around a secure hosted
database? Are you assuming users will never need to work off-line?
When you say "track writing elements," why do you need that (what does
it help you do)? Does "correlates visual..with written" mean WYSIWYG
editing, or something else? What do you mean by "sorting functions,"
and how does having multiple ones help you with your work? And what
would a "custom visual script creation tool set" be for?
Note I'm not knocking your list, I'm just trying to understand it
better. And for me, knowing what your goals are helps me understand
why you want the things you do :)
Ron
Dinehart
Jun 5, 2008, 4:30:10 PM6/5/08
to GW SIG Tools Initiative
Thanks for pressing me! That's more of a next step, I'd rather see
other peoples laundry list...
I was brainstorming...
My feature set is driven from the motivation to build more than a
writing tool. What we need is a tool that works along side game
development pipelines and has enough functionality to be integrated
into them, and utilized throughout production. That said, I'm
expanding the list to explanations, look for them shortly. :)
other peoples laundry list...
I was brainstorming...
My feature set is driven from the motivation to build more than a
writing tool. What we need is a tool that works along side game
development pipelines and has enough functionality to be integrated
into them, and utilized throughout production. That said, I'm
expanding the list to explanations, look for them shortly. :)
Message has been deleted
Message has been deleted
Dinehart
Jun 5, 2008, 5:36:16 PM6/5/08
to GW SIG Tools Initiative
Laundry list expanded, refined, and defined:
Feature #1
Title: "Narrative Database” driven
Description:
This feature allows the data to be tracked, version controlled, and
stored in one central location.
Solves for what problem?
Story related data is stored in multiple places and is modified by
various users, both on and off site; if this data is not tracked and
version controlled by central database human error becomes a handicap
and ultimately becomes a resource drain and quality reducer.
Feature #2
Title: Customizable Data Sorting Functions
Description:
This feature allows the custom sorting of data and associated meta-
data including but not limited to (dialog, localization numbers, scene
headings, characters, etc.)
Solves for what problem?
This allows the tool to be used by multiple user types on the
development team. Different users need to address different pieces of
data depending on their role in the narrative pipeline. audio
designers, play designers, localization experts, writers, programmers,
etc. all need to view the data in custom ways.
Feature #3
Title: Customizable input styles
De
scription:
This feature allows the user customize data entry for their own needs.
Solves for what problem?
Again, this allows the tool to be used by multiple user types on the
development team. Different users need to enter different pieces of
data depending on their role in the narrative pipeline. audio
designers, play desi
gners, localization experts, writers, programmers, etc. all need to
view the data in custom ways.
Feature #4
Title: Extensible and modular
Description:
This feature allows the tool to act as a platform for game writing by
enabling developers to create custom solutions for their individual
production needs. These “widgets” could be shared via a forum, and
Creative Commons licensing. This Encourages adoption, and allows
writers to use one toolset across the industry depending on the
demands of a particular production.
Solves for what problem?
Engines tend to require unique custom solutions. In addition game
development can be iterative and dynamic in such ways that tools need
modification mid-production at times.
Feature #5
Title: Dynamic ubiquitous script output
Description:
This feature allows users to define output types, file locations, and
script "build" intervals based upon their needs. The data is updated
and tracked by the database to maintain continuity in all output
formats.
Solves for what problem?
Creating multiple output types allows various types of users and
sytems to get the story data in custom formants. However, when
creating multiple output files for a production the correlation of the
local files data with master data sources can become a resource drain,
and is prone to reduce quality.
Feature #6
Title: Visually and verbal tool set
Description:
This feature gives the user visual script and storyboard development
tools, which correlate directly to written story data. By having
written and visual tools, the user(s) can create visually and
verbally. In the end both visual and written scripts can be output and
delivered to a team.
Solves for what problem?
Direct correlation of art direction, game direction and story
direction can prove difficult for a lead. This can lead to any number
of problems. This tool
Feature #7
Title:Correlates visual script formats with written
Description:
This feature allows a the a correlation of visual scripts like
storyboards and color scripts with the written data as needed by a
user for production and reference.
Solves for what problem?
Again, this allows the tool to be used by multiple user types on the
development team. Different users need to enter different pieces of
data depending on their role in the narrative pipeline. audio
designers, play designers, localization experts, writers, programmers,
etc. all need to view the data in custom ways.
:)
Feature #1
Title: "Narrative Database” driven
Description:
This feature allows the data to be tracked, version controlled, and
stored in one central location.
Solves for what problem?
Story related data is stored in multiple places and is modified by
various users, both on and off site; if this data is not tracked and
version controlled by central database human error becomes a handicap
and ultimately becomes a resource drain and quality reducer.
Feature #2
Title: Customizable Data Sorting Functions
Description:
This feature allows the custom sorting of data and associated meta-
data including but not limited to (dialog, localization numbers, scene
headings, characters, etc.)
Solves for what problem?
This allows the tool to be used by multiple user types on the
development team. Different users need to address different pieces of
data depending on their role in the narrative pipeline. audio
designers, play designers, localization experts, writers, programmers,
etc. all need to view the data in custom ways.
Feature #3
Title: Customizable input styles
De
scription:
This feature allows the user customize data entry for their own needs.
Solves for what problem?
Again, this allows the tool to be used by multiple user types on the
development team. Different users need to enter different pieces of
data depending on their role in the narrative pipeline. audio
designers, play desi
gners, localization experts, writers, programmers, etc. all need to
view the data in custom ways.
Feature #4
Title: Extensible and modular
Description:
This feature allows the tool to act as a platform for game writing by
enabling developers to create custom solutions for their individual
production needs. These “widgets” could be shared via a forum, and
Creative Commons licensing. This Encourages adoption, and allows
writers to use one toolset across the industry depending on the
demands of a particular production.
Solves for what problem?
Engines tend to require unique custom solutions. In addition game
development can be iterative and dynamic in such ways that tools need
modification mid-production at times.
Feature #5
Title: Dynamic ubiquitous script output
Description:
This feature allows users to define output types, file locations, and
script "build" intervals based upon their needs. The data is updated
and tracked by the database to maintain continuity in all output
formats.
Solves for what problem?
Creating multiple output types allows various types of users and
sytems to get the story data in custom formants. However, when
creating multiple output files for a production the correlation of the
local files data with master data sources can become a resource drain,
and is prone to reduce quality.
Feature #6
Title: Visually and verbal tool set
Description:
This feature gives the user visual script and storyboard development
tools, which correlate directly to written story data. By having
written and visual tools, the user(s) can create visually and
verbally. In the end both visual and written scripts can be output and
delivered to a team.
Solves for what problem?
Direct correlation of art direction, game direction and story
direction can prove difficult for a lead. This can lead to any number
of problems. This tool
Feature #7
Title:Correlates visual script formats with written
Description:
This feature allows a the a correlation of visual scripts like
storyboards and color scripts with the written data as needed by a
user for production and reference.
Solves for what problem?
Again, this allows the tool to be used by multiple user types on the
development team. Different users need to enter different pieces of
data depending on their role in the narrative pipeline. audio
designers, play designers, localization experts, writers, programmers,
etc. all need to view the data in custom ways.
:)
Coray Seifert
Jun 5, 2008, 5:40:52 PM6/5/08
to gw-sig-tool...@googlegroups.com
Ok, my checklist is shorter, but honestly, if I found a program that could do these things, I'd be sold!
Cheers,
- C
- This single biggest item: Exports easily (~5 clicks) to excel for localization/production.
- Assigns line IDs automatically on entry, or has a functon for the user to add line IDs (or to combine multiple lines into one line ID).
- Exports to WGA formatted script.
Cheers,
- C
Title:Correlates visual script formats with written
Description:
This feature allows a the a correlation of visual scripts like
storyboards and color scripts with the written data as needed by a
user for production and reference.
Solves for what problem?
Again, this allows the tool to be used by multiple user types on the
development team. Different users need to enter different pieces of
data depending on their role in the narrative pipeline. audio
designers, play designers, localization experts, writers, programmers,
etc. all need to view the data in custom ways.
:)
On Jun 5, 12:58 pm, Dinehart <s...@flownaway.com> wrote:
Roane Beard
Jun 6, 2008, 12:15:30 AM6/6/08
to gw-sig-tool...@googlegroups.com
Perhaps this is stating the obvious, but I'd add that the tool should support branching dialog, a la the NWN toolset.
--
___________
Roane Beard
Staff Writer
Meteor Games
___________
Roane Beard
Staff Writer
Meteor Games
Ron Toland
Jun 6, 2008, 10:48:51 AM6/6/08
to GW SIG Tools Initiative
Thanks for this expanded list, Stephen! I think I understand what
you're looking for better now.
On Jun 5, 4:36 pm, Dinehart <s...@flownaway.com> wrote:
> Laundry list expanded, refined, and defined:
>
> Feature #1
> Title: "Narrative Database” driven
>
It sounds like what you're really concerned about here is version
control (something everyone needs to worry about). Since that's more
a function of what version control software the team's using
(subversion, perforce, etc.), then the writing tool itself, this
should be easy to take care of. Perforce can handle pretty much any
format; though to get the most out of the "diff" function we'd need to
be sure the native save format of our tool is text-based.
> Feature #2
> Title: Customizable Data Sorting Functions
>
>
"views" function in SQL: different ways of looking at the same data.
Should we perhaps do a survey among programmers, producers, and
artists to find out what the most useful "views" of our game writing
would be for them? Also, should the multiple views be something that
we "must have" for the software, or is nailing a proper view for us
writers the first priority (and we can add the others later)?
>
> Feature #4
> Title: Extensible and modular
>
Yes! Would the open-source nature of the tool take care of this, or
are you thinking of being able to build macros using a scripting
language?
>
> Feature #5
> Title: Dynamic ubiquitous script output
>
> Description:
> This feature allows users to define output types, file locations, and
> script "build" intervals based upon their needs. The data is updated
> and tracked by the database to maintain continuity in all output
> formats.
>
Ok. This sounds like what you're looking for is a multiple-export
function, yes?
>
> Feature #6
> Title: Visually and verbal tool set
>
> Description:
> This feature gives the user visual script and storyboard development
> tools, which correlate directly to written story data. By having
> written and visual tools, the user(s) can create visually and
> verbally. In the end both visual and written scripts can be output and
> delivered to a team.
>
Still a little fuzzy on this one. Are you talking about a snazzy
outlining tool here?
>
> Feature #7
> Title:Correlates visual script formats with written
>
This sounds like another "enter data once, view multiple ways"
feature. Right?
...Should I go ahead and add another section to the wiki for "feature
requests"? Or just keep discussing things here until after we've done
the survey?
Ron
you're looking for better now.
On Jun 5, 4:36 pm, Dinehart <s...@flownaway.com> wrote:
> Laundry list expanded, refined, and defined:
>
> Feature #1
> Title: "Narrative Database” driven
>
control (something everyone needs to worry about). Since that's more
a function of what version control software the team's using
(subversion, perforce, etc.), then the writing tool itself, this
should be easy to take care of. Perforce can handle pretty much any
format; though to get the most out of the "diff" function we'd need to
be sure the native save format of our tool is text-based.
> Feature #2
> Title: Customizable Data Sorting Functions
>
>
> Feature #3
> Title: Customizable input styles
Forgive the analogy, but I think of these two features like the
> Title: Customizable input styles
"views" function in SQL: different ways of looking at the same data.
Should we perhaps do a survey among programmers, producers, and
artists to find out what the most useful "views" of our game writing
would be for them? Also, should the multiple views be something that
we "must have" for the software, or is nailing a proper view for us
writers the first priority (and we can add the others later)?
>
> Feature #4
> Title: Extensible and modular
>
are you thinking of being able to build macros using a scripting
language?
>
> Feature #5
> Title: Dynamic ubiquitous script output
>
> Description:
> This feature allows users to define output types, file locations, and
> script "build" intervals based upon their needs. The data is updated
> and tracked by the database to maintain continuity in all output
> formats.
>
function, yes?
>
> Feature #6
> Title: Visually and verbal tool set
>
> Description:
> This feature gives the user visual script and storyboard development
> tools, which correlate directly to written story data. By having
> written and visual tools, the user(s) can create visually and
> verbally. In the end both visual and written scripts can be output and
> delivered to a team.
>
outlining tool here?
>
> Feature #7
> Title:Correlates visual script formats with written
>
feature. Right?
...Should I go ahead and add another section to the wiki for "feature
requests"? Or just keep discussing things here until after we've done
the survey?
Ron
Stephen E. Dinehart
Jun 6, 2008, 3:06:02 PM6/6/08
to gw-sig-tool...@googlegroups.com
Cool, I hope there aren't to long
winded for you! lol
Let me know if you have any questions or comments.
Ron Toland wrote:
Let me know if you have any questions or comments.
Ron Toland wrote:
Ron Toland
Jun 7, 2008, 9:43:32 AM6/7/08
to gw-sig-tool...@googlegroups.com
Not long winded at all! I do have a few additional questions, though:
Feature #1: It sounds like what you're really concerned about here is
version control (something everyone needs to worry about). Since that's
more a function of what version control software the team's using
(subversion, perforce, etc.), then the writing tool itself, this should
be easy to take care of. Perforce can handle pretty much any format;
though to get the most out of the "diff" function we'd need to be sure
the native save format of our tool is text-based.
Features #2 and #3: Forgive the analogy, but I think of these two
features like the "views" function in SQL: different ways of looking at
the same data. Should we perhaps do a survey among programmers,
producers, and artists to find out what the most useful "views" of our
game writing would be for them? Also, should the multiple views be
something that we "must have" for the software, or is nailing a proper
view for us writers the first priority (and we can add the others later)?
Feature #4: I wholeheartedly agree with this one, and it's something
other people have asked for as well. Would the open-source nature of
the tool take care of this, or are you thinking of being able to build
macros using a scripting language?
Feature #5: Sounds like what you're looking for is a multiple-export
function, yes?
Feature #6: Still a little fuzzy on this one. Are you talking about a
snazzy outlining function here?
Feature #7: This sounds like another "enter data once, view multiple
ways" feature. Right?
Ron
Reply all
Reply to author
Forward
0 new messages