From brandon at cs.uri.edu  Thu Mar  8 15:08:03 2007
From: brandon at cs.uri.edu (Brandon Edens)
Date: Thu, 8 Mar 2007 10:08:03 -0500
Subject: [lmud-devel] Common Lisp Mud Development
Message-ID: <20070308150803.GG9491@bruno.petnet.net>

Hi all,

Not sure how long this list has been quiet. I'm writing because I've been
hacking MUD code in Common Lisp. This is not specifically lmud related as I
wrote my own code from scratch but I did want to engage in discussions with
other MUD hackers.

If anyone is out there and interested, drop a line, and let's have some Common
Lisp Mud discussion.

Brandon

-- 
Brandon Edens                                   brandon at cs.uri.edu
http://www.brandonedens.org
key 0x55438F48
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/lmud-devel/attachments/20070308/0a456e8b/attachment.sig>

From holtzermann17 at gmail.com  Thu Mar  8 17:22:35 2007
From: holtzermann17 at gmail.com (Joe Corneli)
Date: Thu, 8 Mar 2007 11:22:35 -0600
Subject: [lmud-devel] Re: Lisp MUD development
In-Reply-To: <1173366932.28633.3.camel@localhost.localdomain>
References: <20070219004047.BB02581AD@planetmath.cc.vt.edu>
	<1173366932.28633.3.camel@localhost.localdomain>
Message-ID: <a9670630703080922ie3e14a1yfb44294a5eaf1f7c@mail.gmail.com>

Thanks Heow --

I've been talking with Nick Thomas about his Monster Mountain
codebase, and making a few contributions there.  After kicking
what tires there are, they seem quite solid.  Monster Mountain
is a way to get people interacting with Lisp, but there isn't a
whole lot else there to interact with yet.  I'm currently working
on getting it hooked into a database that would contain code
and other "world objects".

The direction I'm interested in going is outlined here:

http://planetx.cc.vt.edu/AsteroidMeta/MUSN

Monster Mountain is here:

http://code.google.com/p/mmtn/

I'd definitely be interested in hearing about other things going
on in the Lisp MUD world.

On 3/8/07, Heow Eide-Goodman <heow at alphageeksinc.com> wrote:
> Hey guys, talk about timing!
>
> Brandon just dropped me a line and is interested in raising discussions
> regarding CL mud hacking:
>
>
>   lmud-devel at common-lisp.net
> I personally see the problem more as a collaborative development effort
> rather than a glorified chat room.  :-)
>
> - Heow
>
>


From brandon at cs.uri.edu  Thu Mar  8 21:43:36 2007
From: brandon at cs.uri.edu (Brandon Edens)
Date: Thu, 8 Mar 2007 16:43:36 -0500
Subject: [lmud-devel] Re: Lisp MUD development
In-Reply-To: <a9670630703080922ie3e14a1yfb44294a5eaf1f7c@mail.gmail.com>
References: <20070219004047.BB02581AD@planetmath.cc.vt.edu>
	<1173366932.28633.3.camel@localhost.localdomain>
	<a9670630703080922ie3e14a1yfb44294a5eaf1f7c@mail.gmail.com>
Message-ID: <20070308214336.GA21445@bruno.petnet.net>

Hi all!

Glad to find some kindred spirits. 
I pulled down Monster Mountain and started going through the code. Also took a
look at MUSN. I'll write more after I've fully digested everything.

I've been going it alone for quite awhile now. Definitely want to continue
discussing mud work, specifically common lisp mud work. I hope lmud-devel
doesn't mind our chatter; if it is a problem we could always create a new
mailing list cl-mud for discussions related to common lisp mud programming.

I'm working on what I call BMUD. Now that I've found some community I'm going to
push it up to Sourceforge as soon as my account application goes through. I've
been working on it, off and on for awhile now. I had trivial versions in
Python/Ruby/C++ before finally settling in with Common Lisp. There was a woman
that built an entire Diku/Circle equivalent in Common Lisp in approximately 3
months time. Her codebase was lost in a hard drive crash. I only saw the game
briefly but I can say a few things. First, it was highly dynamic. They were
building the world in game, reloading the game on the fly etc... I didn't learn
until later that you get all this for free when you use Common Lisp. Hooray!
Also things were fast. The network IO difference between a common lisp MUD and
something written in Ruby, well....


