Non-Print Formats

[Christopher Weeks]

Why is PDF king?

Why don't people sell HTML games instead?  (I know, I know...people do, but why not more?)  Printability is the only thing that's coming to mind, but writing print-ready HTML isn't rocket science.

What other electronic formats are people using?

If these have been discussed a thousand times before, pointers to those threads would be much appreciated.

Chris

[Ron Edwards]

Hey,

Here are some possibly-pertinent older threads:
Best format for web-published games (wow! This was the fourth thread at the Forge - talk about oldies)
Next project: interactive format (a bit off-topic, but a very interesting idea)
eproducts: what eproduct would you provide for your rpg? (highly recommended, directly related to your topic)
Publishing a CHM file for distribution (also closely related, I think)

There are tons and tons of threads about CD-ROM formats, too, but I figured that wasn't quite what you were aiming at.

Best,
Ron

[Christopher Weeks]

Thanks Ron, good stuff.  I'd only previously read the last of the four.

Throughout those threads, it seems to be assumed that an HTML presentation would still be a download.  Why does it have to be?  What if one were to sell an account that gave access to webspace devoted to a game?  

It would always be up to date.  The consumer could automatically get new content as it was posted to a single location.  The consumer could copy or print the files as they chose, or just keep using it online.  (I know, with a net connection -- they are ubiquitous in my world, but not everyone's...yet.)

And there would be room for lots of cool apps that integrated the game's players.  Like the (theoretical) Sorcerer and Demon character DBs.  Like potential for metaplot handling (if/when a game calls for such).  Like suppliment sharing.  Like catalogs of links and graphics and one sheets and...I'm not sure what all else.

This is straying from the topic just a little, but the thing that I'm currently fancying is a game that is published in very small articles (a paragraph or five) that the consumers/users/readers can cast up- and down-votes for which act to change the order of presentation of the articles.  It would be very easy for it to get dumbly chaotic, but figuring out a handling system for making it work would be an exciting interactive presentation option that would only be possible online.

I'm unclear on how much of this kind of thing has been tried.

Chris

[Jonathan Walton]

Throughout those threads, it seems to be assumed that an HTML presentation would still be a download.  Why does it have to be?  What if one were to sell an account that gave access to webspace devoted to a game?

Permanence and reliability.  What's the guarantee that the files I need will stay up for ever, or be accessible every time I want to use them?  Downloading something onto your own machine gives you a more solid sense of ownership and security.  It will always be there when youn need it, assuming something horrible doesn't happen to your own machine.

[Keith Senkowski]

Hi,

his is straying from the topic just a little, but the thing that I'm currently fancying is a game that is published in very small articles (a paragraph or five) that the consumers/users/readers can cast up- and down-votes for which act to change the order of presentation of the articles. It would be very easy for it to get dumbly chaotic, but figuring out a handling system for making it work would be an exciting interactive presentation option that would only be possible online.

I think one of the reasons you don't see a format like that with a built in e-commerce application is that it is expensive to develop.  I think that reason that PDF is the most used format is the applications they are developed in.  When you layout a game you lay it out in an application like Quark or InDesign (or for non-designers Word, etc) which easily generate PDFs.  Also, speaking from experience as one of my many hats are both Graphic Designer and Web Developer, it is a lot easier for me to layout in a print application opposed to the web.  Web deployment (meaning any form of delivery through a browser) sufferes from too many variables, while PDFs offer none besides the version your customer has.

Keith

[quozl]

Web deployment (meaning any form of delivery through a browser) sufferes from too many variables, while PDFs offer none besides the version your customer has.

Keith

What variables are you talking about?

[ethan_greer]

Regarding the inconvenience of an HTML download, I'm just not seeing it.  People talk about how there're files all over the place and what not, but it doesn't really have to be that way - all you really need is a master directory which contains a single HTML file and another directory.  The HTML file should have a name like, "ThisIsTheGame.html" or some such to indicate to the user that that's what he or she should be clicking on. All images, sub-pages, and the like can stay in the sub folder and still be referenced by the main html file. No fuss, no muss, and it would allow for the flexibility of editing, shuffling content, etc. that some users would appreciate.

So, in response to Chris: In my opinion, for online viewing, you could follow the "members only" site design pioneered by the online porn industry, and also include a link to a download that would be the same files and format, arranged as described in the previous paragraph. I think this would be a perfectly viable approach to e-publishing. And it would be easy to implement - just design the whole site as described above. Then, when you update the site, re-zip it and replace the old download file (or better yet, apply version numbers, maintain a "what's new" file, and have version history). For an example of this idea in action (sort of), check out the Web Design Group, a great HTML/CSS reference site. I say "sort of" because while they offer a download of their html pages, it's not particularly well-organized for the ease of the end-user.

There are several advantages of HTML over PDF.  For starters, PDF requires special software (unless you're using a Mac), and you still have to have something else like a word processor or something to generate the content.  In contrast, any schlep with microfuck notefuck* can create HTML/CSS files. And if you're worried about your content showing up properly on different browsers, write Lynx-friendly pages. Second, I don't care what anyone says; if you ask me, an HTML file, well-designed and properly implemented, will always be better to read on screen than a PDF file. We're talking no space wasted on margins and page breaks, no horizontal scrolling for small print multicolumn layouts, and smaller file sizes and load times. Third, HTML is easier to set up with cross references, hyperlinks, table of contents, index, glossary, etc. than PDF.

The only drawback to HTML is the fact that you can't control your layout with an iron fist; you can provide layout guidelines in HTML, but ultimately, layout will depend on the client's browser. But isn't it the content itself that's the most important thing? In my opinion, layout can slide as long as the info gets to the user in a recognizable format.

Yikes. This is turning into a rant, isn't it?  If I felt that strongly about it, one might wonder why I'm planning on publishing my own stuff in PDF. My response is, PDF is the format of choice in digital gaming products, and it's a pretty good format, too.  When it comes down to it, I'm far, far from interested in being any kind of pioneer in digital publishing. But I'm a firm believer in HTML as an effective and useful means if disseminating information, online or off.

So Chris, if you want to release HTML products, you'll get a resounding "Go for it!" from me.

* "Microfuck notefuck" is the second-funniest thing that Vincent Baker has written (that I've read).

[Michael S. Miller]

I'm unclear on how much of this kind of thing has been tried.

TORG tried an interactive gameworld before the internet was ubiquitous. How the individual playgroups fared against the bad guys was supposed to dictate the "metaplot" of the supplements, and the course of the Possibility Wars themselves. It didn't go too well, but, they were trying to organize this through a print newletter, not online. Christopher Kubasik was involved with TORG. I'm not sure if he has any insights on this.

[Keith Senkowski]

Hi,

Fonts are a big variable, particularly if you are using a non-standard font or made up your own for the design.  Also there is less control to the layout in web development than there is in print.  It is very limiting and does not allow you to control things like white space.

If you are using something like Flash there is also always the issue of plug-ins.  This is an issue with PDFs, but the numbers (of people with it) are very good for Acrobat and it comes free on most new machines (and Mac users don't even need it).

Basically, web based deployment limits your control over the user experience.  However, I'm not saying that a pay-per-view type of web site isn't a neat idea and I would love to take the time to design one, but that is the key.  It would cost a lot more to design a proper site with e-commerce capabilities than it would for me to lay out for a PDF.

Keith

[Christopher Weeks]

The TORG metaplot is exactly what I was thinking with that quote.  I was in a TORG playtest group in '90-91 (and still have some of my beta suppliments) and did a miniscule amount of (credited and paid!) writing for them.  I liked the TORG metaplot idea, but like you point out, it would be much easier to run a much more interactive campaign of that sort with the rise of the internet to ubiquity.  

If anyone is intimately familiar with it and the Living... games that I see at cons these days and other similar projects with which I'm unfamiliar, I'd be keen to hear about how the internet is (or should be) used.

Chris

[Christopher Weeks]

Fonts are a big variable, particularly if you are using a non-standard font or made up your own for the design.  Also there is less control to the layout in web development than there is in print.  It is very limiting and does not allow you to control things like white space.
...
Basically, web based deployment limits your control over the user experience.

So, if you want special fonts, that's a problem.  But I happen to think that the typefaces available on pretty much everyone's clients would suffice.  And if I wanted some scripty section headers or drop-caps or something I could jpeg them.

As for less control, that's true and it's not.  Can you make a PDF that will actively assess your reader's screen and conform to presentation rules?  (I don't know the answer, but I suspect not.)  And what control of white space do you have with PDF/Acrobat that I don't with HTML/CSS?

It seems to me that PDF limits your control over user experience, but has the single advantage of much more universal print stability.

Chris

[Keith Senkowski]

Actually with PDF you can do a lot.  It takes some work, but you can control various parts of the user experience.  The problem is it takes time and some skill.  I'm in the process of developing some PDFs to be deployed via CD-ROM for my day job and control over the user experience is real important.  There are a couple of things I have run across in my research, such as control over the size of the page when the PDF is opened and the easy navigation between areas that can be built in, that it suprises me that more people haven't used them.

Keith

[quozl]

Actually with PDF you can do a lot.  It takes some work, but you can control various parts of the user experience.  The problem is it takes time and some skill.  I'm in the process of developing some PDFs to be deployed via CD-ROM for my day job and control over the user experience is real important.  There are a couple of things I have run across in my research, such as control over the size of the page when the PDF is opened and the easy navigation between areas that can be built in, that it suprises me that more people haven't used them.

Keith

It's because PDFs are for printing.  If you want to make an on-screen "user experience", it's much easier to use HTML.