Update on life as a PDF publisher . . .

[philreed]

What style sheets are you working with? Do you use MS Word to create the PDF files?

Writing is in Word, layout is in Quark.

[xenopulse]

Ah, thanks.

I wish I could ofer my services as an editor, seeing that I proof, edit and format documents on a daily basis, but I doubt that I have the D20 experience, market overview or probably even available time to do the job.

In any case, I appreciate the insight into the business.

[Brendan]

Out of curiosity, Phil, what kind of workload (weekly hours-wise) would such an editor be taking on?

[philreed]

Out of curiosity, Phil, what kind of workload (weekly hours-wise) would such an editor be taking on?

No idea. Before the carpall tunnel hit me I was working about 60 hours/week. The few people that have contacted me haven't even discussed time.

Likely the best way this would work is a series of editors -- all with specialities. The goal would be to have a wide variety of products AND avoid overlap.

[Solly Brown]

Thanks for sharing your experience with us Phil, your success gives all us indie publishers hope.

I can see that part of your success is offering small, relevant and inexpensive supplements for the huge d20 market.  

May I ask you how you would market a large non d20 crime book.

Dog Town: Core Rules is a 289 page gritty grand theft autoesque crime game retailing in rpgnow at $20 that has it's own Split System Game mechanic.

Have you got any tips?

I can send you a complimentary copy if that would be of help.

Thank you

Jonathan Ridd
Cold Blooded Games

[Paul Czege]

Hey Phil,

I recommend¹ the following:

First do (or hire someone to do) a data analysis of what you're publishing. I bet a skilled data analyst would identify fewer than eight "entry types" across all of your content (e.g. magic item, character class, monster, etc.), and each with a fairly simple content structure (i.e. set of data elements).

Create a tagging structure for each data type.

Collect content from your writers as tagged ASCII files. Formatting (boldface, italics, etc.) is also tagged.

Parse content using an off-the-shelf parsing application configured to recognize the tag structures of your data types. Fix tagging errors prior to Quark.

Develop Quark styles that recognize your ASCII tagging schemes and apply formatting as appropriate.[/list:u]Upside:
No more messing with Word styles. The parsing application reports errors, which are fixed by your writers prior to Quark. Quark then applies all styles based on the coded data...and those codes will have been validated.[/list:u]The Big Upside:
You move toward database publishing. By properly creating the tagging schemes for your content types, you collect more data (actually not content, but data about your content) than you actually typeset. And then you use that data to package and repackage your content. So, you publish "100 Cursed Wands." And you publish "22 Tropical Beasts." And for everything you're collecting "locale" information. So, later, you publish "The Duchy of Fear," which includes some of your tropical beasts and a couple of cursed wands, as well as descriptive information on various cities within the Duchy. And as you continue publishing, you continue growing your database of content, and spitting out variant slices of content. Next year you do "The Armor of Overlords," which includes stuff you had created as original material for "The Duchy of Fear."

By collecting and storing the content as ASCII files (a style-impartial format), you're able to implement crazy and diverse formats for the individual products. Your customers love getting just the slice of content they want. The effort you put into creating all these different slices is minimized. so you're positioned for spending more of your own time making them all look artistically distinctive. And you create sales across products.[/list:u]Paul

¹ Skeptical? I have fifteen years experience in database publishing, as a project manager, consultant to project managers, and creator of workflows.

[philreed]

Hey Phil,

I recommend¹

¹ Skeptical? I have fifteen years experience in database publishing, as a project manager, consultant to project managers, and creator of workflows.

Wow. Skeptical? That was so far over my head I'm not even sure what you're saying. It's impossible for me to be skeptical. Let me try to see if I get it.

You're saying that I could just keep writing the feats, spells, classes, monsters, etc. and load them in a giant database. The database then "creates" products based on information I enter -- such as "give me 12 magic swords with evil makers." Is that correct?

(Am I letting on how dumb I am by not understanding this idea? I think I understand it but I'm so fuzzy I don't know if I'm inventing ideas in my head or understanding the described process.)

[philreed]

May I ask you how you would market a large non d20 crime book.

Dog Town: Core Rules is a 289 page gritty grand theft autoesque crime game retailing in rpgnow at $20 that has it's own Split System Game mechanic.

That feels way too big to sell as a PDF. I think my first question would be:

"Can it be broken into smaller products?"

[Paul Czege]

Hey Phil,

Well...I'm not so sure I'd go so far as to recommend that you create an actual physical database. I think the real win for you would be from having a consistent tagging structure for your data, and for that tagging structure to be informed by a vision for ways you might want to use the data again in the future. So, if you're doing "The Duchy of Fear," you still include locale information, because you may want to use some of the magic items in a book that isn't specifically about the Duchy. And maybe you have the writer do a one-sentence "blurb" for every NPC, monster, and weapon as well. "Octavius the Blind, who gave up his own eyes so a terminally ill goblin child might have a few days of sight before he died." That way, when you start work on "101 Paladins," you have blurb text for the back cover and whatnot. The real trick will be your implementation of Quark styles. It should be the style you apply to a chunk of content that determines what elements are part of the layout and what elements are not. So, creating a list of back cover blurbs is applying a style that ignores all of the content but the blurb, and creating the page with a magic item on it within "Duchy of Fear" is applying a style that ignores the blurb and the locale.

You don't need to store everything in a database for this. You can always query against text files to find the content you're looking for (locale equals "Duchy of Fear). Sure, you could store everything in a database and output yourself one giant file of content, but I can't see that offering a seriously significant speed advantage. When you do your layout you're still going to have to apply styles to individual chunks of content if their structures are different; just manually pulling in the file (monster, NPC, city description, whatever) as you're working with the styles doesn't seem like it would be so much slower. The big wins for you would be knowing that your styles were going to work with your data (because the data has been used before and/or has been parsed to validate the tagging structure) and starting to think like a database publisher in how you create your content.

Paul

[Tav_Behemoth]

Paul, you've just taken a vague idea I've had, of "industrializing" the process of putting together a "crunch"-heavy d20 product (by having a database of, frex, stats for characters and monsters across a wide range of levels that can be developed once and then used to spit out specific stat-blocks ad infinitum) and taken it to the next two levels.

Like Phil, I'm going to have to spend some time processing what you just laid down, but I'm very excited about the concept. Add in an open license component - that multiple publishers could draw from the same database, since it's all open content - and you've got a roaring juggernaut of synergy.