Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Tips for formatting to print.

edited May 2015 in Chit-Chat
I'm starting a simple choose-your-own-adventure gamebook (no variables) and I will print it later on.
Should I use simple brackets or 2.
Do you have any other advice which would be useful for people meaning to print?

Comments

  • edited April 2015
    I would imagine something like:

    Caverns (page 2). Have the passage title in the link, but then put the page reference outside the link as normal text.

  • My gamebook, made for PDF printing, just uses numbers for the passage titles despite warnings against doing so for whatever technical reasons. I have nearly 300 passages and haven't encountered any issues. Since it's a gamebook, it uses numbered passages. Pages are irrelevant.

    So, just 1, 2, 3, and so forth.
    There is a monster ahead and a door to the right and left. 
    
    What do you do?
    
    Go left: [[12]]
    Go right: [[3]]
    Fight the monster: [[8]]
    

    It's legible when printed as the brackets aren't distracting, but also allows for an HTML version as well.
  • edited May 2015
    Sharpe wrote: »
    Go left: [[12]]
    Go right: [[3]]
    Fight the monster: [[8]]
    
    This is a classy way to do it, and thanks for your suggestion. I do love this html way of linking words within the story itself, and I was looking to see if someone has figured out a way to do it in print even more unobtrusively. Taking your story:
    Should you [[go left]], [[turn right]] or just go ahead and [[fight the damned thing]]?
    
    That's nice and tidy in html, but what about print? Can it be achieved? How can we send them to the correct page?
  • I don't know of a way to make text only appear in the proofing copy, if that's what you're asking. That's assuming you're using the "export to proofing copy" option in Twine 1.x.

    I'm moving this thread to the "Help! with 1.x" forum, if I can figure out how to do so in this new forum software. "Workshop" is mainly for completed games, or playable works in progress nearly so. XD
  • @Sharpe, I'm not really looking into any specific software option. I was just wondering if perhaps someone has suggestions on how to best make this happen in print. Even if I used a typewriter to write this adventure, what should I write to send the player/reader to the correct page?
  • So, this is just a general "choose your own adventure" question rather than a question about Twine? I suppose in that case, just the good ol' "If X, turn to page X" should work. Or, if in-line, then I agree with Claretta's suggestion to put it in parenthesis after the choice.

    When you said "gamebook," I thought you meant like Lone Wolf or Fighting Fantasy.
  • Sharpe, you have a GameBook out? Is it something I could read?
  • I got really heavy into Twine about a year ago creating two projects at once. One was a turn-based RPG with commissioned pixel art. The other was a gamebook that used SJ Games' fee GURPS Lite rules. I didn't complete either before I got burned out. As of today, however, I'm working on the gamebook again.
  • Good luck and I hope you win this time!!

    Writing is a good fight, but a lonely one.

    :)
  • Sharpe wrote: »
    I got really heavy into Twine about a year ago creating two projects at once. One was a turn-based RPG with commissioned pixel art. The other was a gamebook that used SJ Games' fee GURPS Lite rules. I didn't complete either before I got burned out. As of today, however, I'm working on the gamebook again.

    That's quite interesting Sharpe, sorry to hear you burned out. Good luck with it this time round, I'd be quite interested to see something like that, I used to play a lot of GURPS a few years ago.
  • If there isn't some software around yet to automatically generate the PDF from a Twine XML file, I would consider to write one with the goal that the author can keep all links just as they work in the HTML output, and the PDF generator system would (hopefully) internally take care to place page references as one would expect. As Sharpe pointed out, it would be a bad idea to include page numbers into Twine links while writing, because at this time it's unclear on which page the text will end up with, and it would also be quite messy, if any of the text later needs to be changed. To have abstract numbers in the links instead would be much better, but as there would be a mapping to the actual page numbers being required anyway, names should do just as well. If you haven't decided to do this task manually yet, I might attempt to build such an automated system, if time permits.
  • This is something I'm working on right now, actually... This is my project. It's a new Story Format that will feature printing at some point.

    As far as I can tell, there is a LOT that goes into turning something as complex as a Twine document into PDF that can be printed. It isn't really something that any of the existing story formats can handle, either. You've got to think about:
    • How many passages the author can put in
    • A way to denote what page each passage will start on
    • How the number of pages on each passage will affect what page the next passage starts on
    • a way to measure how much content is allowed on each page
    • When measuring, your method needs to allow for variations in font, size, text wrap, and how the story format's structured.
    • margins
    • PDF bloat (less of an issue)
    • PDF bookmarks, for easily keeping track of each passage once the PDF is generated.

    If you want Twine to handle all of it, that's really all you've got to think about when coding this whole thing.

    For now though, you could either make it yourself (if you know js, some possible PDF libraries are pdfkit and jspdf) or just use the Twine project as a framework for the project in some other app, like Word.
  • 1nKy wrote: »
    You've got to think about:
    One extra important thing to think about.

    The output of each passage shown is dynamically generated each time that passage is shown and that output can be a concatenation of any number of inputs including but not limited to: Current Passage Contents, Referenced Passage Contents, Header Contents, Footer Content, and the conversion of $variables references into their current values.
  • greyelf wrote: »
    1nKy wrote: »
    You've got to think about:
    One extra important thing to think about.

    The output of each passage shown is dynamically generated each time that passage is shown and that output can be a concatenation of any number of inputs including but not limited to: Current Passage Contents, Referenced Passage Contents, Header Contents, Footer Content, and the conversion of $variables references into their current values.
    That is a valid point with the possible exception of $variables, because sheets of paper are a static medium. You could solve for referenced passage contents with extra passages, which can get messy (For Screentastic, I'm just disallowing it.)

    Regarding your first point about it being dynamically generated content, what is displayed on the screen is irrelevant because what you see has already been through a hypertext parser that's designed for screen display. To get it all to work, the print parser would have to exist separate from the normal on-screen story parser, and would only be called when the print button is pressed. It'd have to pull from the HTML dump that is the story data, and rejigger the whole thing into a shiny new PDF on the fly. At least that's how I plan to implement it :P
  • My primitive workflow system supports LaTeX as PDF generator backend, therefore LaTeX would take care of all page references via its labelling mechanism. Other PDF generators might have a similar feature, so one wouldn't have to deal with it manually. I wouldn't support any variables or logic, but features like selecting a linear, non-branching path of textnodes or random shuffeling. Would such an workflow be useful to you guys?
  • To work with twine, it'd have to be something you could do purely in Javascript/html. Javascript plugins/extensions such as jQuery are acceptable. I did find this which uses LaTeX: http://manuels.github.io/texlive.js/
    But the displayed snippet on the homepage fails to compile, which doesn't give me a lot of confidence.
  • Is this your requirement, that it has to be in JavaScript, that it has to be integrated into the Twine GUI? Because I would use the Twine Story Archive XML file, which is quite easy to handle, as I found out for a project I'm contributing to.
  • edited October 2015
    What I'm doing is integrating printing into the story format, which for lack of a better description, is a bunch of code that takes the twine archive (which doesn't use XML so much as custom html tags) and parses it into proper html when the end user runs it in their browser. The story format is written in javascript, and uses html as it's input and output.
  • I got it working ^_^
Sign In or Register to comment.