(defclass thing ()
((name :accessor name
:initarg :name
:initform "unnamed thing")))
(defclass person (thing)
((name :initform "unnamed person")))
(defclass place (thing)
((name :initform "unnamed place")
(description :accessor description
:initarg :description
:initform "generic place description")
(exits :accessor exits)))
(defun make-thing (name)
(make-instance 'thing :name name))
(defun make-person (name)
(make-instance 'person
:name name))
(defun make-place (name description)
(make-instance 'place :name name
:description description))
(setf rock (make-thing "rock"))
(setf david (make-person "david"))
(setf startroom (make-place "startroom" "a very nice room indeed"))
here is my latest attempt to write an adventure type game.
before i introduce any more bugs i hope to get more input
from comp.lang.lisp geniuses. because they are the smartest,
friendliest, best looking geniuses of all the usenet. :)
david wrote:
> (defclass thing ()
> ((name :accessor name
> :initarg :name
> :initform "unnamed thing")))
>
> (defclass person (thing)
> ((name :initform "unnamed person")))
>
> (defclass place (thing)
> ((name :initform "unnamed place")
> (description :accessor description
> :initarg :description
> :initform "generic place description")
> (exits :accessor exits)))
>
> (defun make-thing (name)
> (make-instance 'thing :name name))
>
> (defun make-person (name)
> (make-instance 'person
> :name name))
>
> (defun make-place (name description)
> (make-instance 'place :name name
> :description description))
>
> (setf rock (make-thing "rock"))
> (setf david (make-person "david"))
> (setf startroom (make-place "startroom" "a very nice room indeed"))
>
> here is my latest attempt to write an adventure type game.
> before i introduce any more bugs i hope to get more input
> from comp.lang.lisp geniuses. because they are the smartest,
> friendliest, best looking geniuses of all the usenet. :)
>
Check out
http://www.lisperati.com/casting.html
Wade
thanks, casting spels was one of my inspirations for this project.
it was recommended to me on this group to use clos. next i will
work on exits and doors with locks. i am just fishing for any kind
of suggestions.
thanks, david
david wrote:
> thanks, casting spels was one of my inspirations for this project.
> it was recommended to me on this group to use clos. next i will
> work on exits and doors with locks. i am just fishing for any kind
> of suggestions.
> thanks, david
>
You will not get such a blanket suggestion to use CLOS from me.
Sometimes you just need a symbol to represent something like a
"bucket". If you you go through something like Norvig's
Case Studies in CL you will see that some of the best code does
not use clos at all.
Also check out a Paul Graham essay at:
http://paulgraham.com/noop.html
I personally find that OO slows down the software development
cycle too much.
Wade
thanks. i have a copy of graham's ansi common lisp and i was saving up
for
a copy of paip. is case studies in cl more or less advanced than paip?
anyway, i am not married to objects. i started out with defstructs and
was applying what little new knowledge i've gained to my game.
eventually i hope to have the game characters exhibit self-awareness
and rule them by telnet ala sturgeon's "microcosmic god" :)
On Sat, 20 May 2006 14:46:59 GMT, Wade Humeniuk
<··················@telus.net> tried to confuse everyone with this
message:
>david wrote:
>> thanks, casting spels was one of my inspirations for this project.
>> it was recommended to me on this group to use clos. next i will
>> work on exits and doors with locks. i am just fishing for any kind
>> of suggestions.
>> thanks, david
>>
>
>You will not get such a blanket suggestion to use CLOS from me.
>Sometimes you just need a symbol to represent something like a
>"bucket". If you you go through something like Norvig's
>Case Studies in CL you will see that some of the best code does
>not use clos at all.
>
>Also check out a Paul Graham essay at:
>
>http://paulgraham.com/noop.html
>
>I personally find that OO slows down the software development
>cycle too much.
In this particular case, OO is the right choice. Inheritance is
absolutely needed here. The objects in adventure games generally follow
the similar rules, and there are natural classes of objects (rooms,
containers, people) that must follow a more wide set of rules. OO
(especially a good OO implementation, like CLOS) just fits too well to
discard it in search for some new approach.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
thanks, i was following your advice from a month or so ago. i checked
out lifp, it was too advanced for me. i found this on the web
http://www.cs.luc.edu/~pld/courses/372/fall04/adventure2.lisp
which is more the level i am aiming at right now. i am working
on understanding your code though. just very slowly. :)
Timofei Shatrov wrote:
>
> In this particular case, OO is the right choice. Inheritance is
> absolutely needed here. The objects in adventure games generally follow
> the similar rules, and there are natural classes of objects (rooms,
> containers, people) that must follow a more wide set of rules. OO
> (especially a good OO implementation, like CLOS) just fits too well to
> discard it in search for some new approach.
>
What was wrong with the lisperati.com approach?
http://www.lisperati.com/casting.html
Why is CLOS needed? The CLOS code posted by the OP is
about a third the length as the whole game given in the
tutorial and yet implements maybe 2% of the
functionality. How is that a good thing?
Wade
From: Paul Wallich
Subject: Re: newbie attempts to write adventure game, learn lisp
Date:
Message-ID: <e4o50o$6nv$1@reader1.panix.com>
Wade Humeniuk wrote:
> Timofei Shatrov wrote:
>
>>
>> In this particular case, OO is the right choice. Inheritance is
>> absolutely needed here. The objects in adventure games generally follow
>> the similar rules, and there are natural classes of objects (rooms,
>> containers, people) that must follow a more wide set of rules. OO
>> (especially a good OO implementation, like CLOS) just fits too well to
>> discard it in search for some new approach.
>>
>
> What was wrong with the lisperati.com approach?
>
> http://www.lisperati.com/casting.html
>
> Why is CLOS needed? The CLOS code posted by the OP is
> about a third the length as the whole game given in the
> tutorial and yet implements maybe 2% of the
> functionality. How is that a good thing?
The tutorial code is also (imo) hideously unmaintainable, since it uses
simmple lists with arbitrary structure to hold all of its data. For the
simplest possible adventure game this will be fine, but as soon as
things started getting complicated, you're going to forget where the
legal directions go versus the inanimate objects in the space versus the
animate objects versus the current lighting condition
and so on and so forth. Structs might do fine, but there's no reason
not to go with OO, certainly compared to referring to everything by
"first" and "second" with the occasional alist.
(I've seen the responses lower about cobbling together schemas by hand
and making engines that iterate through them, and it makes me itch to
think of extending that to taxonomies of any complexity -- which of
course is one of the reasons that OO got developed in the first place.)
paul
paul
Paul Wallich wrote:
>
> The tutorial code is also (imo) hideously unmaintainable, since it uses
> simmple lists with arbitrary structure to hold all of its data. For the
> simplest possible adventure game this will be fine, but as soon as
> things started getting complicated, you're going to forget where the
> legal directions go versus the inanimate objects in the space versus the
> animate objects versus the current lighting condition
> and so on and so forth. Structs might do fine, but there's no reason
> not to go with OO, certainly compared to referring to everything by
> "first" and "second" with the occasional alist.
>
> (I've seen the responses lower about cobbling together schemas by hand
> and making engines that iterate through them, and it makes me itch to
> think of extending that to taxonomies of any complexity -- which of
> course is one of the reasons that OO got developed in the first place.)
>
The largest taxonomies in the world are relational and contextual, not OO.
Therein lies the problem with OO, everything looks difficult because it
is rigid.
Wade
Wade Humeniuk <··················@telus.net> writes:
> The largest taxonomies in the world are relational and contextual,
> not OO.
Can you elaborate, or point to further reading?
--
Steven E. Harris
Steven E. Harris wrote:
> Wade Humeniuk <··················@telus.net> writes:
>
>> The largest taxonomies in the world are relational and contextual,
>> not OO.
>
> Can you elaborate, or point to further reading?
>
I can give some examples,
The Oxford English Dictionary (Words definitions based on other words)
The Maintenance Manual for the Space Shuttle
The sum of the Content and Hyperlinks of the WWW
The Database at Google that is behind the Search Engine (which I assume
is some kind of relational db).
The loose relationship of Scientific knowledge (Papers, Periodicals)
http://en.wikipedia.org/wiki/Relational_model
Wade
Wade Humeniuk <··················@telus.net> writes:
> I can give some examples,
I was thrown (or piqued) by the word "taxonomy", which I take to mean
classification: a way to group things, and the consideration of the
grouping system itself. Your examples bring to mind "catalog" or
maybe "directory", but neither a dictionary nor Google's search engine
offer much in the way of classification or grouping, at least as an
entry point.
I don't mean to argue with the importance of the relational model. I'm
just not sure I see how it addresses taxonomy (beyond the obvious set
membership and manipulation).
--
Steven E. Harris
"Steven E. Harris" <···@panix.com> writes:
> Wade Humeniuk <··················@telus.net> writes:
>
> > I can give some examples,
>
> I was thrown (or piqued) by the word "taxonomy", which I take to mean
> classification: a way to group things, and the consideration of the
> grouping system itself. Your examples bring to mind "catalog" or
> maybe "directory", but neither a dictionary nor Google's search engine
> offer much in the way of classification or grouping, at least as an
> entry point.
I tend to agree. None of those examples seems to fit in very well (or
at all) with traditional or scientific senses of the term "taxonomy".
I would say that generalization<=>specialization type classification
is at least a _necessary_ aspect for a taxonomy.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Steven E. Harris wrote:
> Wade Humeniuk <··················@telus.net> writes:
>
>> I can give some examples,
>
> I was thrown (or piqued) by the word "taxonomy", which I take to mean
> classification: a way to group things, and the consideration of the
> grouping system itself. Your examples bring to mind "catalog" or
> maybe "directory", but neither a dictionary nor Google's search engine
> offer much in the way of classification or grouping, at least as an
> entry point.
>
> I don't mean to argue with the importance of the relational model. I'm
> just not sure I see how it addresses taxonomy (beyond the obvious set
> membership and manipulation).
>
I was not happy using the word either, but the post I was responding to
was using the word in a way that means (to me) the broader sense of "knowledge"
and how to represent it and use it.
Wade
Actually I thought I would write about my experiences with real
world systems. Currently I have begun working again in the field
of Network Management Systems of Telco equipment. Switches and
such. About 15 years ago CMIP (an highly organized OO OSI standards based
approach was touted as the solution to the complexity of managing
Network Elements (NEs)). It came from a great effort to standardize
what an NE was and how to manage it. However
in these past 15 years, despite the best efforts of many to
implement it, it has failed to an ad-hoc "cobbled" together system
based around the TL1 protocol. TL1 is a free-form, text based
protocol, specified by each individual vendor, for each individual
piece of equipment they make. They follow some common and similar rules,
but... they all have their own slightly different solutions. This
"cobbled" together system is now used to manage millions of pieces
of equipment and billion of pieces of data. The CMIP OO protocol
failed, because OO in this case, was insufficient to classify what
and how a Telco network is and does. This is an example of a
man-made technical system that fails to fit within the OO
paradigm, it is not even close to being as complex human language.
So give me the ball of mud organic approach any day, its the only
game currently in town.
Wade
On Sat, 20 May 2006 20:28:35 GMT, Wade Humeniuk
<··················@telus.net> tried to confuse everyone with this
message:
>Timofei Shatrov wrote:
>
>>
>> In this particular case, OO is the right choice. Inheritance is
>> absolutely needed here. The objects in adventure games generally follow
>> the similar rules, and there are natural classes of objects (rooms,
>> containers, people) that must follow a more wide set of rules. OO
>> (especially a good OO implementation, like CLOS) just fits too well to
>> discard it in search for some new approach.
>>
>
>What was wrong with the lisperati.com approach?
>
It doesn't scale.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
david wrote:
> thanks, casting spels was one of my inspirations for this project.
> it was recommended to me on this group to use clos. next i will
> work on exits and doors with locks. i am just fishing for any kind
> of suggestions.
> thanks, david
>
Sitting down with my morning coffee and considering this issue a
little more, it seems apparent to me that this need psychological need
to use clos and OO in general is the same as the current (and
recurring) desire for standards. Its like nothing can happen unless
there is "class" defined, within a hierarchy, well defined and
complete (though in all cases this OO completeness leads to
rigidity and a lack of creativity).
Wade
On Sat, 20 May 2006 15:43:02 +0000, Wade Humeniuk wrote:
>
> Sitting down with my morning coffee and considering this issue a
> little more, it seems apparent to me that this need psychological need
> to use clos and OO in general is the same as the current (and
> recurring) desire for standards. Its like nothing can happen unless
> there is "class" defined, within a hierarchy, well defined and
> complete (though in all cases this OO completeness leads to
> rigidity and a lack of creativity).
>
> Wade
Well, it's a small point, but eql specifiers don't suffer from this
problem. Getting even further away from the class hierarchy, support for
deftype types in generic functions would also be nice; though I realize
that this could potentially make dispatch very slow.
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
On Sat, 20 May 2006 15:43:02 GMT, Wade Humeniuk <··················@telus.net> wrote:
>
> david wrote:
> > thanks, casting spels was one of my inspirations for this project.
> > it was recommended to me on this group to use clos. next i will
> > work on exits and doors with locks. i am just fishing for any kind
> > of suggestions.
> > thanks, david
> >
>
> Sitting down with my morning coffee and considering this issue a
> little more, it seems apparent to me that this need psychological need
> to use clos and OO in general is the same as the current (and
> recurring) desire for standards. Its like nothing can happen unless
> there is "class" defined, within a hierarchy, well defined and
> complete (though in all cases this OO completeness leads to
> rigidity and a lack of creativity).
Pro and con debate here:
http://www.dreamsongs.com/ObjectsHaveFailedNarrative.html
http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html
Personally, I'm an OO fan, but I try to approach it less
from a "classes �ber alles" perspective and more from a
protocols perspective in which there is usually still a
class hierarchy but it's a partner. I think CLOS facilitates
this approach fairly well, which is one of the reasons why
I like CLOS so much.
--
Jack Unrue
Jack Unrue wrote:
>
> Pro and con debate here:
>
> http://www.dreamsongs.com/ObjectsHaveFailedNarrative.html
> http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html
>
> Personally, I'm an OO fan, but I try to approach it less
> from a "classes �ber alles" perspective and more from a
> protocols perspective in which there is usually still a
> class hierarchy but it's a partner. I think CLOS facilitates
> this approach fairly well, which is one of the reasons why
> I like CLOS so much.
>
Thank you for the links. I found the pro article by Steele to
unconvincing. I personally do use CLOS some of the time, but
I am never happy with the outcome. I have had a much
better time either representing objects as lists (alists,
plists) and writing "engines" which understand the semantics
of the descriptions/objects. These "classes" are much more flexible and
not subject to breakage if they contain more or less information than
the methods need.
Some examples are:
(define-volunteer
`((personal-information
last-name
first-name
contact-method
day-phone
eve-phone
cell-phone
email1
email2
special-skills)
(interests
(school
recycling talent/-skills school-library lost-and-found building-projects phys-ed-events
phys-ed-phoning art-and-drama-after-school school-adhoc)
(committees
transport parking practicum info-evenings wellness recyling cop-ski-lessons committe-adhoc)
(council
council-position phone-fan-out data-input council-adhoc hot-lunch-coordinator
hot-lunch-distributor)
(fundraising
qsp-coordinator calendar-coordinator calendar-helper
fundraising-class-rep
bottle-drive-helper
spring-fling-coordinator
spring-fling-setup-takedown
spring-fling-helper
spring-fling-donation-finder
casino-june/2006
fundraising-adhoc)
(events
breakfast-coordinator breakfast-helper
skating-party-coordinator skating-party-helper
sports-day-helper
teachers-luncheon-coordinator teachers-luncheon-helper
information-evening-host information-evening-helper
special-event-coordinator special-event-helper
events-adhoc))))
--- or ---
(defparameter *knowledge-base*
'((pmbok-guide (concept reference)
(title "A Guide to the Project Management Body of Knowledge")
(version "1.5")
(edition "2000"))
(process-groups (member initiating planning executing controlling closing))
(core-process (member initiation project-plan-development project-plan-execution
integrated-change-control
scope-planning scope-definition activity-definition
activity-sequencing
activity-duration-estimating schedule-development resource-planning
cost-estimating cost-budgeting risk-management-planning
performance-reporting
administrative-closure contract-closeout))
(facilitating-process (member scope-verification scope-change-control
schedule-control cost-control
quality-planning quality-assurance quality-control
organizational-planning
staff-acquisition team-development communications-planning
information-distribution risk-identification
qualitative-risk-analysis
quantitative-risk-analysis risk-response-planning
risk-monitoring-and-control procurement-planning
solicitation-planning
solicitation source-selection contract-administration))
(project-integration-management
(concept project-management-knowledge-area)
(references (pmbok-guide (section "4.")))
(processes project-plan-development
project-plan-execution
integrated-change-control))
(project-scope-management
(concept project-management-knowledge-area)
(references (pmbok-guide (section "5.")))
(pmbok-section "5.")
(processes initiation scope-planning scope-definition
scope-verification scope-change-control))
(project-time-management
(concept project-management-knowledge-area)
(references (pmbok-guide (section "6.")))
(pmbok-section "6.")
(processes activity-definition activity-sequencing activity-duration-estimating
schedule-development schedule-control))
.....
Wade
On Sat, 20 May 2006 20:39:43 GMT, Wade Humeniuk <··················@telus.net> wrote:
>
>Thank you for the links. I found the pro article by Steele to
>unconvincing. I personally do use CLOS some of the time, but
>I am never happy with the outcome. I have had a much
>better time either representing objects as lists (alists,
>plists) and writing "engines" which understand the semantics
>of the descriptions/objects. These "classes" are much more flexible and
>not subject to breakage if they contain more or less information than
>the methods need.
>
>Some examples are:
>(define-volunteer
> `((personal-information
> last-name
> first-name
> contact-method
> day-phone
> eve-phone
> cell-phone
> email1
> email2
> special-skills)
>
> [snip the rest]
OK, sure, I see how this could work.
Now let's say we also have the concept of administrator, so there
would also be a define-administrator form, right? The contact info
for both volunteers and administrators could be represented using
the exact same attributes (cf. personal-information above). Would
you duplicate that piece or is there some way the schema could be
shared?
Or would you push both of those concepts down and replace
define-volunteer with something like define-person which
has attributes for both kinds of people?
--
Jack Unrue
Jack Unrue wrote:
> On Sat, 20 May 2006 20:39:43 GMT, Wade Humeniuk <··················@telus.net> wrote:
>> Thank you for the links. I found the pro article by Steele to
>> unconvincing. I personally do use CLOS some of the time, but
>> I am never happy with the outcome. I have had a much
>> better time either representing objects as lists (alists,
>> plists) and writing "engines" which understand the semantics
>> of the descriptions/objects. These "classes" are much more flexible and
>> not subject to breakage if they contain more or less information than
>> the methods need.
>>
>> Some examples are:
>> (define-volunteer
>> `((personal-information
>> last-name
>> first-name
>> contact-method
>> day-phone
>> eve-phone
>> cell-phone
>> email1
>> email2
>> special-skills)
>>
>> [snip the rest]
>
> OK, sure, I see how this could work.
>
> Now let's say we also have the concept of administrator, so there
> would also be a define-administrator form, right? The contact info
> for both volunteers and administrators could be represented using
> the exact same attributes (cf. personal-information above). Would
> you duplicate that piece or is there some way the schema could be
> shared?
>
> Or would you push both of those concepts down and replace
> define-volunteer with something like define-person which
> has attributes for both kinds of people?
>
As an aside its funny that you refer to the volunteer as a form.
This is exactly how this schema is primarily used, to dynamically create
HTML based forms and read back the information into a volunteer
database. To change the HTML form I just change the above a-tree, which
causes changes in the form and the database (in which volunteers are
just stored as property lists).
To answer your point if I needed an administrator type and that
general type of inheritance structure I would probably create a
"knowledge base" that describes things like addresses, volunteers and
administrators. Much like Norvig's natural language example in PAIP.
There grammars are loosely defined patterns of sentences, with nouns,
verbs, etc.
(just to note some problems with inheritance might be that administrators
may or may not be volunteers, and might not even be people, though they
probably are).
I understand the desire and possible unavoidable need to create some
kind of classification system. After all, computing in its current form
is pedantic and hopelessly bogged down in detail.
Wade
On Sat, 20 May 2006 21:42:37 GMT, Wade Humeniuk <··················@telus.net> wrote:
>
> (just to note some problems with inheritance might be that administrators
> may or may not be volunteers, and might not even be people, though they
> probably are).
Yep. This would make a good interview question :-)
--
Jack Unrue
david wrote:
> (defclass thing ()
> ((name :accessor name
> :initarg :name
> :initform "unnamed thing")))
>
> (defclass person (thing)
> ((name :initform "unnamed person")))
>
> (defclass place (thing)
> ((name :initform "unnamed place")
> (description :accessor description
> :initarg :description
> :initform "generic place description")
> (exits :accessor exits)))
>
> (defun make-thing (name)
> (make-instance 'thing :name name))
>
> (defun make-person (name)
> (make-instance 'person
> :name name))
>
> (defun make-place (name description)
> (make-instance 'place :name name
> :description description))
>
> (setf rock (make-thing "rock"))
> (setf david (make-person "david"))
> (setf startroom (make-place "startroom" "a very nice room indeed"))
>
> here is my latest attempt to write an adventure type game.
> before i introduce any more bugs i hope to get more input
A few comments:
- The "unnamed something" initforms probably don't buy you a lot. I
would recommend either to leave them out, in which case you get an
exception when you try to read an uninitialized slot, or I would rather
say :initform (error "Name this thing."), in which case you are forced
to initialize such a slot when you create an instance.
- The accessor for exists should be existsp - it's idiomatic to end
predicates in p.
- The make-xyz functions are probably overkill. It doesn't buy you a lot
to wrap make-instance calls like that.
- I hope the setf forms are not at top level, but you have introduced
the respective variables before. Otherwise you are invoking undefined
behavior here, as per ANSI Common Lisp.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
thanks for your comments. exits was going to be a list like (north door
locked garden)
as for my setf forms, should i change them to defparameters? should i
use a let?
my limited understanding is that i can create a lexical env. using let.
i am going to
have lots of things persons and places. how would they all be able to
interact?
as for my make-xyz functions and initforms i am just trying out new
stuff as
my goal is to learn lisp as well as make an adventure game.
On 20 May 2006 08:41:19 -0700, "david" <·····@earthlink.net> tried to
confuse everyone with this message:
>thanks for your comments. exits was going to be a list like (north door
>locked garden)
>as for my setf forms, should i change them to defparameters? should i
>use a let?
You should probably use defparameter, because these are basically global
variables. let is for temporary bindings - as soon as you leave its
lexical environment the object would be lost forever.
>as for my make-xyz functions and initforms i am just trying out new
>stuff as
>my goal is to learn lisp as well as make an adventure game.
I think it's a reasonable way to learn Lisp, because it worked for me.
You can see my result at http://common-lisp.net/project/lifp/.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|