Langband v0.1 released
Stig E. Sandoe
[apparently the first announce didn't make it out, I try again]
After a long and rocky road it has finally come to pass:
Langband v0.1 is now released.
Langband is the lispier Angband alternative, and is known to work on
Common Lisp systems on Linux and Unix. It is a concept release
showing the roguelike community that it's a project on the right
track, and that it is soon approaching the high standards set by
Angband v3.0.
The release is a concept release, and may miss some of the advanced
features. What it does have is:
- Graphical tiles for X11, *including* images.
Images is a feature not found in any other angband variant.
See <URL: http://www.langband.org/screenshots.html>
- Most commands (eat, drop, drink, pick up, read, zap wands, ...
- Basic fighting and basic spells
- Most common objects with effects
- Doors, traps, corridors and rooms in the dungeon
- Aggressive monsters and nasty combat attacks by monsters.
- Bows, wands, staves and rods and a fireball for your enemies.
- Simple stores, a simple home and quick to create a character.
More info about features and missing features may be found on the
Langband website at <URL: http://www.langband.org/>
Information about downloading it for a go:
<URL: http://www.langband.org/download.html>
Questions and feedback is appreciated. Either mail st...@langband.org
or ask on the newsgroup rec.games.roguelike.angband
--
------------------------------------------------------------------
Stig E Sandoe st...@langband.org
Leon Marrick
"Stig E. Sandoe" wrote:
>
> [apparently the first announce didn't make it out, I try again]
>
> After a long and rocky road it has finally come to pass:
>
> Langband v0.1 is now released.
>
>
> Langband is the lispier Angband alternative, and is known to work on
> Common Lisp systems on Linux and Unix. It is a concept release
> showing the roguelike community that it's a project on the right
> track, and that it is soon approaching the high standards set by
> Angband v3.0.
Please tell us about the advantages of porting the game to Common
Lisp. I've actually visited your website once or twice, and
never quite understood the "why". Of course, the fact that I'm
totally ignorant of Lisp might have something to do with this. :-)
Brother Elf
>>>>> "LM" == Leon Marrick <leo...@sprintmail.com> writes:
[...]
> Please tell us about the advantages of porting the game to Common
> Lisp. I've actually visited your website once or twice, and
> never quite understood the "why". Of course, the fact that I'm
> totally ignorant of Lisp might have something to do with this. :-)
There is now, apparently, a nethack mode for emacs. We can't lag
behind there, now can we?
Br Elf,
(ESC ESC t M-C-d) and not entirely serious
--
Which signature do you want to use today?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
http://www.usenet.com
Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Stig E. Sandoe
I am not sure about how to answer here, or more specifically;
how to provide a simple persuasive list of advantages that
will provide the reader with an Eureka-feeling.
I doubt I can do that, but I'll try to list some reasons that
makes sense to me. If I do not answer the implied question,
please don't hesitate to ask again. (Details and discussion
about single reasons can be done via private email)
Some reasons that makes sense to me on good days:
- Langband implements an engine-like model, which allows
a developer to "plug in" a variant and customise most
aspects. This allows a developer to use updates to the
engine and new features directly, without making a big
code-split with plenty of patching.
The variant designer can (mostly) use script-like and
high-level language to do operations and customisation,
e.g if you need to upgrade energy of monsters in the
current dungeon:
(with-dungeon-monsters (dungeon mon)
(incf (get-creature-energy mon) (energy-for-speed mon)))
This example increases the monster's energy with energy
appropriate to the monster's speed.
- The engine-like model requires a high-level language that
allows you access to most of the underlying functionality.
Allowing only a small subset of the functionality for
scripting (which is common for engines) you also restrict
the actual customisability and extendability. Using a
clear separation of scripting from the engine makes this
a lot of work.
The advantage of Lisp is that:
a) There is no clear separation of scripting and programming,
but instead it allows both very high-level scripting and
access to low-level stuff (when you need it). The access
is gradual and the variant designer has full rights to
decide what is right for his variant, not the engine writer.
While lua has many good aspects and I welcome the use of lua
in angband, it is still not integrated enough as I see it.
Lisp compilers allows you to compile the lisp-code down to
native code (when you want it to) and the speed is comparable
to C++, which is far better than scripting.
b) Lisp is a full object-oriented language and also inherit a
lot from the functional tradition, giving the variant designer
a well-developed and full language for his needs (when he or
she needs it). There is no ad-hoc scripting language or
limited assembly language, but a complete language.
c) Lisp allows you to treat data as code and code as data. While
that may sound like an academic exercise, it is quite useful,
allowing the variant designer e.g to keep code and data for
objects in the same place:
(define-object-kind "wand-frost-bolt" "frost bolts"
:numeric-id 271
:x-attr #\d
:x-char #\-
:depth 20
:rarity 0
:chance #(1 0 0 0)
:locale #(20 0 0 0)
:weight 10
:cost 800
:sort-value 4819
:the-kind '<wand>
:on-add-magic (magic-add (item depth status)
(add-charges! item (+ (randint 5) 6)))
:on-zap (object-effect (dungeon player item)
(van-fire-bolt-or-beam! player 20 (get-aim-direction)
(get-spell-effect '<cold>)
(roll-dice 6 8))
(possible-identify! player item)
:still-useful))
Note also that the actual language provided by the engine
is tailoured to the needs, e.g define-object-kind, object-effect,
magic-add and as we saw above with-dungeon-monsters
- A common myth about Lisp is that it is interpreted. The reality
is that the langband code is compiled to native code, just like
a C or C++ compiler. In addition, the language is interactive,
allowing me (or a variant designer) to add code, tweak code and
adjust code while it is running... which is an excellent way to
experiment and debug the code.
Of course, there are other less technical reasons, and I'll admit
any day that it is a crazy project.
And I'll even admit to some of the problems:
- Lisp is often considered weird and it is a language that is
haunted by myths. There are a lot more C-programmers than
people who know Lisp. Some people have problems with the
syntax, and others do not believe in interactive programming.
- Lisp-compilers are typically not installed on most systems.
Luckily it is trivial to find one for *nix systems and to
get langband running on most new Linux-systems can be done
quickly. Windows systems are more problematic, and
Langband v0.1 is not recommended on windows unless you're
a serious lisper.
And now for the morale:
-----------------------
It mostly boils down to two things I think:
- Is the variant any fun
- Is it fun to develop
We still don't know if I can do the first, but I hope so.
Any other questions?
--
------------------------------------------------------------------
Stig E Sandoe st...@ii.uib.no http://www.ii.uib.no/~stig/
Matthias Kurzke
> The advantage of Lisp is that:
>
> c) Lisp allows you to treat data as code and code as data. While
> that may sound like an academic exercise, it is quite useful,
> allowing the variant designer e.g to keep code and data for
> objects in the same place:
>
>(define-object-kind "wand-frost-bolt" "frost bolts"
> :numeric-id 271
> :x-attr #\d
> :x-char #\-
> :depth 20
> :rarity 0
> :chance #(1 0 0 0)
> :locale #(20 0 0 0)
> :weight 10
> :cost 800
> :sort-value 4819
> :the-kind '<wand>
> :on-add-magic (magic-add (item depth status)
> (add-charges! item (+ (randint 5) 6)))
>
> :on-zap (object-effect (dungeon player item)
> (van-fire-bolt-or-beam! player 20 (get-aim-direction)
> (get-spell-effect '<cold>)
> (roll-dice 6 8))
> (possible-identify! player item)
> :still-useful))
>
This is really great -- I assume all structures work like this, and all
data can be sorted in this way? That way it will be almost trivial to add
any 'special-cased' monsters/objects/etc., which in the current lua model
requires changes to script files AND 'data files' AND source files. Keeping
the relevant information together like you do here is what I feel it should
be like. (For this reason, I hope the *_info.txt files will all be removed
and replaced by lua scripts, which should give a similar clarity, but
(unfortunately) interpreted only).
Matthias
Kornel "Anubis" Kisielewicz
news:87d6rab...@palomba.bananos.org...
>
> [apparently the first announce didn't make it out, I try again]
>
> After a long and rocky road it has finally come to pass:
>
>
> Langband v0.1 is now released.
Ugh, just as a little comment, the links section on your page has the
outdated RogueLike News site link -- Roguelike News is Dead. Instead
we have a site named YARNS :: Roguelike News (
http://yarns.felis7.civ.pl ) that took over it's place :).
regards,
--
Kornel "Anubis" Kisielewicz ( kis...@fulbrightweb.org )
GenRogue cRPG/Rogue-like Project ( http://genrogue.felis7.civ.pl/ )
YARNS :: Roguelike News ( http://yarns.felis7.civ.pl )
"hominem non odi, sed eius vitia"
Stig E. Sandoe
Yes.
> That way it will be almost trivial to add any 'special-cased'
> monsters/objects/etc., which in the current lua model requires
> changes to script files AND 'data files' AND source files. Keeping
> the relevant information together like you do here is what I feel it
> should be like. (For this reason, I hope the *_info.txt files will
> all be removed and replaced by lua scripts, which should give a
> similar clarity, but (unfortunately) interpreted only).
Yes, as far as possible the code and data should be kept together
as it makes debugging and development much easier. It also makes it
easy to spot (either automatically or by eye) which parts are
unimplemented. Another nice point is that no #define/flag or
separate id is needed to dispatch on the object, ie less clutter.
I don't think that for most objects it will be a problem if it is
interpreted; for the data (depth, rarity, ...) it doesn't matter,
and the add-magic/zap code is not called very often. The exception
might e.g be weapons or spells that are used frequently (magic
missile, lightning bolt, healing).
William Tanksley Google
> "Stig E. Sandoe" wrote:
> > After a long and rocky road it has finally come to pass:
> > Langband v0.1 is now released.
> Please tell us about the advantages of porting the game to Common
> Lisp. I've actually visited your website once or twice, and
> never quite understood the "why". Of course, the fact that I'm
> totally ignorant of Lisp might have something to do with this. :-)
"Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp." (As quoted in
http://www.paulgraham.com/quotes.html, which also contains an amusing
statement about the Tenth Rule.)
The nice thing about Lisp is that it, unlike C, is a high-level
language. It not only gives you libraries to help you do things (and
Common Lisp does, many many more than C); it allows you to mold the
language to fit what you need to do. If you want to describe monsters,
you don't need to write a parser to read in monster files; just modify
Lisp to be suitable for reading in monster data. If you want to
iterate, write a little iteration language (the LOOP macro, part of
Common Lisp, is such a language).
I haven't seen LAngband's source. I hope to see it soon.
-Billy
DarkGod
> This is really great -- I assume all structures work like this, and all
> data can be sorted in this way? That way it will be almost trivial to add
> any 'special-cased' monsters/objects/etc., which in the current lua model
> requires changes to script files AND 'data files' AND source files. Keeping
> the relevant information together like you do here is what I feel it should
> be like. (For this reason, I hope the *_info.txt files will all be removed
> and replaced by lua scripts, which should give a similar clarity, but
> (unfortunately) interpreted only).
Uh ? since when is lua interpreted ? it IS compiled, to bytecode yes, but
it is compiled.
Doing that in lua is very easy, for the brand new stuf I added(spells,
powers, whatever) I do it all in lua, data&code mixed, it is clean & easy.
--
-----------------------+----------------------------------------------
DarkGod comes from | Do not meddle in the affairs of wizards
the hells for YOU ! :) | because they are subtle and quick to anger.
-----------------------+----------------------------------------------
Pe W Olorin YSo L:50 DL:696 A+++ R+++ Sp++ w:Mage Staff of Mana(240%)
Pe*/PM*(Cr) D H- D c++ f- PV s- TT- d++ P++ M+ C- S++ I+++ So++ B/-
ac- GHB- SQ+ RQ V+++ F:Mage playing Mage-like(see Pernangband Sorcerors)
pelpel
> "Greenspun's Tenth Rule of Programming: any sufficiently
> complicated C or Fortran program contains an ad hoc
> informally-specified bug-ridden
> slow implementation of half of Common Lisp." (As quoted in
> http://www.paulgraham.com/quotes.html, which also contains an amusing
> statement about the Tenth Rule.)
>
> The nice thing about Lisp is that it, unlike C, is a high-level
> language. It not only gives you libraries to help you do things (and
> Common Lisp does, many many more than C); it allows you to mold the
> language to fit what you need to do. If you want to describe monsters,
> you don't need to write a parser to read in monster files;
> just modify Lisp to be suitable for reading in monster data.
> If you want to iterate, write a little iteration language
> (the LOOP macro, part of Common Lisp, is such a language).
More on this. As Paul Graham says, Lisp is a programmable
programming language. If one doesn't like something, one
can do whatever s/he likes to it's syntax, read/compile/loading
time behaviour etc. For example, if you feel the LOOP too
complicated and are more inclined to the functional style
(like me (^ ^;), a couple of lines of macro will do.
Actually CLOS is implemented this way (mostly macros).
You can even introduce various forms of infix syntax,
if you really hate parantheses...
Anyway, Congratulations to Fufie :)
> -Billy
// pelpel (pel...@zak.att.ne.jp)
DarkGod
> More on this. As Paul Graham says, Lisp is a programmable
> programming language. If one doesn't like something, one
> can do whatever s/he likes to it's syntax, read/compile/loading
Can you get rid of it's parenthesis and make it looks like lua? ;)
R Dan Henry
(pelpel) declared:
>More on this. As Paul Graham says, Lisp is a programmable
>programming language. If one doesn't like something, one
>can do whatever s/he likes to it's syntax, read/compile/loading
>time behaviour etc.
Doesn't this make it difficult to work on someone else's Lisp code?
R. Dan Henry, Emperor of the Universe
Is an Earth Hound at 4950' a low-down dirty dog?
Hallvard B Furuseth
>> More on this. As Paul Graham says, Lisp is a programmable
>> programming language. If one doesn't like something, one
>> can do whatever s/he likes to it's syntax, read/compile/loading
>> time behaviour etc.
>
> Doesn't this make it difficult to work on someone else's Lisp code?
Very difficult if that code is not commented properly, or if the code is
overly complex just for the joy of using overly complex constructs.
Otherwise it's no big deal.
Anyway, i've found it difficult to hack current Angband code for the
same reason: Not enough documentation. So what's the difference?
--
Hallvard
DarkGod
the source is quote well commented IMO, thanks to ben.
Hallvard B Furuseth
> the source is quote well commented IMO, thanks to ben.
Yes, lots of comments on low-level stuff. Less on higher level
structures and so on.
--
Hallvard
William Tanksley Google
[on Lisp:]
> Can you get rid of it's parenthesis and make it looks like lua? ;)
You can get rid of its parentheses and make it look like anything you
want. Many people have; there are very sophisticated add-ons to do
just that, and it's all part of standard Lisp.
The problem is that it's all an utter and complete waste of time. None
of the proposed syntaxes, with the single exception of the
indentation-based syntax (like Python) actually reduces the
parenthesis count; they simply move parentheses around, into places
where people who don't know Lisp more commonly expect to see them.
The problem with that is that the people who don't know Lisp are wrong
about parentheses; they thought they were the only things stopping
them from understanding Lisp, but actually there are many things in
Lisp different from their other languages, and they just didn't
notice.
If you want to program in Lisp, you need to learn Lisp.
> DarkGod comes from | Do not meddle in the affairs of wizards
-Billy
DarkGod
> If you want to program in Lisp, you need to learn Lisp.
Keep cool I was only joking :)
You know I'm a lua monk that's all :)
--
-----------------------+----------------------------------------------
DarkGod comes from | Do not meddle in the affairs of wizards
pelpel
In article <65rpououhc37vhi0f...@4ax.com>, R Dan Henry wrote:
>On 21 Sep 2002 01:58:43 -0700, in a fit of madness ka...@sta.att.ne.jp
>(pelpel) declared:
>
>>More on this. As Paul Graham says, Lisp is a programmable
>>programming language. If one doesn't like something, one
>>can do whatever s/he likes to it's syntax, read/compile/loading
>>time behaviour etc.
>
>Doesn't this make it difficult to work on someone else's Lisp code?
It can... Well, the justification for this is given in a famous
textbook:
"... as we confront increasingly complex problems, we will find that
Lisp, or indeed any fixed programming language, is not sufficient
for our needs. We must constantly turn to new languages in order
to express our ideas more effectively. Establishing new languages
is a powerful strategy for controlling complexity in engineering
design; we can often enhance our ability to deal with a complex
problem by adopting a new language that enables us to describe
(and hence to think about) the problem in a different way, using
primitives, means of combination, and means of abstraction that
are particularly well suited to the problem at hand."
("Structure and Interpretation of Computer Programs", Chapter 4,
Metalinguistic Abstraction)
I should take this to mean I should be over-enthusiastic about
any single programming language. There's no such thing like
The One Language to Rule Them All :)
Regards,
>R. Dan Henry, Emperor of the Universe
// pelpel (pel...@zak.att.ne.jp)
pelpel
In article <slrnankthh...@localhost.my.domain>, pelpel wrote:
>
>I should take this to mean I should be over-enthusiastic about
^^^^^^
>any single programming language.
I meant to say "I shouldn't" (^ ^;)
Regards,
// pelpel (pel...@zak.att.ne.jp)