BMUD is slow going but I think that is just because I've been doing a lot of
exploratory coding.  The codebase is GPLed like Monster Mountain so I'm thinking
we can cross pollinate. Definitely ideal.

Some thoughts about relicensing completed versions of the game as Affero after I
spoke with Richard Stallman a few months ago. Only because I want to make sure
that players will have access to the code base in case a mud shuts down. I
suppose I could just add in-game functions that allow players to dump the source
code to their terminals and just leave it as GPL with words of encouragement
asking administrators to share the code freely, and not remove the code dump
functionality.

BMUD is Diku/Circle/LP inspired. I was a long time Duris/Toril/Sojourn/Arctic
player. I also occasionally play Battlemech frontiers (btmux). I'm trying to
match a Circle Mud derivative called Greycode. I think you can find it in the
Circle archives. Greycode is more rogue-like than your traditional MUD. I guess
in terms of the world we're talking about a textural map, line of sight, dynamic
lighting and the like. I'm also attempting to make the world fully deformable
and persistent with the end goal of allowing players to take over parts of the
world and remake them in their own image. NPCs will hopefully do the same. 

Using the D20 rule-base.
http://www.d20srd.org/


Greycode had the concept of traditional MUD rooms with each containing an
interior grid. The game would combine these rooms together to blow the world up
into a grid. This is a difficult way of implementing things. I think its rife
with possibility of graph theory problems. I was pursuing this recently but
decided to instead start handling things entirely within a grid system. Reason
is that computing the target of a ranged attack is simple geo/trig. A grid is
made up of 4 layers: terrain, mobs, objects, and meta. The meta layer holds
pointers to room data of a traditional variety. I've got some test code in the
BMUD code base. I'll hopefully have the capability for the player to walk around
the grid shortly.

Going to switch over to responding in-line. (Sorry for the top-post).

On Thu, Mar 08, 2007 at 11:22:35AM -0600, Joe Corneli wrote:

> Thanks Heow --
> 
> I've been talking with Nick Thomas about his Monster Mountain
> codebase, and making a few contributions there.  After kicking
> what tires there are, they seem quite solid.  Monster Mountain
> is a way to get people interacting with Lisp, but there isn't a
> whole lot else there to interact with yet.  I'm currently working
> on getting it hooked into a database that would contain code
> and other "world objects".

I built a rudimentary file based system. I never really understood how pleasant
(read) (print) can be until I looked over PCL chapter 3 again... Let me get the
code up on Sourceforge before I go into it. I'm also sure I'm going to run into
issues of thread safety with this system though. We'll see.

> The direction I'm interested in going is outlined here:
> 
> http://planetx.cc.vt.edu/AsteroidMeta/MUSN
> 
> Monster Mountain is here:
> 
> http://code.google.com/p/mmtn/

BTW Why code.google.com? I was looking over the site. Is there some
disadvantageous towards using Sourceforge?

> I'd definitely be interested in hearing about other things going
> on in the Lisp MUD world.

We need to get some codebases out there so we can secure bragging rights. I see
C# muds popping up on Erin Andreasen's New Mud Codebase's!
http://www.andreasen.org/newmud/


> On 3/8/07, Heow Eide-Goodman <heow at alphageeksinc.com> wrote:
> >Hey guys, talk about timing!
> >
> >Brandon just dropped me a line and is interested in raising discussions
> >regarding CL mud hacking:

Should've put the word out awhile ago. 

> >I personally see the problem more as a collaborative development effort
> >rather than a glorified chat room.  :-)

I'm definitely down. Nice to find others. I figure the community will grow if we
get some usable codebases out there. I find common lisp great for snippet
hacking. I think it is partially functional programming and also related to the
attention to writing code with low side effects.

I'll write back when BMUD goes onto sourceforge. It isn't playable but there is
a lot of useful functions written and it is getting further along each day.

Brandon

-- 
Brandon Edens                                   brandon at cs.uri.edu
http://www.brandonedens.org
key 0x55438F48
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/lmud-devel/attachments/20070308/73d9d7c6/attachment.sig>

