June 2003

• Damage and Stuff (Math and Code) Ben Chambers
• MMO Launch issues ruining potential segments of the market. Derek Licciardi
• • MMO Launch issues ruining potential segments of the market. Mike Shaver
  • • MMO Launch issues ruining potential segments of the market. Mike Shaver
  • MMO Launch issues ruining potential segments of the market. Daniel Anderson
  • • MMO Launch issues ruining potential segments of the market. Matt Mihaly
    • MMO Launch issues ruining potential segments of the market. Luca Girardo
    • MMO Launch issues ruining potential segments of themarket. Ron Gabbard
  • MMO Launch issues ruining potential segments of the market. Chris Holko
  • • MMO Launch issues ruining potential segments of the market. Matt Mihaly
    • • MMO Launch issues ruining potential segments of the market. Daniel.Harman@barclayscapital.com
  • MMO Launch issues ruining potential segments of the market. Justin Coleman
  • MMO Launch issues ruining potential segments of th e market. Daniel.Harman@barclayscapital.com
  • MMO Launch issues ruining potential segments of th e market. Jeff Fuller
  • MMO Launch issues ruining potential segments of the market. Matt Mihaly
  • • MMO Launch issues ruining potential segments of the market. Tess Snider
  • MMO Launch issues ruining potential segments of the market. Luca Girardo
  • • MMO Launch issues ruining potential segments of the market. Tess Snider
    • MMO Launch issues ruining potential segments of the market. Matt Mihaly
    • MMO Launch issues ruining potential segments of the market. Jeff Fuller
    • • MMO Launch issues ruining potential segments of themarket. Chris Holko
      • • MMO Launch issues ruining potential segments ofthemarket. Scott Jennings
        • MMO Launch issues ruining potential segments of the market. Jeff Fuller
• New Column by Dave Rickey "Engines of Creation" Now at Skotos Christopher Allen
• Announcing Shadow Door: an NPC Control Interface for Neverwinter Nights Robert Zubek
• ADMIN: So, what has been happening? J C Lawrence
• [Meta] Forward of moderated message J C Lawrence
• New Here MIKE MacMartin
• • New Here Mike
  • • New Here MIKE MacMartin
    • • New Here Miroslav Silovic
      • • New Here MIKE MacMartin
• Looking for a GUI Mud Development program Snicker Furfoot
• • Looking for a GUI Mud Development program Ben Greear
• ADMIN: List archives are now restored. J C Lawrence
• The Price of Being Male Rayzam
• • The Price of Being Male Sasha Hart
  • The Price of Being Male Daniel.Harman@barclayscapital.com
  • • The Price of Being Male Rayzam
    • • The Price of Being Male Byron Ellacott
      • The Price of Being Male Dr. Cat
    • The Price of Being Male Castronova, Edward
    • • The Price of Being Male Boyle, Paul
      • The Price of Being Male Mark 'Kamikaze' Hughes
      • • The Price of Being Male Rayzam
        • • The Price of Being Male Mark 'Kamikaze' Hughes
          • • The Price of Being Male Rayzam
            • • The Price of Being Male Mark 'Kamikaze' Hughes
        • The Price of Being Male Marian Griffith
        • • The Price of Being Male Paul Schwanz
          • • The Price of Being Male Rayzam
            • • The Price of Being Male Paul Schwanz
              • The Price of Being Male Vincent Archer
              • • The Price of Being Male Rayzam
        • The Price of Being Male Castronova, Edward
        • • The Price of Being Male Sasha Hart
          • The Price of Being Male Mark 'Kamikaze' Hughes
          • • The Price of Being Male Amanda Walker
          • The Price of Being Male Richard A. Bartle
          • • The Price of Being Male Castronova, Edward
            • • The Price of Being Male Richard A. Bartle
          • The Price of Being Male Tazzik
          • • The Price of Being Male Richard A. Bartle
            • • The Price of Being Male Tazzik
      • The Price of Being Male Richard A. Bartle
      • • The Price of Being Male Marian Griffith
        • • The Price of Being Male Sasha Hart
          • • The Price of Being Male Tom
            • The Price of Being Male Marian Griffith
            • • The Price of Being Male Sasha Hart
              • • The Price of Being Male Marian Griffith
                • • The Price of Being Male Sasha Hart
          • The Price of Being Male Richard A. Bartle
        • The Price of Being Male Castronova, Edward
        • • The Price of Being Male Richard A. Bartle
        • The Price of Being Male Daniel.Harman@barclayscapital.com
      • The Price of Being Male Paul Schwanz
      • The Price of Being Male Daniel Anderson
      • • The Price of Being Male Travis Casey
        • • The Price of Being Male Paul Schwanz
          • • The Price of Being Male Travis Casey
          • The Price of Being Male Chris Holko
          • • The Price of Being Male Travis Casey
            • • The Price of Being Male Sanvean
              • • The Price of Being Male Sasha Hart
                • The Price of Being Male Tom
                • • The Price of Being Male Sanvean
                  • • The Price of Being Male Tom
  • The Price of Being Male Paul Schwanz
  • The Price of Being Male Amanda Walker
  • The Price of Being Male shop@isparkinson.co.uk
  • The Price of Being Male Boyle, Paul
  • The Price of Being Male Ola Fosheim Grøstad
  • • The Price of Being Male Sheela Caur'Lir
    • • The Price of Being Male Jeff Crane
• Are gold pieces taxable? Koster, Raph
• • Are gold pieces taxable? Boyle, Paul
  • • Are gold pieces taxable? Amanda Walker
  • Are gold pieces taxable? Thomas Leavitt
  • Are gold pieces taxable? Daniel.Harman@barclayscapital.com
