Two questions

[Ry]

I re-read Bidding for Challenges and saw that you can challenge votes... so I updated the UniversalisBiddingForChallenges.png above.

I keep telling myself I'll pause and wait for some feedback on whether I'm doing this right, but then tinkering more.  Ah well.

[Ry]

I've got Introducing Components done, although again, I'm in uncharted territory here, I may have missed something but I tried to avoid that possibility by farming off new subpages.

http://ogcesix.pbwiki.com/f/UniversalisIntroducingComponents.PNG

[Ry]

During a Scene doesn't fit on a page for obvious reasons, so I split it in two:

http://ogcesix.pbwiki.com/f/UniversalisDuringAScene1.PNG
http://ogcesix.pbwiki.com/f/UniversalisDuringAScene2.PNG

I think there's only 3 more sections to do: Creating Components, Changing Components, and Complications (which may be another 2-pager).

I'll post the .doc files when those are done; basically I'd like to have a stable version of the .doc file before others change it around so there aren't five or six versions that float around.

Any comments right now about whether I'm doing this right would probably save me a lot of work later.

[Valamir]

Hey Ryan, sorry I haven't got back to these sooner.

Some Comments:

On Challenges you have the "does anyone object..." diamond.  The "yes" choice from there should probably lead to another choice box "Does the Player who made the proposal revise it?".  "Yes" from there can lead back to the "All players discuss" box.  This cycle is "Negotiation".  A "No" from there should lead to a "Is the objecting player willing to spend a Coin to back up their Challenge" choice.  A "No" from there should go to "The Proposal is Accepted" (there is no impasse) while a "yes" from there leads to "K".  Mechanically it gets you to the same place, but I think this way makes the spirit of the rule a little more clear.

In the bidding section the first box about selecting a number of Coins to bid is technically correct, although I've never seen anyone lead off with more than a single Coin.  Its funny how this section takes way fewer words to just write out than it does to diagram.

The Introducing Components flow looks correct but you may have tied it too specifically to scene framing.  Any player can do all of the things listed here on their turn not just the scene framer.  The scene framer just has an uninterruptable first crack at it.  So you may want to revise the first couple of boxes (maybe move them back to the previous flow) so that this flow is generic and can be used for all instances of Introducing Components (which technically can also be done during the Tenet phase).

The During a Scene Flow looks pretty complete in that I can't think of anything obvious that's missing.  Only comment here is that I don't follow the logic of having the "Exit a Scene" option feed into the "Event" cycle.  Seems a better fit to flow into the "other details / Facts" cycle.


Interestingly I'm in the middle of a project at work where, having designed a 20 page work procedure we've enlisted one of our business analysts to help find some efficiencies.  The first thing she did was flow chart it all out.  I must say I'm very pleased that the business procedure I designed is no where near as convoluted as the game I designed :-)

Its also interesting the way people's minds work.  I find following the train of a well written narrative far easier to grasp than following a flow chart.  Flow charts for some make complex concepts simpler to follow.  For me they make things look far more complicated than they really are.  Similarly in our recent Robots & Rapiers playtests Seth has taken my well written narrative (ahem...that is to say...desperately in need of a good editing narrative) and boiled it down to little "Conflict Diagrams" which, while not strictly a true flowchart, do make the question of "who is doing what to whom" pretty easy to follow.  I never would have even thought of drawing diagrams like that...my brain just doesn't work that way.  But now I can see they're essential support to the text.

I fear these diagrams may be a bit too ambitious in capturing every detail and nuance...soon they'll turn into a book by themselves;  but I'm certainly intrigued by the process.  It may be more practical to scale back a bit and see if you can't diagram the whole game at a higher level on just 4 pages.  A tenet flow, a during play flow, a page with some of the more important subroutines (like challenges), and a complications flow.  That may (I stress may here) be more useable at the table as a reference.

But I'm loving this, so please continue in whatever fashion adds the most value for you.

Ralph

[Ry]

A quick question:

Is the Scene Framer the only one who can end a scene? 
Is their end of the scene subject to challenge?

[Ry]

My wife pointed out that by putting the stuff about Recording into the Challenges section rather than the other sections, I can take a lot out.  I'm going to see how that looks.

[Valamir]

A quick question:

Is the Scene Framer the only one who can end a scene? 
Is their end of the scene subject to challenge?

Yes.
and Yes...both ways.  They can also be Challenged to force an end to the scene.

[Valamir]

My wife pointed out that by putting the stuff about Recording into the Challenges section rather than the other sections, I can take a lot out.  I'm going to see how that looks.

If you mean the "record the Event" / "record the Fact" boxes, I wouldn't recommend that.  It would probably be technically correct (as in not break the flow chart) but since the vast majority of facts and the like get recorded as they're spoken without any additional discussion, burying the "record" boxes as the end of the "may discuss" subroutine would give the wrong impression of play, I think.

[Ry]

What if the name of the F algorithm was "Discussion, Challenges, Fines, and Recording Results"  ?

It's a long name, but the fact you are "Recording Results" doesn't get buried that way.

[Valamir]

Try it and see how you like it.

I tend to think subroutines as working best when they capture things that don't happen every pass through the chart...like Challenges and Complications.  You don't do those every turn so setting them aside is effective.  Recording stuff, on the other hand, happens continuously.  So they seem best suited to being the main end points of the main flow.  But as I said, I don't really think in terms of flow charts so I may well be off here.

Ralph

[Ry]

Looking deeper, it actually makes more sense (I mean flowchart wise) for the "recording" notes to be in the Challenge section because what gets recorded isn't necessarily the same thing - or even the same kind of thing - as the Proposal.  So I'm going to rename that F subroutine "Discussion and Recording Results"

Re: your anectdote, funny enough I'm a business analyst at work, and I spend between 4 and 10 hours each workday on process design.  When I was thinking "Man, Universalis would be really hard to turn into a process document" I also thought "Hey, I should get more comfortable with those flowchart drawing objects in Word."