February 2000
- datagram protocol design theory? (Question about multithreaded servers) Ola Fosheim Grøstad
- Library error J C Lawrence
- Semi-OT: Linux support in commercial MUDs? Ola Fosheim Grøstad
- From the Apache Referrer logs J C Lawrence
- From the Apache Referrer logs Kris Van Hees
- good muds for ai programming? Robert Zubek
- good muds for ai programming? J C Lawrence
- Event Scheduling Phillip Lenhardt
- Event Scheduling J C Lawrence
- Event Scheduling cg@ami-cg.GraySage.Edmonton.AB.CA
- Event Scheduling J C Lawrence
- Event Scheduling Phillip Lenhardt
- Event Scheduling J C Lawrence
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Miroslav Silovic
- Event Scheduling Jp Calderone
- Event Scheduling Ola Fosheim Grøstad
- Event Scheduling Miroslav Silovic
- Event Scheduling J C Lawrence
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- IO Speed Suggestions Christopher Kohnert
- IO Speed Suggestions J C Lawrence
- Couple of articles Koster, Raph
- Couple of articles Dr Richard A. Bartle
- OT: Soliciting advice from Canadians Alex Oren
- MUD Specific Building pages MichelleThompson
- MUD Specific Building pages J C Lawrence
- Embedding Python icecube@ihug.co.nz
- Embedding Python icecube@ihug.co.nz
- Embedding Python J C Lawrence
- Embedding Python Todd McKimmey
- Embedding Python Oliver Jowett
- Embedding Python Todd McKimmey
- ADMIN: List post rejections J C Lawrence
- distributed objects Kevin Littlejohn
- distributed objects Vijay Weasel Prabhakar
- distributed objects Brandon J. Rickman
- distributed objects J C Lawrence
- distributed objects Koster, Raph
- distributed objects Vijay Weasel Prabhakar
- distributed objects David Bennett
- distributed objects Phillip Lenhardt
- distributed objects cjones@one.net
- distributed objects F. Randall Farmer
- distributed objects Ola Fosheim Grøstad
- distributed objects Kevin Littlejohn
- distributed objects J C Lawrence
- distributed objects Gary Whitten
- distributed objects Balthazaar
- distributed objects J C Lawrence
- distributed objects Ola Fosheim Grøstad
- distributed objects Eli Stevens {Grey}
- distributed objects Jon A. Lambert
- distributed objects Charles Hughes
- distributed objects Caliban Tiresias Darklock
- distributed objects Charles Hughes
- distributed objects J C Lawrence
- distributed objects J C Lawrence
- distributed objects Charles Hughes
- distributed objects Charles Hughes
- distributed objects Laurent Bossavit
- distributed objects Kevin Littlejohn
- distributed objects markm@caplet.com
- distributed objects KevinL
- Distributed Objects Justin Rogers
- Security J C Lawrence
- commercial muds and cable TV (was code base inquiry ) Sellers, Michael
- commercial muds and cable TV (was code base inquiry ) Matthew Mihaly
- commercial muds and cable TV (was code base inq uiry ) Sellers, Michael
- commercial muds and cable TV (was code base inq uiry ) Matthew Mihaly
- business models Matthew Mihaly
- business models Daniel.Harman@barclayscapital.com
- business models Vincent Archer
- business models Dave Rickey
- a shrinking pool of players? Johan J Ingles-le Nobel
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? Bryce Harrington
- a shrinking pool of players? Travis S. Casey
- a shrinking pool of players? PartyG2816@aol.com
- a shrinking pool of players? J C Lawrence
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? PartyG2816@aol.com
- a shrinking pool of players? Ryan P.
- a shrinking pool of players? J C Lawrence
- a shrinking pool of players? Koster, Raph
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Koster, Raph
- a shrinking pool of players? Chris Turner
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Chris Turner
- a shrinking pool of players? Draymoor
- a shrinking pool of players? Koster, Raph
- The Endeavour Map and MUD Applications Michael Hohensee
- The Endeavour Map and MUD Applications Ted Milker
- The Endeavour Map and MUD Applications David Bennett
- The Endeavour Map and MUD Applications Ted Milker
- The Endeavour Map and MUD Applications John Bertoglio
- The Endeavour Map and MUD Applications Justin Rogers
- The Endeavour Map and MUD Applications Eli Stevens {Grey}
- The Endeavour Map and MUD Applications John Bertoglio
- The Endeavour Map and MUD Applications Koster, Raph
- The Endeavour Map and MUD Applications Lo, Kam
- The Endeavour Map and MUD Applications Justin Rogers
- The Endeavour Map and MUD Applications Joel Dillon
- The Endeavour Map and MUD Applications Justin Rogers
- Next gen MUD wishlist Bryce Harrington
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist Bryce Harrington
- Next gen MUD wishlist Bruce
Bryce Harringon wrote:
> On Sat, 19 Feb 2000, Bruce wrote:
> > One problem that I have is that many people equate the above to being a
> > server under the GPL. Since I'm approaching this with a highly
> > commercial bent (and plan to announce our open source project
> > real-soon-now), that really doesn't work well for me. I much prefer a
> > highly modular system with well defined APIs, licensed under either the
> > LPGL or the Mozilla Public License (with the appropriate modifications
> > to the boilerplate).
>
> Okay, so, say the underlying libraries (including especially the network
> layer) should be LGPL'd, allowing the remainder to be licensed as
> desired by the implementors of the server itself? I admit I am indeed
> thinking of GPL, but no reason there couldnt be multiple implementations
> of the design, some of which may be GPL, others something else. So I
> agree with you: If the important modules are sharable, that should be
> enough.
Why implement the design multiple times? This is a waste of everyone's
time
if those people seriously intend to use it. If everyone writes their
own
version due to licensing differences, then we might as well just keep
them
all proprietary. This should be under a fairly liberal and open
license,
not the GPL. I might be offbase here by being more interested in
getting
something done and built, rather than just watching people write the
infrastructure again and again.
> While I was involved with the MPL development I really prefer the LGPL;
> it was IMHO better thought out. The MPL was done in kind of a rush...
The MPL solves some of the serious issues in the LGPL though with
regards to
mixing object code by completely ignoring them.
> > > Server
> > > * Should support on the order of 100-500 simultaneous players
> > > (Is this a realistic number?)
> >
> > This is easily doable with any of a number of servers around today. My
> > goal is to scale well past that. My base requirements are to be able to
> > support at least 5000 users in a single world. I'd be happy to support
> > ten times that.
>
> *Nod* Okay... I guess I'm thinking that with the coordinate-based
> physics the bandwidth per connection could be higher.
So? If the commercial games support 1000+ players currently and can
only be
expected to support more in the future, any effort at an open source
game
engine should aim to supercede that. We certainly plan on it.
> Would it be better to specify this in terms of bandwidth per person?
> How many players should a server on a T1 be able to serve? On a OC3?
> A cablemodem? A 56k modem?
The server side bandwidth doesn't matter. Who is the target user? How
much
bandwidth do they have? Work backwards to find out how much bandwidth
the
server farm will need.
> > > * Should permit scripting in easy to learn, existing language
> >
> > There are some other options here. Customization (not extension) need
> > not involve scripting. Rules-based authoring systems can provide for
> > customization in an even easier way than scripting.
>
> Ah, good point. Mind elaborating?
Wait a couple of weeks for our announcement. :)
> > > * (Desired) should allow use of any arbitrary scripting language(?)
> >
> > I'd rather have one well done, consistent system. I want a single clean
> > object model that fits the requirements of my system, not a hodge-podge
> > that was jury-rigged to make it work with any given scripting language.
> > But, I might be odd in that I don't mind learning new languages and new
> > object models to get a job done.
>
> Hmm, okay. I specified this mostly because I know everyone has their
> own favorite scripting language, and that deciding on a single language
> can be hard. For instance, I might perfer Python, but someone else
> want Mercury, Guile or Perl (or worse!)
>
> What if it was a compile-time option? So, a given compiled instance of
> a server might only support a single scripting language (or even none,
> if one wishes to really squeeze out every bit of performance), but
> people are still permitted the ability to choose.
People will always complain about something. If this path is followed,
then
you'll hear complaints about how code can't be shared, or "Why is this
written in language X? I don't know that language." ... I'd rather not
be
bothered.
But, a key thing is to allow the use of the appropriate tools for the
right
task. My designs take that into account and allow for multiple
languages at
a very different level, where it ends up making a lot of sense.
> > > * Should abstract rules in a way that allow modular replacement
> > > * Should be genre-generic, and even game-generic, at the core
> > > * A stock world/rules should be provided, as a basis to work from.
> > > Further, it should include all graphics, music, and text media to
> > > characterize that world.
> >
> > This shouldn't be seen as an excuse to avoid documenting the server
> > though as happens all too often. :)
>
> Ah, decidely not! ;-)
>
> My plan is to first assemble a fairly extensive wishlist, and then
> extract it into a more proper (and complete) requirements list. Then a
> design document would be drawn up, and only then would implementation be
> allowed to go forth. Separate docs would be want to be written, but if
> worse came to worse, at least there would be the design docs to fall
> back on.
>
> I think once the design docs exist, pretty much any decent programmer
> could code it up, assuming of course that the design was good and had a
> solid basis in reality. ;-)
The core game engine is but a small piece of the pie. The game
mechanics
and everything needed to flesh out the game can be far larger. That's
why
we're going the route of opening up the design and implementation of our
core game engine: shared infrastructure only benefits all of us, whether
we're commercially focused or not.
> > If all of this is to be the 'Next generation' of MUDs, then we (the mud
> > world) are largely already there. MOO and Cold have been here at this
> > level for some time, or had the capabilities of being at this level at
> > the core architecture level. They've had graphical clients. Some of
> > them have had coordinate based systems. They've been able to handle
> > 100-500 users. That said, I've moved on from those systems for reasons
> > explained in the list archives.
> >
> > Isn't it time to really move on to the next generation?
>
> Hmm, did not know that... So you're right, we ought to shoot for a
> little more aggressivity. What would you suggest as good challenges to
> undertake?
Read the list archives!
- Bruce - Next gen MUD wishlist J C Lawrence
- Next gen MUD wishlist Chris Jones
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist adam@treyarch.com
- Next gen MUD wishlist Sellers, Michael
- Next gen MUD wishlist adam@treyarch.com
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist Bryce Harrington
- Codebase Ideas punitac@prodigy.net
- Codebase Ideas Bryce Harrington
- Codebase Ideas Aaron Mitchell
- OT: Money as motivator (was code base inquiry ) J C Lawrence
- OT: Money as motivator (was code base inquiry ) Matthew Mihaly
- Guide Applicant : Player Ratio Geoffrey A. MacDougall
- Guide Applicant : Player Ratio Matthew Mihaly
- MUD-Dev digest, Vol 1 #286 - 13 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #286 - 13 msgs Caliban Tiresias Darklock
- MUD-Dev digest, Vol 1 #286 - 13 msgs Koster, Raph
- voice vs. text Matthew Mihaly
- voice vs. text Justin Rogers
- voice vs. text John Bertoglio
- voice vs. text Lovecraft
- voice vs. text Lo, Kam
- voice vs. text Hans-Henrik Staerfeldt
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Koster, Raph
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Justin Rogers
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Koster, Raph
- Client side prediction Ola Fosheim Grøstad
- Dynamic help files, was code base inquiry Richard Woolcock
- OpenSource licenses for game rules? J C Lawrence
- To all the devoted! (fwd) J C Lawrence
- Newbies Johan J Ingles-le Nobel
- MUD-Dev digest, Vol 1 #288 - 9 msgs Dr. Cat
- (fwd) Commercial-use Restrictions on Code Bases (was: help me find 100% free graphical mud) J C Lawrence
- (fwd) ADMIN: "A Classification Of Muds" [was 'In defence of stock muds...'] J C Lawrence
- Distribution Geir Harald Hansen
- player persistence Matthew Mihaly
- [Off-topic] GDC-2000 Derek Snider
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 Justin Lockshaw
- [Off-topic] GDC-2000 Christopher Allen
- [Off-topic] GDC-2000 Matthew Mihaly
- [Off-topic] GDC-2000 Joe Andrieu
- [Off-topic] GDC-2000 Kristen L. Koster
- [Off-topic] GDC-2000 Richard A. Bartle
- [Off-topic] GDC-2000 Bruce
- [Off-topic] GDC-2000 David Bennett
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] AAAI symposium (was: GDC-2000) Robert Zubek
- MSP Richard Ross
- Privateer-style mu*? Bobby Bailey
- Minimum community sizes Dan Root
- Minimum community sizes Koster, Raph
- Minimum community sizes Dan Root
- Minimum community sizes adam@treyarch.com
- Minimum community sizes Matthew Mihaly
- Minimum community sizes David Bennett
- Minimum community sizes Matthew Mihaly
- Pike codebase Daniel Podlejski
- chil@gate.net Joel Kelso