• Functors / Loki (was: New Here) Eli Stevens
• Architecture Peter "Pietro" Rossmann
• • Architecture Peter "Pietro" Rossmann
  • • Architecture ceo
    • • Architecture Peter "Pietro" Rossmann
• SW:G this is so unfair Marian Griffith
• • SW:G this is so unfair Marc Bowden
  • SW:G this is so unfair Martin Bassie
• Players policing themselves (was: MMO Launch issues ruining potential segments of themarket.) Derek Licciardi
• • Players policing themselves (was: MMO Launch issues ruining potential segments of themarket.) Marian Griffith
• Q&A with Ken Troop, Lead Designer at Turbine Michael Tresca
• • Q&A with Ken Troop, Lead Designer at Turbine Threshold RPG
  • • Q&A with Ken Troop, Lead Designer at Turbine Mike Shaver
    • Q&A with Ken Troop, Lead Designer at Turbine Chris
• Architecture (Cell Rebalancing) Peter "Pietro" Rossmann
• • Architecture (Cell Rebalancing) Zach Collins {Siege}
  • • Architecture (Cell Rebalancing) Peter "Pietro" Rossmann
  • Architecture (Cell Rebalancing) Daniel.Harman@barclayscapital.com
  • • Architecture (Cell Rebalancing) Peter "Pietro" Rossmann
    • Architecture (Cell Rebalancing) Rossmann Peter
    • • Architecture (Cell Rebalancing) ceo
      • • Architecture (Cell Rebalancing) Peter "Pietro" Rossmann
        • • Architecture (Cell Rebalancing) J C Lawrence
            On Thu, 3 Jul 2003 02:43:55 +0200
            Peter Rossmann <Peter> wrote:
            
            > who is ISTR JC?
            
            ISTR == I Seem To Recall
            
            JC, or more often "JCL" or "Claw" would be me.
            
            >> ...spoke a couple of times about dependent working sets on the night
            >> before the MDC (in relation to a dicussion on geographical
            >> partitioning).
            
            > any links/memories of that speech? never heard that before.
            
            Hit the list archives. Its all there. You might also like to dig back
            to the old discussions around my server model and C&C (compare &
            commit). As base structure it wasn't a bad approach, and even scaled
            fairly well for a soft-code runtime morphic system as long as
            transaction set's working sets didn't cluster too hard.
            
            >> Otherwise you have a design that is easy for a human to read on
            >> paper, but practically impossible to implement.
            
            > reading easines for human is only the visual/graphical
            > configuration. if the design is right, then the partitioning will be
            > right and the connections will be on proper places in regard to
            > endpoints.
            
            I've not jumped in on this design thread as you're approaching from an
            angle which I know others find profitable, but which has never been
            either useful or illuminating for me. For me designs are best evolved
            from constraints, requirements and use cases (which are really just
            constraints married to requirements, but bear with me).
            
            Start out by stating what you want to do. Clearly, simply, in no more
            than a half dozen nice declarative sentences. Beat on that for a while
            -- beat on it until nothing is left but the absolutely necessary major
            bones. This is your statement of "purpose". Then work over that and
            start pulling out some constraints and requirements. Arm waving stuff
            is good enough at this level. Then go back and start adding use cases.
            Start inventing scenarios. Make then as detailed as you can. Specify
            WHAT the system must accomplish in the use cases, but not HOW. This is
            usually the fun bit -- don't hold back, thrown in everything you can
            think of.
            
            Now go back and line up your use cases with your purpose statement. If
            they fail to line up naturally, one or the other is at fault. Fix it.
            Once all the use cases are happy, pull in the requirements and
            constraints to match.
            
            Add more use cases. Get dreamy. Heck, add a use case every time you
            get bored, have an idea, or just feel like it -- but make sure every one
            lines up perfectly with the purpose statement (discard the ones that
            head out on tangents).
            
            Odds are you can get this done a few days to a week -- its normally a
            lot of fun. Once you've got that done you'll find you understand the
            backgrounds and contexts that the basic design structures will start
            natively falling out.
            
            A point to aware of here is that those design structures natively fall
            out so easily because there's a natural tendency to structure your
            thinking in terms of what you know. Thus your use cases etc will tend
            to align to the types of systems, architectures, and models you're
            familiar with.
            
            Now's the time to start the blue sky research. Go dig. read (the
            archives), find as many other fields of work and thought that you can
            relate what you want to do to as you can. Then cherry pick them, line
            up your use cases, purpose statement etc, and get going.
            
            > The trouble with many architects is that they start to program too
            > soon, in too detailed areas and the result is no good then.
            
            Yup. The same is true of many architects: they design far too soon and
            in too much abstraction. Design is a Good Thing, but can kill a project
            just as readily as lack of design.
            
            --
            J C Lawrence
            ---------(*) Satan, oscillate my metallic sonatas.
            claw@kanga.nu He lived as a devil, eh?
            http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
          • • Architecture (Cell Rebalancing) Peter "Pietro" Rossmann
            • • Architecture (Cell Rebalancing) J C Lawrence
          • Architecture (Cell Rebalancing) Rossmann Peter
        • Architecture (Cell Rebalancing) Rossmann Peter
        • • Architecture (Cell Rebalancing) J C Lawrence
          • • Architecture (Cell Rebalancing) Peter "Pietro" Rossmann
      • Architecture (Cell Rebalancing) Daniel.Harman@barclayscapital.com
      • • Architecture (Cell Rebalancing) Peter "Pietro" Rossmann