|
Post by thegrapesoda on Sept 8, 2014 1:35:40 GMT
Has anybody given any thought to standardizing our route formatting/scene writing/etc? I ask because at some point we're going to have to turn our stuff over to the programmers, and I feel like if we don't have some sort of standardization going then one of two things is going to happen:
1) The programmers are going to get a bunch of .docx files containing routes, scenes, and the like in a variety of different formats, leading to frustration/delays while they acclimate to everyone's documentation style 2) We're going to be forced to standardize everything as a last step before handing off to the programmers, which might lead to a headache for us for the same reasons (as well as things being missed in translation from individual style --> standard --> programmers)
I feel like if we have some sort of standard document structure that we all adhere to, it'll only serve to help us down the line - both during the overarching editing/QC process, as well as in the transition from writers --> programmers.
I've been going through some Ren'Py documentation to see what would translate easiest from writing --> programming, and I've used a few different Word/Open Office templates before for scriptwriting, so I have a few ideas on how to tackle this. However, I'd like to hear everyone else's ideas/comments/etc as well.
EDIT: Also, if anyone has any ideas as far as a central file repository goes, please jump in!
|
|
|
Post by torgamous on Sept 8, 2014 3:25:02 GMT
Twine apparently plays nicely with Ren'py, and is much friendlier to branching stories than a word processor.
|
|
|
Post by igfod13 on Sept 8, 2014 5:53:41 GMT
One of the programmers should start a GitHub repo. Also, I made a dropbox folder if people want to use that for file storage/sharing.
In terms of writing, put everything in quotation marks for Ren'py. For example: "Do this for narrative text."
For characters speaking, put the character's name or abbreviation first, then put text in quotes, like this: sh "Notice me, senpai!"
Here's a list of abbreviations to use for now. Scuba-kun: sk (or sc?) Shark-chan: sh Class rep: c Hama: h Rinko: r Mako: m Nami: n
Also, we need a standardized list of specific emotions for each character. I remember someone linked one of those emotion tables before, but it would be nice to have a standard one. To change the emotion of the sprite, use: show *Insert character abbreviation* *Insert emotion* Example: show sh happy
|
|
|
Post by thegrapesoda on Sept 8, 2014 12:34:07 GMT
One of the programmers should start a GitHub repo. Also, I made a dropbox folder if people want to use that for file storage/sharing. In terms of writing, put everything in quotation marks for Ren'py. For example: "Do this for narrative text." For characters speaking, put the character's name or abbreviation first, then put text in quotes, like this: sh "Notice me, senpai!" Here's a list of abbreviations to use for now. Scuba-kun: sk (or sc?) Shark-chan: sh Class rep: c Hama: h Rinko: r Mako: m Nami: n Also, we need a standardized list of specific emotions for each character. I remember someone linked one of those emotion tables before, but it would be nice to have a standard one. To change the emotion of the sprite, use: show *Insert character abbreviation* *Insert emotion* Example: show sh happy Awesome. Is there a lead programmer who can be pinged to create the GitHub project? What's the link to the dropbox (maybe put a sticky in the Super Secret Spoilers section)? How should decision trees and conversation choices be formatted/tagged? For the list of emotions, I feel like there would be three states that all sharks have: - Basic State: What the shark normally looks like when talking to Scuba. For ClassRep, that might be overly confident. For Hama, that might be a little shy and withdrawn. - "Up" State: What the shark looks like when they're one tick up from the basic state. Happy/positive, or when Scuba gives them an answer they like. For ClassRep, that might be an even bigger grin. For Hama, that might be a demure smile with a bit of blush. - "Down" State: What the shark looks like when they're one tick down from the basic state. Angry/sad, or when Scuba gives them an answer they don't like. For ClassRep, that might be a furrowed brow and crossed fins. For Hama, a look of embarrassment. From there, each shark would have a few extra faces as dictated by the narrative. I feel like it might make sense to conceptualize their emotions starting from the "big three" I mention above, since those would be the faces the player would most likely encounter unless s/he gets deeper into a shark's specific route. Until Scuba really starts digging on one of them, they'd probably hold back on some of their "bigger" expressions - with exceptions, of course, based on the shark's personality and the writer's preferences. Thoughts?
|
|
|
Post by todash on Sept 10, 2014 3:26:32 GMT
One of the programmers should start a GitHub repo. Also, I made a dropbox folder if people want to use that for file storage/sharing. In terms of writing, put everything in quotation marks for Ren'py. For example: "Do this for narrative text." For characters speaking, put the character's name or abbreviation first, then put text in quotes, like this: sh "Notice me, senpai!" Here's a list of abbreviations to use for now. Scuba-kun: sk (or sc?) Shark-chan: sh Class rep: c Hama: h Rinko: r Mako: m Nami: n Also, we need a standardized list of specific emotions for each character. I remember someone linked one of those emotion tables before, but it would be nice to have a standard one. To change the emotion of the sprite, use: show *Insert character abbreviation* *Insert emotion* Example: show sh happy Awesome. Is there a lead programmer who can be pinged to create the GitHub project? What's the link to the dropbox (maybe put a sticky in the Super Secret Spoilers section)? How should decision trees and conversation choices be formatted/tagged? For the list of emotions, I feel like there would be three states that all sharks have: - Basic State: What the shark normally looks like when talking to Scuba. For ClassRep, that might be overly confident. For Hama, that might be a little shy and withdrawn. - "Up" State: What the shark looks like when they're one tick up from the basic state. Happy/positive, or when Scuba gives them an answer they like. For ClassRep, that might be an even bigger grin. For Hama, that might be a demure smile with a bit of blush. - "Down" State: What the shark looks like when they're one tick down from the basic state. Angry/sad, or when Scuba gives them an answer they don't like. For ClassRep, that might be a furrowed brow and crossed fins. For Hama, a look of embarrassment. From there, each shark would have a few extra faces as dictated by the narrative. I feel like it might make sense to conceptualize their emotions starting from the "big three" I mention above, since those would be the faces the player would likely encounter unless s/he gets deeper into a shark's specific route. Until Scuba really starts digging on one of them, they'd probably hold back on some of their "bigger" expressions - with exceptions, of course, based on the shark's personality and the writer's preferences. Thoughts? I like it. I'm going to keep using my personal format while writing on paper but once i type it up ill be sure to use the standardized format.
|
|
|
Post by thegrapesoda on Sept 15, 2014 2:26:32 GMT
Went through and figured out formatting for conversation branches. Probably would be a good idea for everyone to read the Ren'Py tutorial as well: www.renpy.org/doc/html/quickstart.htmlBelow is the example provided by the tutorial, followed by my brief explanation. To give the player a choice of responses, use the menu: command. After each potential response, use the jump command followed by the name of a label. When a player picks one of these responses, Ren'Py will jump to the label paired with that response and show the relevant dialogue. When you are done with the response/ jump pairings, write out the individual label commands and the relevant dialogue. Follow this up with another jump, which will most likely be back to a shared thread. If you've done programming before, this should be fairly straightforward. If not, I (and others) can help answer questions. As a sidenote - since we're doing a points system, each label will probably make a change to a points counter for the shark's route. But that's a specific implementation we can discuss later.
|
|
|
Post by igfod13 on Sept 15, 2014 3:07:16 GMT
We should also split the script file into multiple files to avoid having a giant block of text. A good way to organize this would probably be having it done by Chapter or whatnot(outline, anyone?).
|
|
|
Post by batsan on Sept 27, 2014 19:56:14 GMT
Has anyone made a github project yet? I'm not sure I'm "lead" programmer material but I could do it if it's still needed.
|
|