From brandon at cs.uri.edu  Fri Mar  9 14:52:51 2007
From: brandon at cs.uri.edu (Brandon Edens)
Date: Fri, 9 Mar 2007 09:52:51 -0500
Subject: [lmud-devel] Re: Lisp MUD development
In-Reply-To: <Pine.GSO.4.50.0703081824020.20854-100000@garnet.tc.umn.edu>
References: <20070219004047.BB02581AD@planetmath.cc.vt.edu>
	<1173366932.28633.3.camel@localhost.localdomain>
	<a9670630703080922ie3e14a1yfb44294a5eaf1f7c@mail.gmail.com>
	<20070308214336.GA21445@bruno.petnet.net>
	<Pine.GSO.4.50.0703081824020.20854-100000@garnet.tc.umn.edu>
Message-ID: <20070309145251.GB21445@bruno.petnet.net>

On Thu, Mar 08, 2007 at 06:37:04PM -0600, Thomas A Lenius wrote:

> i think locking is one reason to use a decent db (postgresql in our
> possible implementation)

Yeah, it is going to be an issue. For some reason I thought file operations in
*nix were atomic. At least they aren't in Linux. I ran a cat > yoyo.txt test
from two bash instances and was randomly merging data into each.

I'll wait until it becomes something serious then introduce locking. I could
also channel saves through a single mechanism to ensure that multiple threads
aren't saving the same data at the same time.

I've used cl-sql both the mysql uffi wrapper and the postgresql network adapter.
I've got to admit that Kevin did a great job with that. My only complaint is the
usage of uffi instead of cffi but he wrote uffi so can we blame him?


> also it simplifies porting. the storage format can remain a blackbox; all
> clients need to know is sql, i.e., have a driver. compare with keeping
> track of details for a custom fs level format

Actually, this is what I was going to write about so I'll just toss it out right
now. Still waiting on the acceptance of the Sourceforge project. Let me give you
the basic mechanics for how I'm doing save/load.

This will be a bit abbreviated and is definitely a candidate for macro goodness
because I have near identical machinery between players, objects, and mobs.

(defclass player ()
  ((username
    :initarg :username
    :initform "")
   (password
    :initarg :password
    :initform "")))

