Definition of roguelike
Kalle Pahajoki
always though it was the character based graphics, but someone mentioned
Nahlak as roguelike. So is it?
What features are most important in a roguelike game? Is there an official
definition of 'roguelike'?
I am interested in this stuff because I'm coding a roguelike game for Casio
(mine is 9950g) calculators and have been thinking of the features it should
have. The environment is very limited so I can't just make a copy of angband.
--
___ _____ ,---------------------------------------------------.
/ _ \/ ___/ / Kalle Pahajoki <paha...@voimax.cygnnet.jkl.fi> /
/ ___/ /__ / Proud member of the Pahajoki Collective /
/_/ \___/ `--------------------------------------------------'
G Masonic
(Kalle Pahajoki) whispered to Solomon:
>What is required of a game so that it can be called a roguelike game? I
>always though it was the character based graphics, but someone mentioned
>Nahlak as roguelike. So is it?
>What features are most important in a roguelike game? Is there an official
>definition of 'roguelike'?
Something like the game "rogue". IF enough people agree it is
roguelike, it is roguelike.
The question is a little like "What is blue?" Well, it's blue if
enough people agree to call that particular wavelength of light blue.
I would not hold up 'character-based graphics' as a defining point.
Is it more a flavor of game than a strict
it-has-this-and-this-so-it-is.
-----
Go to:
www/11thhourradioshow.com
or die.
Drakmere
only REALLY unifying factor.
--
(All quotes are not guaranteed accurate.)
ICQ: 8869737 Yahoo: Drakmere Aim: drakmere9
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvaldis claims to be trying to take over the world.
When in-laws are outlawed, only outlaws will have in-laws.
This .sig in UNDER CONSTRUCTION
Any suggestions are appreciated, and disposed of ;)
G Masonic
whispered to Solomon:
>In article <3624fd7c...@news.erols.com>, Freemason@Solomon's.Temple (G Masonic) babbled thusly:
>>After giving the secret handshake, paha...@voimax.cygnnet.jkl.fi
>>(Kalle Pahajoki) whispered to Solomon:
>>>What is required of a game so that it can be called a roguelike game? I
>>>always though it was the character based graphics, but someone mentioned
>>>Nahlak as roguelike. So is it?
>>>What features are most important in a roguelike game? Is there an official
>>>definition of 'roguelike'?
>>
>>Something like the game "rogue". IF enough people agree it is
>>roguelike, it is roguelike.
>>
>>The question is a little like "What is blue?" Well, it's blue if
>>enough people agree to call that particular wavelength of light blue.
>>
>>I would not hold up 'character-based graphics' as a defining point.
>>Is it more a flavor of game than a strict
>>it-has-this-and-this-so-it-is.
>I think to be rogue-like it has to be an RPG with one PC. That seems to be the
>only REALLY unifying factor.
I disagree. Randomization is the only real unifying theme.
-----
Go to:
www.11thhourradioshow.com
or die.
jwk
And I'm tempted to say that as long as it's got to do with fighting,
single or in very small groups, with characters from different
classes, different races, different stats, who learn along the way,
it's roguelike enough for me. This may also include a lot of
adventures, I know.
Flame on!
Jurriaan
I never think, sir. Didn't get a degree.
Chief Inspector Morse
Drakmere
sure it "rogue-like"
Remco Gerlich
>What is required of a game so that it can be called a roguelike game? I
>always though it was the character based graphics, but someone mentioned
>Nahlak as roguelike. So is it?
>What features are most important in a roguelike game? Is there an official
>definition of 'roguelike'?
>
>(mine is 9950g) calculators and have been thinking of the features it should
>have. The environment is very limited so I can't just make a copy of angband.
>
had and that most of the games that people commonly call Roguelike have,
and then decide for yourself which are essential and which aren't...
Some features that Rogue and *most* roguelikes have (there are important
exceptions to most of these): The player walks around in a dungeon,
going down, where the dungeon gets harder and harder, to some goal deep
down. The dungeon is "discrete and 2D", that is, a dungeon level consist
of a grid of squares; if one monster/player is in a square, there can't
be any more. The dungeon is displayed using ASCII characters. The
commands are simple, 1 character, sometimes with a single parameter. The
player's inventory labels items with characters to identify them.
Players can use equipment of fixed types, like 1 weapon 1 body armour 1
cloak 1 pair of boots and 1 pair of gloves (for example). There are
things like "potions" and "scrolls" that can be quaffed or read to get a
one-time magical effect. There are wands and staves to get an effect
multiple times. If you want to attack an adjacent monster, you move into
it. Randoms play a large role; in deciding the outcome of events, and
for the way the dungeon looks, so that it's different each time you
play. You can save, but it'll kick you out of the game - if you die, you
die. Types of potion/scroll/etc get random names at the beginning of the
game; if you've identified a type, you recognize the others of that
type.
(pretty random order, written down from the top of my head).
You can decide for yourself what you think is essential... For instance,
graphics are now available in many roguelikes. I could accept a game
without potions and scrolls as a roguelike, but without the discrete 2D
random world and the 1-char commands it'd be hard...
--
Remco Gerlich scarblac at dds dot nl
Aidan Ryder
<scar...@dds.nl> writes
>paha...@voimax.cygnnet.jkl.fi (Kalle Pahajoki) wrote:
>>What is required of a game so that it can be called a roguelike game? I
>>always though it was the character based graphics, but someone mentioned
>>Nahlak as roguelike. So is it?
>>What features are most important in a roguelike game? Is there an official
>>definition of 'roguelike'?
>>
>>I am interested in this stuff because I'm coding a roguelike game for Casio
>>(mine is 9950g) calculators and have been thinking of the features it should
>>have. The environment is very limited so I can't just make a copy of angband.
>>
>Well, there's no clear line. But you can look at the features that Rogue
>had and that most of the games that people commonly call Roguelike have,
>and then decide for yourself which are essential and which aren't...
>
>
>(pretty random order, written down from the top of my head).
>
>You can decide for yourself what you think is essential... For instance,
>graphics are now available in many roguelikes. I could accept a game
>without potions and scrolls as a roguelike, but without the discrete 2D
>random world and the 1-char commands it'd be hard...
>
>
>--
>Remco Gerlich scarblac at dds dot nl
Diablo?
--
Aidan Ryder -- http://members.tripod.com/~Aidan_Ryder/Start.htm
"Two parts apathy, one part despair" - NOFX
Remco Gerlich
>In article <6vqrrl$ok1$1...@info.service.rug.nl>, Remco Gerlich
><scar...@dds.nl> writes
>>
>>
>>(pretty random order, written down from the top of my head).
>>
>>You can decide for yourself what you think is essential... For instance,
>>graphics are now available in many roguelikes. I could accept a game
>>without potions and scrolls as a roguelike, but without the discrete 2D
>>random world and the 1-char commands it'd be hard...
>>
>>
>Diablo?
Ah - the expected answer. Diablo is probably on the edge. Its dungeons
are 2D, but lack the "squares" part - monsters (and players) can move
pretty continuously between spots - they can move halfway to some other
location, and then change directions... The interface is quite different
from the traditional Roguelike. You can save, and just continue, to
backup, as if nothing happened. But, because of the random dungeons, the
replay value is there (there are artifacts that are dropped randomly as
in Angband as well, right? I'm not sure).
Personally, I don't consider Diablo to be a Roguelike, even though I
*do* consider it to be an Angband-ripoff. It's just not a game "like
Rogue", like Angband, Nethack, Moria, Crawl, etc are. I do understand
that some people do consider it a Roguelike - as I said, "you can decide
for yourself what is essential", and Diablo obviously comes close.
[Disclaimer - I am drunk. I do believe in the intention of what's above,
but I may have posted it in an overly clumsy manner.]
Ted Douglas
>(Snip, whack, snip...)
>
>>: I personally think that defining what makes a game roguelike is
>>: impossible. I would myself consider Diablo to be roguelike (though a
>>: shallow one). You can point to several common themes, but you cannot
>>: really define it (sounds nice `n` spiritual huh?).
>
>>Not really hard...I think Diablo is the only game where there is really
>>question of its roguelike-ness. I myself say that even if it fits "the
>>rules" it made notty sacrafices to aim it at the QUAKE crowd. Roguers wear
>>their narrow game appeal like a badge of honor-so Diablo is out just
>>because we say so! Also it broke the theme-substance over presentation.
>
>(Whackety snip snip...)
>
>
>What about Caverns of Kroz? ZZT? Apshai? SSI's Dungeon Hack?
What about this obscure game for the Game Gear, whose name escapes
me at the moment? This game has a knight walking around randomly
generated dungeons whacking monsters, and also finds rods, potions and
spellbooks that can only be identified by using them, For instance,
a "yellow potion" or a "blue scroll" can have any of several effects.
Anyone know what game I'm talking about (I am sober<g>)?
/Ted Douglas
Aidan Ryder
<scar...@dds.nl> writes
>Aidan Ryder <Ang...@broomlee.demon.co.uk> wrote:
>>In article <6vqrrl$ok1$1...@info.service.rug.nl>, Remco Gerlich
>><scar...@dds.nl> writes
>>>
>><snip>
>>>
>>>(pretty random order, written down from the top of my head).
>>>
>>>You can decide for yourself what you think is essential... For instance,
>>>graphics are now available in many roguelikes. I could accept a game
>>>without potions and scrolls as a roguelike, but without the discrete 2D
>>>random world and the 1-char commands it'd be hard...
>>>
>>>
>
>>Diablo?
>
>Ah - the expected answer. Diablo is probably on the edge. Its dungeons
>are 2D, but lack the "squares" part - monsters (and players) can move
>pretty continuously between spots - they can move halfway to some other
>location, and then change directions... The interface is quite different
>from the traditional Roguelike. You can save, and just continue, to
>backup, as if nothing happened. But, because of the random dungeons, the
>replay value is there (there are artifacts that are dropped randomly as
>in Angband as well, right? I'm not sure).
>
>Personally, I don't consider Diablo to be a Roguelike, even though I
>*do* consider it to be an Angband-ripoff. It's just not a game "like
>Rogue", like Angband, Nethack, Moria, Crawl, etc are. I do understand
>that some people do consider it a Roguelike - as I said, "you can decide
>for yourself what is essential", and Diablo obviously comes close.
>
I personally think that defining what makes a game roguelike is
impossible. I would myself consider Diablo to be roguelike (though a
shallow one). You can point to several common themes, but you cannot
really define it (sounds nice `n` spiritual huh?).
[Disclaimer - I am sober. I do believe what I said above, but I am
probably wrong, I`ll read it again after I get stoned]
>[Disclaimer - I am drunk. I do believe in the intention of what's above,
>but I may have posted it in an overly clumsy manner.]
>
>--
>Remco Gerlich scarblac at dds dot nl
--
Timothy Meyers
: In article <6vu3hg$6vq$1...@info.service.rug.nl>, Remco Gerlich
Not really hard...I think Diablo is the only game where there is really
question of its roguelike-ness. I myself say that even if it fits "the
rules" it made notty sacrafices to aim it at the QUAKE crowd. Roguers wear
their narrow game appeal like a badge of honor-so Diablo is out just
because we say so! Also it broke the theme-substance over presentation.
-tim-
: [Disclaimer - I am sober. I do believe what I said above, but I am
Drakmere
>Aidan Ryder <Ang...@broomlee.demon.co.uk> wrote:
>>In article <6vqrrl$ok1$1...@info.service.rug.nl>, Remco Gerlich
>><scar...@dds.nl> writes
>>>
>><snip>
>>>
>>>(pretty random order, written down from the top of my head).
>>>
>>>You can decide for yourself what you think is essential... For instance,
>>>graphics are now available in many roguelikes. I could accept a game
>>>without potions and scrolls as a roguelike, but without the discrete 2D
>>>random world and the 1-char commands it'd be hard...
>>>
>>>
>
>>Diablo?
>
>Ah - the expected answer. Diablo is probably on the edge. Its dungeons
>are 2D, but lack the "squares" part - monsters (and players) can move
>pretty continuously between spots - they can move halfway to some other
>location, and then change directions... The interface is quite different
>from the traditional Roguelike. You can save, and just continue, to
>backup, as if nothing happened. But, because of the random dungeons, the
>replay value is there (there are artifacts that are dropped randomly as
>in Angband as well, right? I'm not sure).
>
>Personally, I don't consider Diablo to be a Roguelike, even though I
>*do* consider it to be an Angband-ripoff. It's just not a game "like
>Rogue", like Angband, Nethack, Moria, Crawl, etc are. I do understand
>that some people do consider it a Roguelike - as I said, "you can decide
>for yourself what is essential", and Diablo obviously comes close.
>
Roguelikes really fail miserably in the multiplayer department...
rp...@my-dejanews.com
thun...@xs4all.nl wrote:
> On Sun, 11 Oct 1998 03:42:41 GMT, Freemason@Solomon's.Temple (G
> Masonic) wrote:
>
> >After giving the secret handshake, Mat...@uscom.com (Drakmere)
> >whispered to Solomon:
the
> >>only REALLY unifying factor.
> >
> >I disagree. Randomization is the only real unifying theme.
> >-----
> >Go to:
> >www.11thhourradioshow.com
> >or die.
> And I'm tempted to say that as long as it's got to do with fighting,
> single or in very small groups, with characters from different
> classes, different races, different stats, who learn along the way,
> it's roguelike enough for me. This may also include a lot of
> adventures, I know.
I've got an idea: A roguelike is a game in the spirit of the game 'rogue'.
:)
--RJP
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Howard Liu
>: I personally think that defining what makes a game roguelike is
>: impossible. I would myself consider Diablo to be roguelike (though a
>: shallow one). You can point to several common themes, but you cannot
>: really define it (sounds nice `n` spiritual huh?).
>Not really hard...I think Diablo is the only game where there is really
>question of its roguelike-ness. I myself say that even if it fits "the
>rules" it made notty sacrafices to aim it at the QUAKE crowd. Roguers wear
>their narrow game appeal like a badge of honor-so Diablo is out just
>because we say so! Also it broke the theme-substance over presentation.
(Whackety snip snip...)
What about Caverns of Kroz? ZZT? Apshai? SSI's Dungeon Hack?
(I also vaguely remember an odd game that took place in a pyramid, and played
kind of like Hunt the Wumpus, with Driders everywhere. Played it around the
same time I was playing Temple of Apshai and D&D/Telengard, I think. Temple of
Lolth, or something like that? Not really Roguelike, but you got wandered
through a randomly generated dungeon, had stats, fought monsters. Drank from
pools, too, I think. Kind of like Hunt the Wumpus, really).
How much plot or character interaction can you put in before a Roguelike
becomes an CRPG (alternatively, are Eye of the Beholder or Daggerfall
Roguelikes)? How deep does it have to be to avoid becoming "Daleks"?
The main defining point for me is simply that Roguelikes are free. Of course,
by this definition, Rogue isn't a Roguelike, but it's the guideline I went by.
As far as Diablo goes, I didn't think it was *that* shallow. They took out a
lot of things I don't enjoy fiddling with in the first place (food,
sticky-cursed items, other things I just find more inconvenient than
challenging), and it had multiplayer plus some fairly well-done mini-quests. I
really like stumbling over the unexpected quirks of a new Roguelike (or old
ones that keep evolving), though, and Diablo didn't really have a lot to offer
in that regard. Probably my own fault, for having the attention span of a
gnat, though, after the initial flush of new discovery - it's been a while
since I've finished any Roguelike at all.
Drakmere
>>
>>>: I personally think that defining what makes a game roguelike is
>>>: impossible. I would myself consider Diablo to be roguelike (though a
>>>: shallow one). You can point to several common themes, but you cannot
>>>: really define it (sounds nice `n` spiritual huh?).
>>
>>>Not really hard...I think Diablo is the only game where there is really
>>>question of its roguelike-ness. I myself say that even if it fits "the
>>>rules" it made notty sacrafices to aim it at the QUAKE crowd. Roguers wear
>>>their narrow game appeal like a badge of honor-so Diablo is out just
>>>because we say so! Also it broke the theme-substance over presentation.
>>
>>(Whackety snip snip...)
>>
>>
>>What about Caverns of Kroz? ZZT? Apshai? SSI's Dungeon Hack?
>
>me at the moment? This game has a knight walking around randomly
>generated dungeons whacking monsters, and also finds rods, potions and
>spellbooks that can only be identified by using them, For instance,
>a "yellow potion" or a "blue scroll" can have any of several effects.
>
>Anyone know what game I'm talking about (I am sober<g>)?
>
>/Ted Douglas
>
game, it was for gameboy...) I hated the one about Alchemy, but it had a VERY
weird battle system.
Linley Henzell
> I personally think that defining what makes a game roguelike is
> impossible. I would myself consider Diablo to be roguelike (though a
> shallow one). You can point to several common themes, but you cannot
> really define it (sounds nice `n` spiritual huh?).
Yeah. It's a Zen thing.
Linley
Jason Willoughby
> Something to do with Alchemy? Or some such, right? (Or was that a different
> game, it was for gameboy...) I hated the one about Alchemy, but it had a VERY
> weird battle system.
I remember the Alchemy game, really unique, but it took way to much
patience for my tastes. There were hundreds of combinations of the
elements, and 90% of the results were absolutely useless. You needed some
serious note-taking or spoilers to get anywhere.
Not roguelike, I would say, although it was a dungeon crawl...
Guenther Fischer
> Not really hard...I think Diablo is the only game where there is really
> question of its roguelike-ness. I myself say that even if it fits "the
> rules" it made notty sacrafices to aim it at the QUAKE crowd. Roguers wear
I always thought the turn-based system is one integral part of a
roguelike game (thinking instead of reacting). That's the reason why
Diablo isn't a Roguelike.
Guenther Fischer
Drakmere
David Grabiner
> What about Caverns of Kroz? ZZT? Apshai? SSI's Dungeon Hack?
ZZT: No, because it's not a game in which you develop you rplayer; it's
more of a puzzle which happens to be played on a grid. Combat is
incidental to the game, and it isn't replayable once you have won.
Apshai: Not the same format. It's a D&D-type game like Rogue, but the
nature of the game is quite different. Movement is almost continuous,
with only one active monster at a time, and that monster becomes
inacvtive if you leave its room.
--
David Grabiner, grab...@math.lsa.umich.edu
http://www.math.lsa.umich.edu/~grabiner
Shop at the Mobius Strip Mall: Always on the same side of the street!
Klein Glassworks, Torus Coffee and Donuts, Projective Airlines, etc.
Guenther Fischer
> >I always thought the turn-based system is one integral part of a
> >roguelike game (thinking instead of reacting). That's the reason why
> >Diablo isn't a Roguelike.
> >
> >Guenther Fischer
> Mangband IS turnbased (Kinda) if you were interterested.
Then Mangband (I don't know it) probably is a Roguelike, can't have an
opinion on this. Diablo isn't (IMHO) because of the above mentioned
reason.
Guenther Fischer
rp...@my-dejanews.com
Why do we have to be pedantic about what is or is not a roguelike? Why must
there be a well-defined box which a game must fit to be a roguelike? It isn't
like it is of any legal importance. :)
Now, I haven't played Diablo, but it sounds like it is sortof rogue-ish. As
it stands, many of the games we call 'roguelikes' are only sortof rogue-ish.
Isn't something a roguelike if it is like rogue? Why can't we have action
roguelikes? Must a roguelike be a single-player turn-based text-based
ortho-grid-based single-entity-per-square level-split single-screened
DnD-genre game to be a roguelike?
I don't think so, and probably most of you don't either. But I don't think
the question should be 'Where do we draw the lines,' but more 'Why do we need
to draw the lines?' If it's rogueish enough, it will be accepted as a
roguelike, if not, it won't.
Here we have come down to the fact that the only thing that spans all
roguelikes is the fact that it's turn-based. But so is chess, and that isn't
a roguelike.
Personally I think a networked multiplayer strategy-gameboard-based
ultrafuture 'roguelike' would be cool. Of course, that breaks most of the
'rules' for a roguelike, but most would still probably agree that it is.
So, why argue? :)
> Guenther Fischer
-- RJP
Remco Gerlich
>Why do we have to be pedantic about what is or is not a roguelike? Why must
>there be a well-defined box which a game must fit to be a roguelike? It isn't
>like it is of any legal importance. :)
>
for a generic roguelike once, and I need to know what to put in and what
to leave out =). Also I can't stand people calling every other game
roguelike; and I like arguing.
>Now, I haven't played Diablo, but it sounds like it is sortof rogue-ish. As
>it stands, many of the games we call 'roguelikes' are only sortof rogue-ish.
>Isn't something a roguelike if it is like rogue? Why can't we have action
>roguelikes? Must a roguelike be a single-player turn-based text-based
>ortho-grid-based single-entity-per-square level-split single-screened
>DnD-genre game to be a roguelike?
>
Well, opinions differ on this. Hence the discussion.
>I don't think so, and probably most of you don't either. But I don't think
>the question should be 'Where do we draw the lines,' but more 'Why do we need
>to draw the lines?' If it's rogueish enough, it will be accepted as a
>roguelike, if not, it won't.
>
Nah, the question shouldn't be "why argue about this" - if some people
want to argue, let them. Also, even though people accept 1,000 random
games as being roguelike doesn't mean that I have to agree :-).
The few games I accept as being roguelike are all very special to me;
they have something special that I really like. By trying to define what
exactly makes these games different from others, I try to find out what
it is exactly that I like so much.
>Here we have come down to the fact that the only thing that spans all
>roguelikes is the fact that it's turn-based. But so is chess, and that isn't
>a roguelike.
>
Nah, there are more things spanning all roguelikes. (Hmmm... how about
battle chess with a randomized opening position? :-)).
>Personally I think a networked multiplayer strategy-gameboard-based
>ultrafuture 'roguelike' would be cool. Of course, that breaks most of the
>'rules' for a roguelike, but most would still probably agree that it is.
>
Don't know. I'd have to play it first to see.
Guenther Fischer
> Why do we have to be pedantic about what is or is not a roguelike? Why must
> there be a well-defined box which a game must fit to be a roguelike? It isn't
> like it is of any legal importance. :)
Because the original poster asked about it? :)
> Isn't something a roguelike if it is like rogue? Why can't we have action
> roguelikes? Must a roguelike be a single-player turn-based text-based
Because they aren't roguelikes anymore. Why call an action-RPG
roguelike? Just call it Action-RPG!
> Here we have come down to the fact that the only thing that spans all
> roguelikes is the fact that it's turn-based. But so is chess, and that isn't
> a roguelike.
Nah, it's one of the definitions, not the only definition.
> So, why argue?
Maybe for the one reason that I want to read about roguelikes here, or
else we could rename this group to
rec.games.maybealittlebitlikeroguelikesbutmaybenotwhocares.misc :)
Guenther Fischer
rp...@my-dejanews.com
scar...@dds.nl (Remco Gerlich) wrote:
> rp...@my-dejanews.com wrote:
> >Why do we have to be pedantic about what is or is not a roguelike? Why must
> >there be a well-defined box which a game must fit to be a roguelike? It isn't
> >like it is of any legal importance. :)
> >
> for a generic roguelike once, and I need to know what to put in and what
> to leave out =). Also I can't stand people calling every other game
> roguelike; and I like arguing.
>
Actually, I'm working on a rather generic extendable roguelike now.
I had started it a long time ago, and it got put off because of various
other more important things (like paying the bills :).
How does scriptable, networkable, built-to-be-hacked sound? And what are
people's opinions on scripting languages? I was initially thinking of just
having extensions in C loaded as shared libraries at runtime, but that's
more trouble than it's worth. Perl sound good?
<snip>
> >I don't think so, and probably most of you don't either. But I don't think
> >the question should be 'Where do we draw the lines,' but more 'Why do we need
> >to draw the lines?' If it's rogueish enough, it will be accepted as a
> >roguelike, if not, it won't.
> >
> Nah, the question shouldn't be "why argue about this" - if some people
> want to argue, let them. Also, even though people accept 1,000 random
> games as being roguelike doesn't mean that I have to agree :-).
>
> The few games I accept as being roguelike are all very special to me;
> they have something special that I really like. By trying to define what
> exactly makes these games different from others, I try to find out what
> it is exactly that I like so much.
>
Yeah. Which is why it's probably better to talk about things as 'more
roguelike' or 'less roguelike'. Oh, did I mention I don't like character
classes? Give me a skill-based system any day. :)
<snip>
>Personally I think a networked multiplayer strategy-gameboard-based
> >ultrafuture 'roguelike' would be cool. Of course, that breaks most of the
> >'rules' for a roguelike, but most would still probably agree that it is.
> >
> Don't know. I'd have to play it first to see.
>
If this gets done, you'll have a chance. =)
> --
> Remco Gerlich scarblac at dds dot nl
>
-- RJP
William Tanksley
>How does scriptable, networkable, built-to-be-hacked sound? And what are
>people's opinions on scripting languages? I was initially thinking of just
>having extensions in C loaded as shared libraries at runtime, but that's
>more trouble than it's worth. Perl sound good?
No. (Sorry.) Take a look at some other things first -- Perl is the first
to occur, but it's a horrible language for anything other than simple
scripting. Try Python, which is an excellent scripting language. One
really cool thing about Python is that you can distribute bytecodes instead
of or in addition to the source (for those secret levels). Plus, it's
readable, and has function support.
http://www.python.org. Like Perl, it's free.
> -- RJP
-Billy working on learning Perl, and not enjoying it
Juho E Snellman
was a horribly unfounded opinion. Python has its advantages, and
perl its weaknesses, but these are certainly not them. ]
On Sat, 17 Oct 1998 <wtan...@cx930311-b.ocnsd1.sdca.home.com> wrote:
>No. (Sorry.) Take a look at some other things first -- Perl is the first
>to occur, but it's a horrible language for anything other than simple
>scripting.
Why ?
>Try Python, which is an excellent scripting language. One
>really cool thing about Python is that you can distribute bytecodes instead
>of or in addition to the source (for those secret levels).
As one can with perl. The B-module can compile to bytecode, though I
admit that it is not yet as refined as Pythons support for bytecode.
>Plus, it's
>readable,
At least perl is writable, unlike Python. Blocks being defined by indentation
is just horrible, not to mention the fact that Python tries to force
the programmer to use constructs that are not well suited for the
task (for example reg.ex:s) to keep the language uncluttered.
>and has function support.
Wow! Functions! I'll switch to Python immediately. Oh, wait a minute.
Perl seems to have functions too... Since funtions aren't really
anything special in a language I'll have to assume that you meant
something else with your comment. Care to elaborate on that ?
If you truly haven't discovered elementary concepts like 'sub {}', no wonder
you think that perl is not suitable for anything but simple scripting.
--
Juho Snellman
Zvahyyn rv byr xbgvfvihn bfbvggrrffn uggc://jjj.ylfrb.rqh.bhxn.sv/~wfaryy/
Ivan Igor Tkatchev
Juho E Snellman <jsn...@lyseo.edu.ouka.fi> wrote:
>
>At least perl is writable, unlike Python. Blocks being defined by indentation
>is just horrible, not to mention the fact that Python tries to force
>the programmer to use constructs that are not well suited for the
>task (for example reg.ex:s) to keep the language uncluttered.
Argghh, _how_ many times have I heard this misconception??? Python's
blocks ARE NOT horrible. Please, people, try it first before flaming!
Don't confuse Python with make. Just because Makefiles have a braindead
way of defining blocks doesn't mean Python does too! I've never heard a
person say that Python's blocks are ``horrible'' once he has tried to
program in Python for a little bit.
(Besides, who needs regexes in a roguelike game? And what the heck does
reg.ex:s mean?)
Juho E Snellman
>In article <slrn72h8bu...@melkki.cs.Helsinki.FI>,
>Juho E Snellman <jsn...@lyseo.edu.ouka.fi> wrote:
>>
>>At least perl is writable, unlike Python. Blocks being defined by indentation
>>is just horrible
>blocks ARE NOT horrible. Please, people, try it first before flaming!
>Don't confuse Python with make. Just because Makefiles have a braindead
>way of defining blocks doesn't mean Python does too! I've never heard a
>person say that Python's blocks are ``horrible'' once he has tried to
>program in Python for a little bit.
They are. I want my editor to do my indenting, and not having to worry
about it myself. I like the fact that I don't have to worry about the
indentation having any effect on my program. Maybe "horrible" is an
overstatement, but it certainly is very uncomfortable. Certainly
this is no more a misconception than the common one of calling perl
unreadable.
I've programmed in Python a little, mainly enough to realize that it
was close enough to perl in capabilities that spening my time on learning
it would not really make me more productive. I suppose that for someone
who learnt Python first there is no real incentive to learn perl either.
>>, not to mention the fact that Python tries to force
>>the programmer to use constructs that are not well suited for the
>>task (for example reg.ex:s) to keep the language uncluttered.
>
>(Besides, who needs regexes in a roguelike game? And what the heck does
>reg.ex:s mean?)
Well, to my eyes 'reg.ex' looks a lot clearer then 'regexe'. YMMV, but
if the best arguments you have are spelling flames I'm not really sure
this is a meaningful discussion.
Josh Fishman
> How does scriptable, networkable, built-to-be-hacked sound? And what are
> people's opinions on scripting languages? I was initially thinking of just
> having extensions in C loaded as shared libraries at runtime, but that's
> more trouble than it's worth. Perl sound good?
Consider Python. It's a fun language to embed.
- Josh
--
O< ( ( "So [camels] long ago plumped for a lifestyle that, in return
_NH >=O ) ) for a certain ammount of porterage and being prodded with st-
<_>-<_ + :::::-. icks, allowed them adequate food and grooming and the chance
HCl<O> :::`-' to spit in a human's eye and get away with it."-TP on c.l.p.m
William Tanksley
>[ I'll try not to start a language war here, but I thought that this
> was a horribly unfounded opinion. Python has its advantages, and
> perl its weaknesses, but these are certainly not them. ]
It's decently founded, but poorly stated. :) Thanks for refraining from
flaming :).
>On Sat, 17 Oct 1998 <wtan...@cx930311-b.ocnsd1.sdca.home.com> wrote:
>>No. (Sorry.) Take a look at some other things first -- Perl is the first
>>to occur, but it's a horrible language for anything other than simple
>>scripting.
>Why ?
See below.
>>Try Python, which is an excellent scripting language. One
>>really cool thing about Python is that you can distribute bytecodes instead
>>of or in addition to the source (for those secret levels).
>As one can with perl. The B-module can compile to bytecode, though I
>admit that it is not yet as refined as Pythons support for bytecode.
Indeed.
>>Plus, it's
>>readable,
>At least perl is writable, unlike Python. Blocks being defined by indentation
>is just horrible,
Python is the most writable language I've ever used. Even Forth is less
writable, because it goes too far for simplicity. Indentation blocks are
like a breath of frash air -- and you're free to differ with that. Python
has a built-in feature which lets you put in any form of braces you want,
like this:
if x==0:
#{
do(something)
#}
Cool, huh? Or you can do this the right way, like this:
if x==0: do(something)
or
if x==0:
do(something)
>not to mention the fact that Python tries to force
>the programmer to use constructs that are not well suited for the
>task (for example reg.ex:s) to keep the language uncluttered.
I'm sorry, where were you forced to use regexes? Python doesn't have
built-in support for them, so it's pretty strange that you should be forced
to use them inappropriately.
>>and has function support.
>Wow! Functions! I'll switch to Python immediately. Oh, wait a minute.
>Perl seems to have functions too... Since funtions aren't really
>anything special in a language I'll have to assume that you meant
>something else with your comment. Care to elaborate on that ?
Perl has REALLY rudimentary subroutine support. For an example of what I
mean, take a look at Perl's way of getting parameters into a procedure:
sub whatever {
my ($x,$y) = @_;
/* ... */
}
You have to manually disassemble the command line of the subroutine. Of
course, there's some nice things there; I can't deny that you sometimes want
to manually disassemble it. That's why Python supports that, like this:
def whatever( *params ):
(x,y) = params
# ...
>If you truly haven't discovered elementary concepts like 'sub {}', no wonder
>you think that perl is not suitable for anything but simple scripting.
Perl is an extremely powerful scripting language, best used for text
processing and info extraction. For anything else, there are better tools.
Python is best suited for rapid application development and for things which
require a scripting language but don't always permit source. It's also
decent at math and such, and gets better when you add in somme mmodules
(like NumPy). For other purposes, I'd choose something else.
Eiffel is... :-)
Anyhow, my point was that for this purpose, Perl is standing on all of its
weaknesses and none of its admirable strengths. We don't need text
processing; we could, on the other hand, use bytecode (for secret roomms and
such).
>Juho Snellman
-Billy
Ivan Igor Tkatchev
Juho E Snellman <jsn...@lyseo.edu.ouka.fi> wrote:
>
>They are. I want my editor to do my indenting, and not having to worry
>about it myself. I like the fact that I don't have to worry about the
>indentation having any effect on my program. Maybe "horrible" is an
>overstatement, but it certainly is very uncomfortable. Certainly
>this is no more a misconception than the common one of calling perl
>unreadable.
I don't know what editor you use, but my editor indents my Python code for
me.
Programmers think of blocks in terms of whitespace, not braces. The braces
are there to guide the dumb parser. (Unless you know of someone who
codes withuot indenting blocks?)
Indentation _always_ has an effect on the program. Maybe not as far as the
parser is concerned, but in your head indentation always matters.
>
>Well, to my eyes 'reg.ex' looks a lot clearer then 'regexe'. YMMV, but
>if the best arguments you have are spelling flames I'm not really sure
>this is a meaningful discussion.
>
Spelling flame? I wasn't sure what you meant by ``reg.ex:s''. I thought
you were referring to Python syntax or somthing like that.
William Tanksley
>>>At least perl is writable, unlike Python. Blocks being defined by indentation
>>>is just horrible
>>Argghh, _how_ many times have I heard this misconception??? Python's
>>blocks ARE NOT horrible. Please, people, try it first before flaming!
>They are. I want my editor to do my indenting, and not having to worry
>about it myself.
Er -- what editor are you using? I've tried several, almmost all of them
with superb Python support. I'm using Jed right now. Emacs also has it, as
does vim. vi doesn't really need it, because it works perfectly well if you
use either just tabs or just spaces.
>I like the fact that I don't have to worry about the
>indentation having any effect on my program.
Sorry -- it does. The effect without Python is that your program becomes
unmaintainable; the effect with Python is that your program becomes
obviously buggy, or possibly even generates an error. There's no real
difference between the two, in the long run.
Here's some C.
if (something)
if (something_else)
do_other();
else do_this();
In Python, this code means exactly what it says. In Perl, of course, it's
impossible because I didn't put in the curly braces (good for Perl, that
reduces ambiguity even at the expense of more typing). In C, it actually
means:
if (something)
if (something_else)
do_other();
else do_this();
Note the difference on the last line?
>Maybe "horrible" is an
>overstatement, but it certainly is very uncomfortable.
It's actually not -- but there's no way of convincing you of that except
having you write or maintain some Python, where you would see that far from
being uncomfortable, it's the most comfortable and useful combination of
convention and compiler that you've used.
>Certainly
>this is no more a misconception than the common one of calling perl
>unreadable.
True. Perl may be noisy, but it's not unreadable. Noise is no sin; APL is
also noisy, and it's a great language.
>I've programmed in Python a little, mainly enough to realize that it
>was close enough to perl in capabilities that spening my time on learning
>it would not really make me more productive. I suppose that for someone
>who learnt Python first there is no real incentive to learn perl either.
This is a VERY good point. However, we're not debating here whether people
should learn Python or Perl; we're discussing which one would make a good
scripting language for a Roguelike.
Another thing to suggest is S-lang.
S-lang and Python have both been used to help script Angband variants; the
newest beta of Zangband is released with S-Lang support. The Python
variant, known as PAngband (plot based Angband) is in unknown development
right now :).
>>>, not to mention the fact that Python tries to force
>>>the programmer to use constructs that are not well suited for the
>>>task (for example reg.ex:s) to keep the language uncluttered.
>>(Besides, who needs regexes in a roguelike game? And what the heck does
>>reg.ex:s mean?)
>Well, to my eyes 'reg.ex' looks a lot clearer then 'regexe'. YMMV, but
>if the best arguments you have are spelling flames I'm not really sure
>this is a meaningful discussion.
I was curious about whether you mmeant anything by the strange spelling as
well. I still don't know what you mean by the sentance, though.
>Juho Snellman
-Billy
Warren Cheung
> Why do we have to be pedantic about what is or is not a roguelike? Why must
> there be a well-defined box which a game must fit to be a roguelike? It isn't
> like it is of any legal importance. :)
If anyone cares, this is the definition that I personally would like to
put my money on. I like openendedness - the ability to move forward.
As a developer and an enduser of such games, I wouldn't mind some
variety - I mean, sooner or later, the most rigid definitions will be
implemented until we have them coming out of our ears. Room for
expansion/improvement is good.
Otherwise, we might end up with roguelike-likes just because a game
doesn't fit one little criteria...
Roguelike - When I play it, it reminds of other roguelikes. <G>
--
WACko
Homepage:
http://wac.cjb.net or http://wac.home.ml.org
SLASH'EM (Game Indev):
http://slashem.cjb.net or http//slashem.home.ml.org
Juho E Snellman
>>not to mention the fact that Python tries to force
>>the programmer to use constructs that are not well suited for the
>>task (for example reg.ex:s) to keep the language uncluttered.
>
>built-in support for them, so it's pretty strange that you should be forced
>to use them inappropriately.
Oops, I should have stated that more clearly. What I meant is that _if_
I want to use a regular expression, I have to use it in a rather convoluted
way (i.e regex.compile(), regex.match() etc), since they had to fit into
the structures of the language. Perl on the other hand adds new constructs
to the language for new features. This admittedly makes the code look
like a mess sometimes when you have constructs borrowed from a dozen
places, but I don't think it makes it harder to understand. And I think
it makes writing much easier.
>You have to manually disassemble the command line of the subroutine. Of
>course, there's some nice things there; I can't deny that you sometimes want
>to manually disassemble it. That's why Python supports that, like this:
Okay, I can see your point. Your original statement was a bit too strong :)
I'd like to point out though that we are only talking about syntactic
sugar here (it could be a nice piece of sugar though :) ). Not really
much difference in apperance (and none in functionality) between
sub foo ($$) { ($x, $y) = @_;
and a hypothetical
sub foo ($x, $y) {
>Perl is an extremely powerful scripting language, best used for text
>processing and info extraction. For anything else, there are better tools.
"Perl is a hammer. All programs are nails." :)
Seriously, I dislike dooming languages into niches if they are not
totally unwieldy outside of their own area (Cobol for roguelikes,
anyone ? ) . Once you have languages that are flexible enough, you're
really better off using the ones that you feel most comfortable
with.
Juho E Snellman
>>
>>They are. I want my editor to do my indenting, and not having to worry
>>indentation having any effect on my program. Maybe "horrible" is an
>>overstatement, but it certainly is very uncomfortable. Certainly
>>this is no more a misconception than the common one of calling perl
>>unreadable.
>
>me.
So does mine, but since the editor really can't know what I mean, and
must start guessing. For exampleif I write the following code, it
is indented as I type it:
if foo == 0:
bar()
if foo == 1:
doh()
I must then go and move the second if to where it belongs:
if foo == 0:
bar()
if foo == 1:
doh()
Not a big nuisance, but aggravating enough. I like the fact that if
I have to add a loop around some segment of code I can just add
braces around the code, and then re-indent the whole section with
just one key. In this case the editor must again start guessing in
Python. Is some editor smarter than Jed in this ?
>Programmers think of blocks in terms of whitespace, not braces. The braces
>are there to guide the dumb parser.
Perhaps. But I don't like worrying about laying the whitespace if I can
just lay the aids there for the computer to take care of it for me.
>(Unless you know of someone who
>codes withuot indenting blocks?)
Besides Linley ? Nope ;)
Juho E Snellman
>This is a VERY good point. However, we're not debating here whether people
>should learn Python or Perl; we're discussing which one would make a good
>scripting language for a Roguelike.
Might as well get back to the topic :) Were we discussing a scripting
language for a RL or a implementation language for one ? Not that there
is much difference, but I'm leaning to the opinion that beyond implementing
the IO-routines in C, the rest could (and should) be implemented in
a high-level language (I finally figured out why my first attempt
at a perl roguelike was a memory hog, which eliminated my reservations
about it). Especially interfacing the neccesary variables between the
languages tends to be icky, and the benefits of C aren't really there
for games.
I haven't seen any of the roguelikes with scripting support yet, but
I can't really imagine them having a big impact (especially if they
have been bolted on 15 years after the basic design of the game).
If you start designing the game for expandability, you might as well
ditch C completely.
>Another thing to suggest is S-lang.
The lack of data-structures of any kind really kills it for me. Otherwise
It'd be a splendid little language for (ehh...) bolting on to an existing
roguelike. I can't really imagine designing a whole game around it
unlike an editor or news-reader though :)
I'm pretty certain that implementing a roguelike in would be as
plausible in perl, Python or Scheme. There might be small features
or mis-features in all of them that help or hinder, but they really
are not significant in the scope of the whole project.
Ivan Igor Tkatchev
Juho E Snellman <jsn...@lyseo.edu.ouka.fi> wrote:
>
>Not a big nuisance, but aggravating enough. I like the fact that if
>I have to add a loop around some segment of code I can just add
>braces around the code, and then re-indent the whole section with
>just one key. In this case the editor must again start guessing in
>Python. Is some editor smarter than Jed in this ?
>
blocks. Still, if you want to add a loop around some code, you can just do
this:
Before:
if foo:
bar.class.func(foo)
After:
if foo:
for x in foo:
bar.class.func(x)
>Perhaps. But I don't like worrying about laying the whitespace if I can
>just lay the aids there for the computer to take care of it for me.
That's true. The way Python does it, though, ensures that what you wrote
it exactly what you meant to write. At lest for me, the indentation-based
blocks reduce the number bugs and stupid syntax errors.
William Tanksley
><wtan...@cx930311-b.ocnsd1.sdca.home.com> wrote:
>>>not to mention the fact that Python tries to force
>>>the programmer to use constructs that are not well suited for the
>>>task (for example reg.ex:s) to keep the language uncluttered.
>>I'm sorry, where were you forced to use regexes? Python doesn't have
>>built-in support for them, so it's pretty strange that you should be forced
>>to use them inappropriately.
>Oops, I should have stated that more clearly. What I meant is that _if_
>I want to use a regular expression, I have to use it in a rather convoluted
>way (i.e regex.compile(), regex.match() etc), since they had to fit into
>the structures of the language. Perl on the other hand adds new constructs
>to the language for new features. This admittedly makes the code look
>like a mess sometimes when you have constructs borrowed from a dozen
>places, but I don't think it makes it harder to understand. And I think
>it makes writing much easier.
There's room for your opinion on that -- I think it's a good point. Perl's
regexpes are certainly admirable.
OTOH, the added typing isn't a big deal; typing 'match()' instead of "=~
s///" isn't a problem.
I'd say that neither language has a definite win here; Perl looks and acts
cool, but Python acts cool and at least doesn't look geeky. :) (Irony, eh?)
>>You have to manually disassemble the command line of the subroutine. Of
>>course, there's some nice things there; I can't deny that you sometimes want
>>to manually disassemble it. That's why Python supports that, like this:
>Okay, I can see your point. Your original statement was a bit too strong :)
I'm known for that :). Thanks for your patience.
However, there's a problem I forgot to mention. See below.
>I'd like to point out though that we are only talking about syntactic
>sugar here (it could be a nice piece of sugar though :) ). Not really
>much difference in apperance (and none in functionality) between
>sub foo ($$) { ($x, $y) = @_;
>and a hypothetical
>sub foo ($x, $y) {
But there's orders of magnitude difference between either of those and this:
def foo(x,y):
simply because that one can accept an array as a parameter. According to my
Perl book, making a Perl subroutine accept an array is difficult at best.
>>Perl is an extremely powerful scripting language, best used for text
>>processing and info extraction. For anything else, there are better tools.
>"Perl is a hammer. All programs are nails." :)
Cute and untrue. If nothing else, assembly is still needed. That sort of
opinion is something I'd always admired the Perl commmunity for having --
until I started learning Perl. Now it's started to disgust me (sorry).
>Seriously, I dislike dooming languages into niches if they are not
>totally unwieldy outside of their own area (Cobol for roguelikes,
>anyone ? ) . Once you have languages that are flexible enough, you're
>really better off using the ones that you feel most comfortable
>with.
The problem is that Perl IS totally unwieldy outside of its problem area.
Name a problem -- integer work, bignums, object orientation, typesafe, and
so on. It's coincidental that I happened to name areas that Python is
far better than Perl; it's inevitable that some language would exceed in a
list that long.
What's scary is how short the list of things that Perl does really well is,
and what its advantages in those areas really are:
Text processing (screamingly fast optimised subsystem). Unix system
administration and scripting (tailored functions).
I suppose there were people who wanted to use SNOBOL for everything as well.
And Tcl. I mean, it's certainly possible; they're turing-complete.
>Juho Snellman
-Billy
Josh Fishman
> [ I'll try not to start a language war here, but I thought that this
> was a horribly unfounded opinion. Python has its advantages, and
> perl its weaknesses, but these are certainly not them. ]
>
> >No. (Sorry.) Take a look at some other things first -- Perl is the first
> >to occur, but it's a horrible language for anything other than simple
> >scripting.
>
> Why ?
Python and Perl attack different problem spaces. Perl reminds me of
shell scripting on steroids -- it's a great language for quick & dirty
hacks, or things that involve text processing. I like Perl a lot, and
used to use it daily, for everything from automating my Mac to parsing
a particular made-up pseudocode and emitting the appropriate pseudo-
parallel C code.
Now I'm helping embed Python in a set of truely huge programs. Python
is, IMHO, easier for many people to learn. I'm a UNIX guy, so shells,
ed(1) regexen and other Perl conventions seem natural to me, but for
many people they are not immediately intuitive. Python is easier for
those people to learn for the simple reason that there is less of it.
It took me about a week to learn Python with nothing but the on-line
docs and the interactive mode of Python itself (IMHO a great boon to
debugging).
> >Try Python, which is an excellent scripting language. One
> >really cool thing about Python is that you can distribute bytecodes instead
> >of or in addition to the source (for those secret levels).
>
> As one can with perl. The B-module can compile to bytecode, though I
> admit that it is not yet as refined as Pythons support for bytecode.
... and both have the support necessary for cross-platform binary data
representations (via Perl's pack and Python's pickle package) and cross-
platform bones files, which is of course the Ultimate Holy Grail of
Roguelikes.
> >Plus, it's
> >readable,
>
> At least perl is writable, unlike Python. Blocks being defined by indentation
> is just horrible, not to mention the fact that Python tries to force
> the programmer to use constructs that are not well suited for the
> task (for example reg.ex:s) to keep the language uncluttered.
Keeping the language uncluttered is precisely why I like it as an
embedded ``scripting'' language. The whole point of such a language
IMHO is so people who are not C hackers can nonetheless customize
their environment.
I know I'd rather write a short tutorial on how to program in Python.
BTW, I really don't get the problem with indentation as blocking. We
all know that we're supposed to indent our code like that anyway, right?
> >and has function support.
>
> Wow! Functions! I'll switch to Python immediately. Oh, wait a minute.
> Perl seems to have functions too... Since funtions aren't really
> anything special in a language I'll have to assume that you meant
> something else with your comment. Care to elaborate on that ?
He may be refering to first-class functions, or to Python's ``functional''
programming support. Perl has the former at least, and probably the latter,
though disguised.
> If you truly haven't discovered elementary concepts like 'sub {}', no wonder
> you think that perl is not suitable for anything but simple scripting.
I thought at issue was Python's superiority for simple scripting <wink>.
Anyway, I stick to the assertion that Python is the best choice for an
easy-to-{read,write,embed,extend} language, and it's the one I'd prefer
to see in a Roguelike (and am willing to help with, esp. a Linux verison).
- Josh, the rabid new Python convert
Juho E Snellman
>In article <slrn72i6c3...@melkki.cs.Helsinki.FI>, Juho E Snellman wrote:
>simply because that one can accept an array as a parameter. According to my
>Perl book, making a Perl subroutine accept an array is difficult at best.
A Point well taken. You'd need to pass references to the arrays instead.
Not difficult IMHO, but potentially annoying.
sub doh ($\@) { ($foo, @$bar) = @_; }, if I'm not too sleepy right now.
>>"Perl is a hammer. All programs are nails." :)
>
>Cute and untrue.
Trust me, I certainly wasn't serious.
>The problem is that Perl IS totally unwieldy outside of its problem area.
>Name a problem -- integer work, bignums, object orientation, typesafe, and
>so on.
I wouldn't really call most of those problem areas, they are more like
techniques. I think that few people have really thought that the
current perl (as of 5.005) OO is anything beyond a hack. But that
doesn't really mean that there aren't other, equally valid ways
of doing the same tasks. OOP can also be a hammer, you know ;)
I haven't really done anything with the BigInt and BigFloat modules that
come with perl, so I'm not aware of any deficiensies they might have.
Care to elaborate a bit on why Python is better with regards to them ?
As for roguelikes, I don't think that any of Python's (or any other general-
purpose language's) advantages apply if we are talking about adding
extendability to a game written in C. They'd only be be apparent in writing a
game from scratch.
>What's scary is how short the list of things that Perl does really well is,
>and what its advantages in those areas really are:
That depends on what languages we are comparing :) If we are talking
about absolute advantages in the pool of all languages, that might be
correct, but then again Python wouldn't have a stunning list either.
In a head-to-head comparison I feel the result would be pretty
even, with most of the differences attributable to the cultural
difference to language desing between the perl and Python camps.
>Text processing (screamingly fast optimised subsystem). Unix system
>administration and scripting (tailored functions).
I'd add at least the huge amount of centrally available modules to
that list (you added OO to yours, this is fair :) ). Also the
liberal syntax is a plus for me.
Juho E Snellman
>Keeping the language uncluttered is precisely why I like it as an
>embedded ``scripting'' language. The whole point of such a language
>IMHO is so people who are not C hackers can nonetheless customize
>their environment.
That's an interesting point. Is the object to make it easier for
non-programmers to modify the game, or ease the programmer's job ?
I think that the closest analogue here is QuakeC. Did it make
Carmack's job easier to implement big parts of the game extrenally ?
I doubt it. Did it allow non-programmers to modify the game
meaningfully ? I doubt that too. Spectacular things were done
with QuakeC, but they were certainly done by programmers who
were already competent when they started.
Then again, I'm still having some difficulties envisioning a framework
for the game that would give enough rope for those extending the game.
The closest one that I can think of is a Inform-style action-based
system. Might still be too difficult to integrate the new artifact
sword you added that slays some certain critters, and the new almost-
critter that someone else made. You'd need an ungodly amount of flags
for that...
Josh Fishman
> <jo...@vortex.nyu.edu> wrote:
[ ``it'' == Python ]
> >Keeping the language uncluttered is precisely why I like it as an
> >embedded ``scripting'' language. The whole point of such a language
> >IMHO is so people who are not C hackers can nonetheless customize
> >their environment.
>
> That's an interesting point. Is the object to make it easier for
> non-programmers to modify the game, or ease the programmer's job ?
I was envisioning Python fitting into the latter role in particular,
but read on ...
> I think that the closest analogue here is QuakeC. Did it make
> Carmack's job easier to implement big parts of the game extrenally ?
> I doubt it. Did it allow non-programmers to modify the game
> meaningfully ? I doubt that too. Spectacular things were done
> with QuakeC, but they were certainly done by programmers who
> were already competent when they started.
And isn't Unreal's advantage over QuakeII that it features better
scripting? (Since there's no Unreal for Linux, I haven't played it
yet, but QuakeII was pretty good.)
> Then again, I'm still having some difficulties envisioning a framework
> for the game that would give enough rope for those extending the game.
> The closest one that I can think of is a Inform-style action-based
> system. Might still be too difficult to integrate the new artifact
> sword you added that slays some certain critters, and the new almost-
> critter that someone else made. You'd need an ungodly amount of flags
> for that...
I wasn't thinking of making the engine code easily extensible by non-
programmers, but rather the interface. So if you wanted to write your
own ``run'' function you could, or bind some arbitrary key to a macro
of your own design, you would be able to do so with out too much code
diving. E.g. ``M-d<ret>cursed<ret>'' drop all items which match regex
``cursed'' (okay, that's not much of a regex, but you get the idea).
- Josh
Greg Wooledge
>Programmers think of blocks in terms of whitespace, not braces. The braces
>are there to guide the dumb parser. (Unless you know of someone who
>codes withuot indenting blocks?)
That's just great until you run across code that's been edited by
two different people with two different editors, at least one of which
is using non-standard tab stops.
Have you seen Zangband's code yet? Check out the variety of indentation
levels. (I may not have preserved all the original tabs/spaces. The
following is the result of displaying the code with 8-space tab stops,
then cut-and-pasting (which clobbers tabs and makes them spaces), then
converting all 8-space chunks back into tabs. If you're viewing this
with a fixed-width font and 8-space tab stops, like God intended, then
you'll see that almost nothing lines up correctly.)
case 12: /* Orb or Draining */
if (!get_aim_dir(&dir)) return;
fire_ball(GF_HOLY_FIRE, dir,
(damroll(3, 6) + plev +
(plev / ((p_ptr->pclass == 2
|| p_ptr->pclass == CLASS_HIGH_MAGE) ? 2 : 4))),
((plev < 30) ? 2 : 3));
break;
case 13: /* Protection from Evil */
(void)set_protevil(p_ptr->protevil + randint(25) + 3 * p
_ptr->lev);
break;
case 14: /* Healing */
(void)hp_player(300);
(void)set_stun(0);
(void)set_cut(0);
break;
case 15: /* Glyph of Warding */
warding_glyph();
break;
case 16: /* Exorcism */
(void) dispel_undead(plev);
(void) dispel_demons(plev);
(void) turn_evil(plev);
break;
case 17: /* Dispel Curse */
(void)remove_all_curse();
break;
This is from version 2.1.1b, which is admittedly not the latest. I'm not
criticizing either Topi or Robert. Just pointing out that *in real
life*, when multiple people work on code, the indenting isn't likely to
be consistent. If indenting actually affects the interpretation of the
code by the parser, it sounds like a disaster waiting to happen to me.
But then, I've never used Python, so maybe there's some sort of sanity
check...?
Oh, here's something else to send everyone screaming in horror:
*variable-width fonts*
Ponder that for a moment. The correlation between variable-width fonts
and clueless Windoze programmers is extremely high. If Python were more
popular, you'd be seeing code snippets that look like Angband character
dumps after someone decides to edit them in their variable-width-font
news reader....
Note follow-ups.
--
"Daddy, why do those people have to | Greg Wooledge
use Microsoft Windows?" | wool...@kellnet.com
"Don't stare, son; it's not polite." | http://www.kellnet.com/wooledge/
ae...@blarg.net
jmf...@is4.nyu.edu wrote:
> On Fri, 16 Oct 1998 22:05:50 GMT, rp...@my-dejanews.com wrote:
> > How does scriptable, networkable, built-to-be-hacked sound? And what are
> > people's opinions on scripting languages? I was initially thinking of just
> > having extensions in C loaded as shared libraries at runtime, but that's
> > more trouble than it's worth. Perl sound good?
>
> Consider Python. It's a fun language to embed.
Actually, that was my first consideration long ago. Much easier to embed
than perl I must say, and due to some design changes, it might be possible.
I have also considered Scheme in some form (like Guile or Elk), although
I don't think it provides enough advantages (or a robust enough object
system) to work, not to mention speed penalties. Too bad you can't embed
common lisp.
As for the advantages of python over perl or the other way around, I
don't want to start a flamewar, so let's leave it at that. :)
>
> - Josh
-RJP
ae...@blarg.net
wtan...@cx930311-b.ocnsd1.sdca.home.com (William Tanksley) wrote:
> In article <708fvv$t3g$1...@nnrp1.dejanews.com>, rp...@my-dejanews.com wrote:
>
> >more trouble than it's worth. Perl sound good?
>
oh what *have* i started :P
> No. (Sorry.) Take a look at some other things first -- Perl is the first
> to occur, but it's a horrible language for anything other than simple
> scripting.
<cut>
I must disagree. After completing a fairly major project involving two
TCP servers (pure perl), I must say it is pretty darn robust and easy to
code.
Now, as a collector of languages, I don't like it for certain aesthetic
reasons (rather huge language with lots of magic), but it does get the
job done. OO is under par, but 'good enough', and at least it supports
multiple inheritence. :) And it's fast. And has lots of modules. Compared
to python, it's a bear to embed, however.
<cut>
> Try Python, which is an excellent scripting language. One
> really cool thing about Python is that you can distribute bytecodes instead
> of or in addition to the source (for those secret levels). Plus, it's
> readable, and has function support.
>
> http://www.python.org. Like Perl, it's free.
>
I learned python long before I learned perl, and I like and use them both.
I will be reconsidering python, don't worry, and the ease of embedding
it might be worth it. (After all, most of the stuff will be purely
callbacks anyway, so lots of perl modules isn't a big factor here).
> > -- RJP
>
> -Billy working on learning Perl, and not enjoying it
>
heh, it is *much* more complex than Python. I picked up python in a 10-minute
breeze through the tutorial (very well written); perl took a couple days
of flipping between manpages and hacking out code. But give it time, it's
a *very* useful language.
-- RJP
rp...@my-dejanews.com
jsn...@lyseo.edu.ouka.fi (Juho E Snellman) wrote:
> [ I'll try not to start a language war here, but I thought that this
> was a horribly unfounded opinion. Python has its advantages, and
> perl its weaknesses, but these are certainly not them. ]
>
> On Sat, 17 Oct 1998 <wtan...@cx930311-b.ocnsd1.sdca.home.com> wrote:
>
> >Try Python, which is an excellent scripting language. One
> >really cool thing about Python is that you can distribute bytecodes instead
> >of or in addition to the source (for those secret levels).
>
> admit that it is not yet as refined as Pythons support for bytecode.
>
This isn't a concern. This is GPL software, and I support open source.
That's almost a misfeature .... ;)
> >Plus, it's
> >readable,
>
> At least perl is writable, unlike Python. Blocks being defined by indentation
> is just horrible, not to mention the fact that Python tries to force
> the programmer to use constructs that are not well suited for the
> task (for example reg.ex:s) to keep the language uncluttered.
>
*fights both ends against the middle*
Python is perfectly writable. The difference is that it makes bad code
and poor design harder to maintain. But that doesn't mean you can't write
perfectly readable and easily maintainable code in perl, either.
Not sure what you mean by 'regex:s', last time I looked at python (1.5 or
so), there was the 're' module. Works very well; not quite as quick to
hack into code as in Perl, but just as powerful.
Now, how about we consider best-for-the-application and quit flaming? =P
-RJP
Ryan Pavlik
so I've crossposted it there, and we should probably phase it out
under .misc. We've been discussing perl vs. python for extending a
roguelike game, as if any of you don't read r.g.r.* ;)
Juho E Snellman <jsn...@lyseo.edu.ouka.fi> wrote:
> <wtan...@cx930311-b.ocnsd1.sdca.home.com> wrote:
>>This is a VERY good point. However, we're not debating here whether people
>>should learn Python or Perl; we're discussing which one would make a good
>>scripting language for a Roguelike.
Bravo. Relevant discussion. Thanks. =)
> Might as well get back to the topic :) Were we discussing a scripting
> language for a RL or a implementation language for one ? Not that there
> is much difference, but I'm leaning to the opinion that beyond implementing
> the IO-routines in C, the rest could (and should) be implemented in
> a high-level language (I finally figured out why my first attempt
> at a perl roguelike was a memory hog, which eliminated my reservations
> about it). Especially interfacing the neccesary variables between the
> languages tends to be icky, and the benefits of C aren't really there
> for games.
Exactly that. The basic stuff that handles all the networking et al. is
all in C. Everything else is in the language of choice (everything from
Map objects which contain what you actually see, to characters and inventory
stuff).
> I haven't seen any of the roguelikes with scripting support yet, but
> I can't really imagine them having a big impact (especially if they
> have been bolted on 15 years after the basic design of the game).
> If you start designing the game for expandability, you might as well
> ditch C completely.
That is a consideration. I don't really see a lot of reason to use it,
especially if I were to use perl. "Written in C, scriptable in XYZ" has
a bit more appeal perhaps, though.
Also, I originally planned to have it *all* in C, and do have a bit
of a codebase in C already. If it comes down to it, I won't hesitate
to ditch it.
This is especially the case when considering threading, which alone is
impossible with any embeddable scripting language I know of. Make
two threads and try to use the interpreter in both... nice segfault.
Of course, splitting it up into multiple processes is equally a problem,
since multiple interpreters get memory-heavy.
>>Another thing to suggest is S-lang.
> The lack of data-structures of any kind really kills it for me. Otherwise
> It'd be a splendid little language for (ehh...) bolting on to an existing
> roguelike. I can't really imagine designing a whole game around it
> unlike an editor or news-reader though :)
AFAIK, S-lang isn't a full enough language to do much more than
basic option processing. We need a robust language here. :)
> I'm pretty certain that implementing a roguelike in would be as
> plausible in perl, Python or Scheme. There might be small features
> or mis-features in all of them that help or hinder, but they really
> are not significant in the scope of the whole project.
Considered scheme, but I can't find a satisfactory implementation.
Wish I could embed common lisp... ;)
> --
> Juho Snellman
> Zvahyyn rv byr xbgvfvihn bfbvggrrffn uggc://jjj.ylfrb.rqh.bhxn.sv/~wfaryy/
-RJP
Ryan Pavlik
> Then again, I'm still having some difficulties envisioning a framework
> for the game that would give enough rope for those extending the game.
> The closest one that I can think of is a Inform-style action-based
> system. Might still be too difficult to integrate the new artifact
> sword you added that slays some certain critters, and the new almost-
> critter that someone else made. You'd need an ungodly amount of flags
> for that...
Nope, OOP to save the day. Make a new object, put it in the game.
In pseudo-C++, make a magic sword:
class MagicSword : Sword, MagicItem {
...
}
You get the picture. Add a class, it becomes available in the game,
place the object where you want it. Simple. Totally extensible. :)
Juho Snellman
>Exactly that. The basic stuff that handles all the networking et al. is
>all in C. Everything else is in the language of choice (everything from
>Map objects which contain what you actually see, to characters and inventory
>stuff).
Yeah, this is really the more feasible way for a new project. It does
move the hardware requirements up though, which would really suck
for those 486-owners whose only joy are new roguelikes :)
>Also, I originally planned to have it *all* in C, and do have a bit
>of a codebase in C already. If it comes down to it, I won't hesitate
>to ditch it.
I think that everyone reading this has already thrown out five times
more code then they currently have in their project :) And a quick
and dirty translation could be done very quickly I think.
>This is especially the case when considering threading, which alone is
>impossible with any embeddable scripting language I know of. Make
>two threads and try to use the interpreter in both... nice segfault.
I must admit that I really don't see any advantage of threading in
a roguelike. Well, maybe you could start running monster AI in a
separate thread, now that I think about it. Would be horribly complex
to balance it correctly, though. I can already think of the abuses
following from monster intelligence depending on the speed that the
player makes his decisions. And at the same time the benefits from
having the separate thread for AI would be the fact that you could give
it time to think.
>AFAIK, S-lang isn't a full enough language to do much more than
>basic option processing. We need a robust language here. :)
Certainly if we are talking about a sole implementation language.
(Followups set to devel)
Linley Henzell
> <tkat...@cs.purdue.edu> wrote:
> >In article <slrn72hnnp...@melkki.cs.Helsinki.FI>,
> >codes withuot indenting blocks?)
>
Hey, I never had to indent in C64 BASIC. So why should I change my
programming style just for C?
Linley
William Tanksley
>Ivan Igor Tkatchev (tkat...@cs.purdue.edu) wrote:
>>Programmers think of blocks in terms of whitespace, not braces. The braces
>>are there to guide the dumb parser. (Unless you know of someone who
>>codes withuot indenting blocks?)
>Have you seen Zangband's code yet? Check out the variety of indentation
>levels. (I may not have preserved all the original tabs/spaces. The
>you'll see that almost nothing lines up correctly.)
[huge snip of horrible indentation standardization problems]
>This is from version 2.1.1b, which is admittedly not the latest. I'm not
>criticizing either Topi or Robert. Just pointing out that *in real
>life*, when multiple people work on code, the indenting isn't likely to
>be consistent. If indenting actually affects the interpretation of the
>code by the parser, it sounds like a disaster waiting to happen to me.
Wrong. In C or any language which doesn't notice the interpretation, it's a
disaster waiting to happen. Years later, when all the current programmers
have moved on, some poor schmoe will have to modify that code, and he'll
have a million other things to do as well (all of them indented that
poorly), and he'll make some mistakes. And those mistakes will be invisible
to everyone but the compiler, and maybe the compiler will mistakenly think
thay're all right.
In Python, it's a minor problem which gets fixed as soon as it occurs -- and
it NEVER gets that bad, because code that bad would never have run.
>But then, I've never used Python, so maybe there's some sort of sanity
>check...?
There are several. Tabnanny is built into the compiler, and it can be set
to warn or give errors whenever it detects any combination of tabs and
spaces which could possibly result in different indentations under different
tabsizes. In general, though, it doesn't matter; the guidelines are very
loose, and I've never heard of anyone actually having problems with them,
even with multiple programmers and so on. If your code produces a bug, you
fix it. No problem.
>Oh, here's something else to send everyone screaming in horror:
> *variable-width fonts*
>Ponder that for a moment. The correlation between variable-width fonts
>and clueless Windoze programmers is extremely high. If Python were more
>popular, you'd be seeing code snippets that look like Angband character
>dumps after someone decides to edit them in their variable-width-font
>news reader....
Er... You mean the opposite. If Python were popular, you wouldn't see ANY
of those, because they would not only be unmaintainable, they plain wouldn't
work. C is popular, and you STILL don't see these, because people take some
pain to indent correctly. This is true even though it doesn't matter to C.
>Note follow-ups.
Sorry. My ISP seems to have dropped that -- I'll fix it before my next post
in this thread (if I ever make another).
>"Daddy, why do those people have to | Greg Wooledge
> use Microsoft Windows?" | wool...@kellnet.com
>"Don't stare, son; it's not polite." | http://www.kellnet.com/wooledge/
-Billy (someday the world will be free to use an operating system which is
both useful and reliable. That OS will be free software, or at least open
source)
Thomas Kilburn
wrote:
>Juho E Snellman <jsn...@lyseo.edu.ouka.fi> wrote:
><major snip>
>> Then again, I'm still having some difficulties envisioning a framework
>> for the game that would give enough rope for those extending the game.
>> The closest one that I can think of is a Inform-style action-based
>> system. Might still be too difficult to integrate the new artifact
>> sword you added that slays some certain critters, and the new almost-
>> critter that someone else made. You'd need an ungodly amount of flags
>> for that...
>
>Nope, OOP to save the day. Make a new object, put it in the game.
>In pseudo-C++, make a magic sword:
>
>class MagicSword : Sword, MagicItem {
> ...
>}
>
>You get the picture. Add a class, it becomes available in the game,
>place the object where you want it. Simple. Totally extensible. :)
I dunno, you're starting to break the is-a/has-a argument. What is a
magic sword but a sword with an enchantment on it. Instead of
creating a new kind of weapon class, why not another class to give the
sword modifiers (warning: pseudocode ahead)
--------------------------------------------------------------------------
//definition of an enchantment
class MagicEffect {
private:
int EffectType;
int EffectQuantity;
int Duration;
public:
... //accessors, mutators, Constructors, the whole shebang
}
---------------------------------------------------------------------------
The member EffectType tells what kind of magical enhancement that the
effect object represents. For weapons, the most appropriate ones
would probably be:
Attributes: Alter the wielders stats.(Includes to-hit/damage mods)
AddDamage: Adds magical damage to attack
Resistance: Gives the wielder resistance against certain attacks.
Vulnerability: Like above, only in the other direction
Ability: Give the wielder a new power/skill;
Trigger: Activates a game event under certain circumstances
Timer: Activates a game event every number of turns
Special: Things not covered under the preceding (curses, slay
<species>, etc.
The member EffectQuantity would be used either to denote the value of
adjustment (in the case of Attributes), or as a specifier for the
other kinds of events (a bytecode for resistance, vulnerability, and
addDamage, a number representing the power gained with an Ability kind
of MagicEffect, etc.)
The Member duration would determine how long the MagicEffect would
last (in terms of game turns) This would allow for the granting of
godlike weapons which after a while would become a bit more
manageable. Set it to -1, and the effect is permanent.
Weapons would have in their definition a data member which would hold
a listing of these effect members (More p-code)
-----------------------------------------------------------------------------------------------
class Weapon {
private:
EffectList * MyEffects;
...
public:
...
}
----------------------------------------------------------------------------------------------
Whether you use a template list class or an hand-crafted list class is
up to you. Whenever you wielded the weapon, the game should check the
effect list, and give the character the various weals and woes as held
within the EffectList. Stat bonuses will be easily apparent, but the
once every 1000 turn death storm spell would be less apparent. Magic
Effects which only occur in combat could be checked with if statements
against the weapons effects during damage-dealing phase . . . (where
it get's extremely ugly . . . least the way I'm trying to implement it
:)
--------------------------------------------------------------------------------------------------------
If Hit:
If (Weapon->EffectList.search(Effect::ADD_DAMAGE)) Then
{
SWITCH:
CASE (Player->EffectList.search(Effect::RESIST) .AND.
Weapon->EffectList.search(Effect::ADD_DAMAGE))
== 0:
damage=weapon damage + (magic damage / 2);
CASE (Player->EffectList.search(Effect:VULNERABLE) .AND.
Weapon->EffectList.search(Effect::ADD_DAMAGE))
==0:
damage=weapon damage + (magic damage * 2);
DEFAULT:
damage=weapon damage+ magic damage;
}
Else
damage=weapon damage;
--------------------------------------------------------------------------------------------------------
You'd have to add other switches for the other effect types, but
hopefully the basic idea does come through. For AddDamage,
Vulnerability, and Resistance, I used the same bytecode system for all
three. The pseudosystem above doesn't allow for multiple checks on
resistances, nor for other special abilities (that's the ugly I
mentioned earlier.)
The same enchantment system could be used on armor, rings, magic
items, and even people (That's the main reason why duration is there).
This keeps you from having to recode MagicAxe, MagicGlaive, and
MagicPickAxe, which is what would seem to be necessary in the
previously proposed method. The downside to this method is increased
overhead (checks for Effects when items initially worn, a really scary
damage system, etc.). Also, you really have to watch out for
conserving memory as it would be easy to waste.
Anyways, hope that my rant is useful to somebody. Checked the
newsgroup late at night after drinking a 24 pack of Doctor Pepper. No
way I'm going to be able to go to sleep tonight :)
Sincerely
**********************************************************************
* Thomas Kilburn * "Why am I sitting on a mind flayer?!?" *
* a.k.a * "Don't lose the horse! It's rented!" *
* Crooknose Grippewalle * "That's the third squire I've lost today!" *
**********************************************************************
>
>> --
>> Juho Snellman
>> Zvahyyn rv byr xbgvfvihn bfbvggrrffn uggc://jjj.ylfrb.rqh.bhxn.sv/~wfaryy/
>
> -RJP
Klaus Schilling
> > I'm pretty certain that implementing a roguelike in would be as
> > plausible in perl, Python or Scheme. There might be small features
> > or mis-features in all of them that help or hinder, but they really
> > are not significant in the scope of the whole project.
>
> Considered scheme, but I can't find a satisfactory implementation.
> Wish I could embed common lisp... ;)
I use guile-scheme for my game.
Klaus Schilling
Ryan Pavlik
> On 18 Oct 1998 15:02:50 -0800, Ryan Pavlik <rp...@localhost.blarg.net>
> wrote:
<snippage>
>> for that...
>>
>>Nope, OOP to save the day. Make a new object, put it in the game.
>>In pseudo-C++, make a magic sword:
>>
>>class MagicSword : Sword, MagicItem {
>> ...
>>}
>>
>>You get the picture. Add a class, it becomes available in the game,
>>place the object where you want it. Simple. Totally extensible. :)
> I dunno, you're starting to break the is-a/has-a argument. What is a
> magic sword but a sword with an enchantment on it. Instead of
> creating a new kind of weapon class, why not another class to give the
> sword modifiers (warning: pseudocode ahead)
I personally don't think so... and what you say below fits nicely into this
scheme too. A MagicItem has MagicEffects, right? :) A Wand of Wishing for
instance is a MagicItem with a MagicEffect that grants a wish... etc.
Now sure, you could argue that a MagicItem is any item with a MagicEffect,
and you don't need MagicItem at all, since it's implied, but there are
uses for it. An item needs power, charges/MP, etc. stored in a general way.
<actual content, which is very good, snipped and saved>
> Sincerely
> **********************************************************************
> * Thomas Kilburn * "Why am I sitting on a mind flayer?!?" *
> * a.k.a * "Don't lose the horse! It's rented!" *
> * Crooknose Grippewalle * "That's the third squire I've lost today!" *
> **********************************************************************
--
-RJP
Ryan Pavlik
> Ryan Pavlik <rp...@localhost.blarg.net> writes:
<snip>
>>
>> Considered scheme, but I can't find a satisfactory implementation.
>> Wish I could embed common lisp... ;)
> I use guile-scheme for my game.
>
I don't consider it satisfactory, for a few reasons. Mostly, it's plain slow.
For a single-player game this wouldn't be a big problem, but when you want to
support several hundred simultaneous players, it's an unfortunate issue.
Second is I don't like it's object system. Multiple inheritence is something
I'm taking advantage of, since this is a shining example of where it helps.
(Note: yes, it can be done with single. This is not the point. I could also
write it in PostScript, this is not the point either.)
Thirdly, the documentation is rather sadly lacking...
> Klaus Schilling
--
-RJP
Thomas Kilburn
wrote:
>Thomas Kilburn <pala...@airmail.net> wrote:
>> On 18 Oct 1998 15:02:50 -0800, Ryan Pavlik <rp...@localhost.blarg.net>
>> wrote:
>
><snippage>
>>> for that...
>>>
>>>Nope, OOP to save the day. Make a new object, put it in the game.
>>>In pseudo-C++, make a magic sword:
>>>
>>>class MagicSword : Sword, MagicItem {
>>> ...
>>>}
>>>
>>>You get the picture. Add a class, it becomes available in the game,
>>>place the object where you want it. Simple. Totally extensible. :)
>
>> I dunno, you're starting to break the is-a/has-a argument. What is a
>> magic sword but a sword with an enchantment on it. Instead of
>> creating a new kind of weapon class, why not another class to give the
>> sword modifiers (warning: pseudocode ahead)
>
>I personally don't think so... and what you say below fits nicely into this
>scheme too. A MagicItem has MagicEffects, right? :) A Wand of Wishing for
>instance is a MagicItem with a MagicEffect that grants a wish... etc.
Actually, OO has a different definition depending upon who you talk
to. An IMHO should have been in front of mys statement and I do
apologize for the rudeness of the statement.
>Now sure, you could argue that a MagicItem is any item with a MagicEffect,
>and you don't need MagicItem at all, since it's implied, but there are
>uses for it. An item needs power, charges/MP, etc. stored in a general way.
Actually, I've been staying away from limited use items (Probably just
a subconscious urge brought about by many many useless wands and
scrolls :) When I finally get my act into gear on that part, I'll
have to write new classes for scrolls, wands, magical focusing
devices, the Ronco Automatic Monster Shredder 2000 (c)(R) 8-|,
elemental summoning rocks, etc. You could easily go your way, start
off with these basics as descendants of MagicItem, then work to making
other classes Magic-al. Too much extra coding for my personal tastes
though (not to mention multiple inheritance gives me gas, despite its
benefits :)
><actual content, which is very good, snipped and saved>
>
**********************************************************************
Ryan Pavlik
> On 19 Oct 1998 10:21:05 -0800, Ryan Pavlik <rp...@localhost.blarg.net>
> wrote:
<snip>
>>I personally don't think so... and what you say below fits nicely into this
>>scheme too. A MagicItem has MagicEffects, right? :) A Wand of Wishing for
>>instance is a MagicItem with a MagicEffect that grants a wish... etc.
> Actually, OO has a different definition depending upon who you talk
> to. An IMHO should have been in front of mys statement and I do
> apologize for the rudeness of the statement.
Oh bleh that wasn't rude at all. ;) I know there are a few different views of
the way OO design 'should be done'. This is my personal preference; it seems
to mirror the natural world more closely...
>>Now sure, you could argue that a MagicItem is any item with a MagicEffect,
>>and you don't need MagicItem at all, since it's implied, but there are
>>uses for it. An item needs power, charges/MP, etc. stored in a general way.
> Actually, I've been staying away from limited use items (Probably just
> a subconscious urge brought about by many many useless wands and
> scrolls :) When I finally get my act into gear on that part, I'll
> have to write new classes for scrolls, wands, magical focusing
> devices, the Ronco Automatic Monster Shredder 2000 (c)(R) 8-|,
> elemental summoning rocks, etc. You could easily go your way, start
> off with these basics as descendants of MagicItem, then work to making
> other classes Magic-al. Too much extra coding for my personal tastes
> though (not to mention multiple inheritance gives me gas, despite its
> benefits :)
Hmm. I don't see how there's a lot of extra coding.. mostly I code the basics
first (various weapon types, magic types, etc.) then go for the specifics by
putting the other classes together. Again, this just seems 'natural' to me;
that's how I think about things. :)
--
-RJP
Laurence Withers
From: Ryan Pavlik <rp...@localhost.blarg.net>
Time: Sun, 18 Oct 1998, 14:55:21
>This is especially the case when considering threading, which alone is
>impossible with any embeddable scripting language I know of. Make
>two threads and try to use the interpreter in both... nice segfault.
I'm using a PC-specific (DJGPP-specific, I believe) scripting language
called SeeR for my game. It does support multithreading (considering I'm
writing most of the game in C++, and each object has its own code, it
would be kind of difficult if it didn't...)
Bye for now,
--
Laurence Withers, mailto:lwit...@lwithers.demon.co.uk
Integrated Peripherals Operating System Project Leader || OPES Project
Projects' homepage is at: http://www.lwithers.demon.co.uk/ Leader
shang.re...@st.jyu.fi.edu
Organization: University of Jyvaskyla, Finland
<crossposted to r.g.r.development>
Thomas Kilburn <pala...@airmail.net> wrote:
> I dunno, you're starting to break the is-a/has-a argument. What is a
> magic sword but a sword with an enchantment on it. Instead of
> creating a new kind of weapon class, why not another class to give the
> sword modifiers (warning: pseudocode ahead)
> --------------------------------------------------------------------------
> //definition of an enchantment
> class MagicEffect {
> private:
> int EffectType;
> int EffectQuantity;
> int Duration;
> public:
> ... //accessors, mutators, Constructors, the whole shebang
> }
Instead of using the EffectType attribute, I think that a more
object-oriented way of doing this would be to inherit the different kinds
of magical effect from the MagicEffect base class. So:
class MagicEffect {
private:
/* ... some attributes common to all effects, duration might be one of
these, as well as the 'owner' of the effect (usually an object). */
public:
/*
The MagicEffect could have virtual methods that apply the effect in
various situations, e.g.
virtual void effectOnWield();
virtual void effectOnWear();
virtual void effectOnActivate();
virtual void effectOnAttack();
etc...
*/
};
class ME_AddDamage : MagicEffect {
/*
Maybe attributes like amount of damage and damage type (fire, frost,
etc.).
*/
public:
virtual void effectOnAttack(); // override the relevant methods
};
class ME_IncAttribute : MagicEffect {/*...*/};
class ME_Resistance : MagicEffect {/*...*/};
etc...
In this approach, you'll have to define a lot of new classes, but still it
seems to me like a cleaner way to do it.
<------------------------------------------------------------>
< Sami Hangaslammi shang @ st (dot) jyu (dot) fi >
< University of Jyväskylä, Faculty of Information Technology >
<------------------------------------------------------------>
athol-brose
William Tanksley wrote:
>Here's some C.
>
>if (something)
> if (something_else)
> do_other();
>else do_this();
>
>In Python, this code means exactly what it says. In Perl, of course, it's
>impossible because I didn't put in the curly braces (good for Perl, that
>reduces ambiguity even at the expense of more typing). In C, it actually
>means:
>
>if (something)
> if (something_else)
> do_other();
> else do_this();
>
>Note the difference on the last line?
There wouldn't have been a problem if the programmer had used
braces. (I always use braces in C/C++; it reduces a lot of errors like
that one.
if (something) {
if (something else) {
do_other();
}
} else {
do_this();
}
Clear and unambiguous. Also ready to insert more code into the ifs
without reformatting, which we all know happens all the time :)
Sorry; I won't contribute any more to this particular holy flamewar!
--
r. n. dominick -- cinn...@one.net
Daniel Ligon
wrote:
>
>Also, I originally planned to have it *all* in C, and do have a bit
>of a codebase in C already. If it comes down to it, I won't hesitate
>to ditch it.
>
>impossible with any embeddable scripting language I know of. Make
>two threads and try to use the interpreter in both... nice segfault.
The latest perl, version 5.005, can be compiled with support for
threads. However, for now, threading is considered an experimental
feature.
--
Good hunting, Brother.
Daniel Ligon
mak...@qis.net
Ryan Pavlik
> In rec.games.roguelike.development, Ryan Pavlik <rp...@localhost.blarg.net>
> wrote:
>>This is especially the case when considering threading, which alone is
>>impossible with any embeddable scripting language I know of. Make
>>two threads and try to use the interpreter in both... nice segfault.
> The latest perl, version 5.005, can be compiled with support for
> threads. However, for now, threading is considered an experimental
> feature.
Yeah, I've got 5.005_51 and 5.005_02 installed here, and however experimental,
threads work fine. Doing stuff like 'async { block; };' is very cool.
However, this is a slightly different thing than trying to call an embedded
interpreter from two different threads... which as of yet doesn't work in any
embedded language I know of.
--
-RJP