Subject: MN: Sun Arise

From: "Dunx (Duncan Ellis)" <DELLIS@U...>
Date: 18 Jan 99 12:29:16 +0000

Players: 

These are some of my thoughts following on from dave's suggestion about 
reorganising the ruleset. I apologise in advance for the lecturing tone and 
the length, but I'm just trying to get a handle on things. 

First of all, we need to identify why we might want to reorganise the
ruleset. 

The oft-stated goal of this game is to produce a set of rules for MC, and to 
achieve that goal satisfactorily the ruleset should be readable straight 
through, in a similar way to the rules for a standard game (board game, 
roleplaying game, whatever). 

What is it that makes such rulesets readable? Several things, I think [MN 
comments are bracketed thus]: 

a) progressiveness - the basic concepts are always explained first 

[I reckon this is one of the most fundamental conflicts between the 
'readable ruleset' goal and the way a Nomic is played, since Rules 
tend to get added to a Nomic ruleset in time order. 

[The use of sections in the MN ruleset ameliorates this effect 
somewhat. Also, an effort has been made to address this further with 
the out-of-sequence rule ordering in some sections, but if anything 
that just makes things *more* confusing. 

[No renumbering Proposal has ever, to my knowledge, been
implemented.] 

b) grouping - similar concepts are clumped together 

[we already have something like this within MN with the sectional 
format, but could this be improved? Made more flexible, perhaps?] 

c) language - most games aim to use the simplest appropriate language in 
order to explain concepts clearly and unambiguously. 

[the language in MN can be a bit high-flown, not to mention 
inconsistent in style (which is largely inevitable in any multi- 
authored document). I know I'm as guilty of prolixity as anyone, but 
there are reasons behind it - trying to cover all the angles is one, 
and attempting to offer hooks for extension is another.] 

d) cross-referencing - related ideas may have links between them. 

[The HTML version of the ruleset goes some way to addressing this, 
but doesn't deal with exclusions and exceptions to a rule. 

[Unfortunately, explicit cross-referencing is anathema to a Nomic 
ruleset, since every single link from one Rule to another needs to
be 
maintained, which places an additional burden on the Proposer.] 

e) indexing - perhaps not for the simpler board games, but if you look
at 
the rules for an RPG or wargame you will find an index. 

[The closest analogue we have to this in MN is the series of Action 
tables, and while these are a very useful, they are incomplete (only 
covering Actions) and quite difficult to use (since you have to know 
which phase the Action operates in beforehand). 

[An index has the same issues associated with it as
cross-referencing, 
unless the index is generated (much as the HTML ruleset is).] 

f) duplication - if an idea is important, it may be explained in brief 
where it is significant with a more detailed explanation elsewhere;
or 
vital information may be summarised in a quick reference appendix. 

[The whole way in which MN is written is intended to eliminate 
duplication, since duplication requires maintenance.] 

How we actually might go about restructuring the existing ruleset to try and 
achieve these goals is beyond me at the moment. 

The stylistic issues can only really be addressed by sensitive copy editing 
(particularly ticklish in a Nomic context because of the importance of rule 
interpretation), but I think we can probably modify the structure of the 
ruleset to make such changes easier to accommodate. 

The following structural ideas occur: 

1. turn the ruleset into a database - I believe William Li did this with the 
Thring ruleset when he was Speaker of that Nomic. Basically, this approach 
means that the Ruleset as distributed is never the master version, but is 
generated by reading through the records in the database. 

The major advantage of this strategy is that renumbering, cross-referencing, 
and indexing all become relatively trivial. The disadvantage is lack of 
transferrability: look at what happened to Thring when William left the game 
(AFAIK it's still dead - any more active Thring watchers out there care to 
correct me? Paul?) 

There are actually lots and lots of counter-arguments to this approach, and
it 
would be tremendously fun to go through them, but then again it's not worth 
the time. 

2. turn the ruleset into native HTML - Kevan had a go at this a while ago,
and 
I think it was generally agreed that it didn't work terribly well (this is 
distinct from the HTML ruleset which is currently published - that is 
generated from the text file version, and will be again as soon as I work
out 
to get the BASIC program which does the conversion to work again). 

The primary perceived weakness at the time seemed to be that each section
had 
its own file. This made downloading and printing harder. 

But possibly more significant is that HTML is not one language - it has 
changed over time, and different browsers work in different ways. At least 
text files are fairly universal. 

3. split the ruleset - this is something dave mentioned, and obviously has a 
resonance with the HTML ruleset idea, but splitting into multiple text files 
makes more sense if we isolate the Nomic and MC components. 

What I would suggest would be three sections: a contents table, the Nomic 
mechanics, and the MC rules themselves. Any generated index pages (see
below) 
wouldn't be considered as part of the ruleset proper. 

4. write more indexing tools - effectively, this is an extension of the 
current text->HTML conversion, where we could write an indexing tool that 
generates one or more indices of the ruleset. 

I was thinking of two different indices - one for the text ruleset which
lists 
section numbers, and one for the HTML ruleset which provides accurate
bookmark 
references. 

The main issue with automatic indexing tools is that they do not know which 
are the important occurrences of particular words. 

5. promote the tables - group the Action, emporium and token tables to make 
them easier to find, and expand them to provide better indexing into the 
ruleset. 

I suppose the answer (as far as there can be a single answer at all) is some 
combination of all of these. 

What do people think? 

-- 
Dunx 
IRL: Duncan Ellis, Senior Software Engineer, Business Modelers, Oracle 
<I work for Oracle, I don't speak for them>

------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/l-nomic-d
Free Web-based e-mail groups by eGroups.com