(defmethod to-list ((player player))
  "Converts a player object into a list."
  (with-slots (username password) player
    (list 'PLAYER :username username :password password)))

(defmethod print-list ((player player) &optional (stream t))
  "Prints out the player information in list format."
  (format stream "~s" (to-list player)))

(defmethod print-object ((player player) stream)
  "Print object overloaded for players."
  (print-unreadable-object (player stream :type t :identity t)
    (print-list player stream)))

(defmethod save ((player player))
  "Saves a player to disk."
  (with-slots (username) player
    (log-debug "Saved player ~a." username)
    (write-player username (to-list player))))

(defun make-player (data)
  "Makes a player from given data (most likely a (PLAYER ... list))."
  (etypecase data
    (cons
     (apply 'make-instance 'player (rest data)))))

(defun read-player (username)
  "Loads and reads a player with given username from disk."
  (with-open-file (stream (merge-pathnames *player-directory*
                                           (format nil "~a.lisp" (string-downcase username)))
                          :direction :input
                          :if-does-not-exist :error)
    (with-standard-io-syntax
      (read stream))))

(defun write-player (username data)
  "Saves a player with the given username to disk."
  (with-open-file (stream (merge-pathnames *player-directory*
                                           (add-lisp-suffix
                                            (space-to-underscore
                                             (string-downcase username))))
                          :direction :output
                          :if-exists :overwrite
                          :if-does-not-exist :create)
    (with-standard-io-syntax
      (print data stream))))



Here's an example of it's usage (this is my real player class).
BMUD> (make-instance 'player :username "tom" :password (hash-password "ping-pong") :firstname "Thomas" :lastname "Jones" :email "tjones at yoyo.com")
#<PLAYER (PLAYER :USERNAME "tom" :PASSWORD
          "f2764ee70e739a32a7aa4de35b005184290d50f51b1bb9cc27573f275d8ebb33"
          :FIRSTNAME "Thomas" :LASTNAME "Jones" :EMAIL "tjones at yoyo.com"
          :CREATED-TIMESTAMP 3382439955 :TOTAL-TIME-PLAYED 0 :PLAYER-KILLS 0
          :PLAYER-DEATHS 0 :MOB-KILLS 0 :MOB-DEATHS 0 :MOB NIL :PROMPT-COLOR
          :GREY :CONNECT-TIME 3382439955 :IDLE-TIME 0 :TITLE "") {10024583F1}>
BMUD> 



I save this new player.
BMUD> (save (make-instance 'player :username "tom" :password (hash-password "ping-pong") :firstname "Thomas" :lastname "Jones" :email "tjones at yoyo.com"))




Now to show what it looks like on the filesystem.
brandon at bruno ~/bmud/var/players $ cat tom.lisp 

(BMUD::PLAYER :USERNAME "tom" :PASSWORD "f2764ee70e739a32a7aa4de35b005184290d50f51b1bb9cc27573f275d8ebb33" :FIRSTNAME "Thomas" :LASTNAME "Jones" :EMAIL "tjones at yoyo.com" :CREATED-TIMESTAMP 3382439987 :TOTAL-TIME-PLAYED 0 :PLAYER-KILLS 0 :PLAYER-DEATHS 0 :MOB-KILLS 0 :MOB-DEATHS 0 :MOB NIL :PROMPT-COLOR :GREY :CONNECT-TIME 3382439987 :IDLE-TIME 0 :TITLE "")


Now I go ahead and load the player "tom".
BMUD> (read-player "tom")
(PLAYER :USERNAME "tom" :PASSWORD
 "f2764ee70e739a32a7aa4de35b005184290d50f51b1bb9cc27573f275d8ebb33" :FIRSTNAME
 "Thomas" :LASTNAME "Jones" :EMAIL "tjones at yoyo.com" :CREATED-TIMESTAMP
 3382439987 :TOTAL-TIME-PLAYED 0 :PLAYER-KILLS 0 :PLAYER-DEATHS 0 :MOB-KILLS 0
 :MOB-DEATHS 0 :MOB NIL :PROMPT-COLOR :GREY :CONNECT-TIME 3382439987 :IDLE-TIME
 0 :TITLE "")
BMUD> (make-player (read-player "tom"))
#<PLAYER (PLAYER :USERNAME "tom" :PASSWORD
          "f2764ee70e739a32a7aa4de35b005184290d50f51b1bb9cc27573f275d8ebb33"
          :FIRSTNAME "Thomas" :LASTNAME "Jones" :EMAIL "tjones at yoyo.com"
          :CREATED-TIMESTAMP 3382439987 :TOTAL-TIME-PLAYED 0 :PLAYER-KILLS 0
          :PLAYER-DEATHS 0 :MOB-KILLS 0 :MOB-DEATHS 0 :MOB NIL :PROMPT-COLOR
          :GREY :CONNECT-TIME 3382439987 :IDLE-TIME 0 :TITLE "") {10028F9001}>





If you see anything that could be further improved please let me know. I'm
probably going to go back to using random serial number's for mobs and objects
soon. ie bmud/var/mobs/mob-3382440161-2AED195510E176A-1CFAE095F174DF5.lisp
for instance.

(defun generate-random-serial-number ()
  "Generates a random serial number using current time and some random numbers.
We're hoping that through the massive size of the number that we might be able to
produce something suitably random."
  (format nil "~10,'0d-~15,'0x-~15,'0x"
          (get-universal-time)
          (random 999999999999999999)
          (random 999999999999999999)))


I might actually store them under the mob's current "zone" location to ease
loading all the mobs last held in a zone when the zone is loaded back into the
game. Of course you run the risk of possibly duplicating mobs; if you move a mob
from one zone to another, then don't properly remove the old mob after saving it
in its new zone location.


Some of the benefits of this system is that it is data is stored in lists and is
parseable by Common Lisp. It is trivial to add new features to
mobs/objects/players. Even if you needed to modify all of the existing records
to remove some existing feature, well we're talking about normal *nix text
processing tools like grep/sed/awk/etc...



> but i haven't looked at what anyone else is doing so maybe i'm off.
> performance is one reason i can see for going without a db

That is a big one for me. Saving/Loading mobs is O(1) on the filesystem. Also
because my game is persistent I'm going to be modifying game world contents
constantly. 

I'm writing the game to run on my Gentoo GNU/Linux machine. I don't really care
about Mac OSX or Windows. That's probably the wrong attitude. I guess if SBCL
runs there I'll make the effort to ensure that it works. Right now I just want
to get something off the ground. I mean in the end we're talking about Common
Lisp aka we're not talking about programming in assembly, heh.


If anyone knows why this is a terrible idea I'm all ears. I feel like I'm in
uncharted waters most of the time.

Brandon

-- 
Brandon Edens                                   brandon at cs.uri.edu
http://www.brandonedens.org
key 0x55438F48
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/lmud-devel/attachments/20070309/4f4586e3/attachment.sig>