Guild - YABDR??

[Antoine]

Archived from groups: rec.games.roguelike.development (More info?)

Antoine wrote:
> Antoine wrote:
> > Hi RGRDers,
> >
> > After finishing the Quickband project I've come back to Guild, and am
> > wondering what to do with it.
> >
> > Guild is looking alarmingly like YABDR (yet another born dead
> > roguelike) at this stage. I'm not quite sure why, but it's received
> > very little attention since it was first released - no discussion on
> > RGRD or RGRM to speak of, only a few emails and not one single YAVP. In
> > fact, I'm not sure if anyone but me has ever actually completed the
> > whole game (or even the second quest???)
> >
> > I'd appreciate any feedback on
> > -why Guild didn't take off
> > -from those who did try it, what they liked and/or disliked about it
> > -how the game could be improved to be more successful, or
> > -how the game could be marketed to be more successful...
> >
> > A.
>
> Thanks for the feedback, all,
>
> Here is my plan for getting Guild back on the rails - some small tweaks
> and some quite big changes. Any comments appreciated.
>
> 1. Publish the source (easy enough, I could put that on guildgame.com
> today)
>
> 2. Put frequent updates on RGRD describing new / interesting features
>
> 3. Fix the fatal 'wield' bugs
>
> 4. Reduce resource constraints (cheaper potions, higher healing limit
> in one dungeon trip, more fountains)
>
> 5. Less junk in drops?
>
> 6. Remove the mechanic which 'exhausts' dungeon levels that you visit
> often - it makes the dungeon too empty
>
> 7. Simplify NPC control - reduce the number of 'orders' (and perhaps
> display the current 'order' on the main console). Put one order
> instructing the whole party to target a specific monster, another one
> telling them to take up positions that you will specify. Consider
> disassociating orders from the sound system, which would mean you could
> give orders to a character who was far from your party leader.
>
> 8. Allow unarmed characters to punch and throw unlimited rocks - would
> reduce irritating 'nothing to wield' messages
>
> 9. Move to a graphic tile-based map. I was talking to a guy who was
> going to help me out with this by producing a tileset - must get back
> in touch... failing that I could use one of the standard tilesets.
>
> 10. In the process, move to a multi-platform set of libraries, thus
> allowing Linux and Mac ports
>
> 11. (and I'd want coder help with this) Move to more of a GUI, with
> graphic interfaces for inventory management, etc, and mouse control on
> the main map.

14. More of a sense of a 'goal' in the early game

15. All priests start with Cure Wounds

16. Somewhat more open dungeon layouts with more 2-wide corridors

17. More standard roguelike keybindings (have to figure out what that
is though!)

A.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

At 11 Sep 2005 13:57:12 -0700,
Antoine wrote:

> 7. Simplify NPC control - reduce the number of 'orders' (and perhaps
> display the current 'order' on the main console). Put one order
> instructing the whole party to target a specific monster, another one
> telling them to take up positions that you will specify. Consider
> disassociating orders from the sound system, which would mean you could
> give orders to a character who was far from your party leader.

Ever played Seiken Densetsu 3 (aka Secret of Mana 2)?


--
Radomir `The Sheep' Dopieralski @**@_
(..) 3 Bee!
. . . ..v.vVvVVvVvv.v.. .

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

At 11 Sep 2005 14:16:56 -0700,
Antoine wrote:

> Radomir 'The Sheep' Dopieralski wrote:
>> Ever played Seiken Densetsu 3 (aka Secret of Mana 2)?
> No? Tell me about it.

I'll assume this is not sarcasm 😉

Well, it's an action RPG for SNES. You control a 3-member party -- when
exploring all the characters merge into one in standard way in this kind
of games, so no problem here. During battles, however, you only control
one character, and the other two fight automatically. You can switch
between them to make them do something special, but most of the time
they're on their own. You can even make your main character fight
automatically (just hold the attack button all the time).

Now, in the menu screen you've got a set of options controling how the
characters are supposed to fight. These are pretty simple and ilustrated
with 'formation' images, so that you can easily 'get it'.

Here's a screenshot:
<http://atos.wmid.amu.edu.pl/~sheep/seiken3.png>

You can select which techniques should be used by the characters (there
are two special attacks for them, one weaker and one stronger, but taking
more hits to charge), and also which monster they should attack (assist
one of the two other characters or pick an enemy that's not fighting any
of them).
--
Radomir `The Sheep' Dopieralski @**@_
(@a) 3 Be?
. . . ..v.vVvVVvVvv.v.. .

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

> 7. Simplify NPC control - reduce the number of 'orders' (and perhaps
> display the current 'order' on the main console). Put one order
> instructing the whole party to target a specific monster, another one
> telling them to take up positions that you will specify. Consider
> disassociating orders from the sound system, which would mean you could
> give orders to a character who was far from your party leader.

Definitely disassociate orders from the sound system--while it was an
interesting idea, you can 'order' any character at any range by
switching to them anyway, so the sound system limitations feel more
like an annoyance than a real game mechanic.

Some other suggestions: Spellcasters should perhaps remember their
orders with regards to spellcasting after leaving the dungeon; it's
kind of annoying to have to give them the same orders every time if
there's a spell you don't want them to cast or if you don't want them
to cast spells on their own. Some other behavior orders might also
make sense as 'persistant' ones, too.

Possibly there should be an order to have someone cast a specific spell
remotely, without having to switch to them.

Oh, also. If the player hits the 'O'rder key and then a letter-key
(without first hitting a number to choose who they're ordering around),
the corresponding order should be given to the entire party. This
would let players order their entire party with fewer keystrokes. Of
course, this wouldn't work with orders that are given with a number,
but it would still be a nice feature.

> 9. Move to a graphic tile-based map. I was talking to a guy who was
> going to help me out with this by producing a tileset - must get back
> in touch... failing that I could use one of the standard tilesets.

This is the only one I'm not quite so sure about. Personally, I prefer
the ascii roguelike look, and I know that I'd rather play using an
ASCII version if one was available. I definitely don't think you
should use a standardized tileset.

And you have to understand that the people who are asking for graphics
aren't just asking for tiles. They want games that *use* those
graphics, games with unique ways of displaying things and detailed
graphical maps and similar things--gradients for light radiuses, for
instance. They want simple mouse controls with no keys to remember.
They want, basically, something significently different from what Guild
is now; while all the other suggestions come down to relatively simple
improvements or changes, this is something fairly radical. It might be
interesting if Guild could go down that route (and it would certainly
provide an opportunity to add a unique look-and-feel to the game, which
might help with the "generic setting" problem), but I don't think it's
worth it if it's only going to go halfway.

Basically, I don't think you should bother with graphics unless you're
sure that (1) you're going to use them, and (2) you're going to make
them look good.

Of course, a purely optional tileset that doesn't really change the
underlying mechanics might be sensible if it doesn't require much work,
but I doubt it would really make the people who want graphics happy,
and the people who like ascii would just ignore it.

 

[Antoine]

Archived from groups: rec.games.roguelike.development (More info?)

Aquillion wrote:
> > 7. Simplify NPC control - reduce the number of 'orders' (and perhaps
> > display the current 'order' on the main console). Put one order
> > instructing the whole party to target a specific monster, another one
> > telling them to take up positions that you will specify. Consider
> > disassociating orders from the sound system, which would mean you could
> > give orders to a character who was far from your party leader.
>
> Definitely disassociate orders from the sound system--while it was an
> interesting idea, you can 'order' any character at any range by
> switching to them anyway, so the sound system limitations feel more
> like an annoyance than a real game mechanic.

I feel in two minds about this. The sound-based order system, for those
who haven't experienced it, worked like this: to order one of your PCs,
your leader would select 'whisper', 'order' or 'yell', making a soft,
moderate or loud call respectively. If that sound could travel through
the dungeon far enough for the PC to hear it, then the order would take
effect; if not, then you were wasting your time. (Unless you had the
rare and valuable Helm of Telepathy...)

This had several advantages. It meant that characters with a low
Perception would sometimes not hear you, especially if they were
wearing a heavy helmet, which seems kinda good. It meant that you
couldn't order characters around from across the entire width of the
dungeon. It meant that when you were trying to be sneaky, you'd have to
'whisper' or stop giving orders entirely. It meant that deaf characters
went out of control.

On the other hand it was a bit of a pain at times, sometimes left you
wondering 'why didn't they do what I told them?', and wouldn't fit well
with a simpler orders interface, especially a point and click one.

Not sure...

A.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

> 7. Simplify NPC control - reduce the number of 'orders' (and perhaps
> display the current 'order' on the main console). Put one order
> instructing the whole party to target a specific monster, another one
> telling them to take up positions that you will specify. Consider
> disassociating orders from the sound system, which would mean you could
> give orders to a character who was far from your party leader.

Also, I meant to say, I'm not sure which orders you mean to remove...
Most of them seem pretty important to me.

Is there any reason why the player would have a character who could be
sneaking not sneak? Maybe the sneak-related orders should be removed,
and any character who can sneak should sneak. Of course, since you
can't sneak while carrying a light source, players could control which
of their characters sneak by equipping/unequipping a glowing stone or
something similar.

Likewise, the Light/Extinguish commands might not be necessary... how
often do players use torches, anyway? I always just used glowing
stones when I wanted a light, they're not too hard to find. Actually,
I never used the change weapon commands, either...

I don't know if this needs a command, but one manuver that I often had
trouble getting my characters to fall into was guarding an entranceway.
Often, the player will want to position their characters so that two
or three of them can gang up on a line of monsters emerging from a
narrow hallway or stepping through a doorway; the AI does not make it
easy to do this. If you walk up to a door, usually one of your other
party members will step into it, fighting the monsters one at a time
instead of ganging up on them. Mages have a tendency to take
front-line spots that ought to have gone to a more melee-capable
character. Sometimes mages will step into the doorway... etc, etc,
etc. Some of this could be fixed with general AI improvements (e.g.,
mages wielding a wand shouldn't step next to a monster if they'd be
taking the place of another party member who could be using a melee
attack, or characters shouldn't step into a narrow corridor on their
own initative if the PC is standing just outside it.)

One other minor unrelated improvement I've been meaning to suggest:
Currently, if you have a thief equipped with a bow and walk into to a
monster to pickpocket it, the game will force you to switch back to
your melee weapon first. This doesn't make much sense.

 

[Antoine]

Archived from groups: rec.games.roguelike.development (More info?)

Aquillion wrote:
> > 7. Simplify NPC control - reduce the number of 'orders' (and perhaps
> > display the current 'order' on the main console). Put one order
> > instructing the whole party to target a specific monster, another one
> > telling them to take up positions that you will specify. Consider
> > disassociating orders from the sound system, which would mean you could
> > give orders to a character who was far from your party leader.
>
> Also, I meant to say, I'm not sure which orders you mean to remove...
> Most of them seem pretty important to me.

With less restrictive mana limits, I think I could go to a single spell
command per spellcaster, listing the spells they may or may not cast.

I was going to remove the light source ones as well, making them
implicit in other commands.

And introduce two separate keys for 'take up positions which I will
specify' and 'your main enemy is monster X', which allows some of the
main order list to be removed.

> Is there any reason why the player would have a character who could be
> sneaking not sneak?

ALlows them to start casting spells and doing other normal stuff...


> I don't know if this needs a command, but one manuver that I often had
> trouble getting my characters to fall into was guarding an entranceway.

Yes. This needs to be improved (hence the 'take up positions' above).

> One other minor unrelated improvement I've been meaning to suggest:
> Currently, if you have a thief equipped with a bow and walk into to a
> monster to pickpocket it, the game will force you to switch back to
> your melee weapon first. This doesn't make much sense.

Fair call, will change if I remember.

A.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Antoine a écrit :
> Aquillion wrote:
>
>>>7. Simplify NPC control - reduce the number of 'orders' (and perhaps
>>>display the current 'order' on the main console). Put one order
>>>instructing the whole party to target a specific monster, another one
>>>telling them to take up positions that you will specify. Consider
>>>disassociating orders from the sound system, which would mean you could
>>>give orders to a character who was far from your party leader.
>>
>>Definitely disassociate orders from the sound system--while it was an
>>interesting idea, you can 'order' any character at any range by
>>switching to them anyway, so the sound system limitations feel more
>>like an annoyance than a real game mechanic.
>
>
> I feel in two minds about this. The sound-based order system, for those
> who haven't experienced it, worked like this: to order one of your PCs,
> your leader would select 'whisper', 'order' or 'yell', making a soft,
> moderate or loud call respectively. If that sound could travel through
> the dungeon far enough for the PC to hear it, then the order would take
> effect; if not, then you were wasting your time. (Unless you had the
> rare and valuable Helm of Telepathy...)
>
> This had several advantages. It meant that characters with a low
> Perception would sometimes not hear you, especially if they were
> wearing a heavy helmet, which seems kinda good. It meant that you
> couldn't order characters around from across the entire width of the
> dungeon. It meant that when you were trying to be sneaky, you'd have to
> 'whisper' or stop giving orders entirely. It meant that deaf characters
> went out of control.

When you want to be sneaky, you issue hand coded orders to those in
visual range. For operations in dangerous places you would usualy avoid
losing visual contact with your friends. That way, it's easier to
distiguish friend from foo : just shoot anything that moves and isn't
your friends

> On the other hand it was a bit of a pain at times, sometimes left you
> wondering 'why didn't they do what I told them?', and wouldn't fit well
> with a simpler orders interface, especially a point and click one.
>
> Not sure...

The simple interface wouldn't be what would bother me the least. I think
the 'why didn't they do what I told them?' is the main problem. You can
add a "roger" message from those who heard you for example or you can
let the game select the correct order volume according to the distance.
That way the player will never issue an order that wasn't heard and
he'll know easily how loud he must say it.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Antoine wrote:
> Aquillion wrote:
>
>>>7. Simplify NPC control - reduce the number of 'orders' (and perhaps
>>>display the current 'order' on the main console). Put one order
>>>instructing the whole party to target a specific monster, another one
>>>telling them to take up positions that you will specify. Consider
>>>disassociating orders from the sound system, which would mean you could
>>>give orders to a character who was far from your party leader.
>>
>>Definitely disassociate orders from the sound system--while it was an
>>interesting idea, you can 'order' any character at any range by
>>switching to them anyway, so the sound system limitations feel more
>>like an annoyance than a real game mechanic.
>
>
> I feel in two minds about this. The sound-based order system, for those
> who haven't experienced it, worked like this: to order one of your PCs,
> your leader would select 'whisper', 'order' or 'yell', making a soft,
> moderate or loud call respectively. If that sound could travel through
> the dungeon far enough for the PC to hear it, then the order would take
> effect; if not, then you were wasting your time. (Unless you had the
> rare and valuable Helm of Telepathy...)
>
> This had several advantages. It meant that characters with a low
> Perception would sometimes not hear you, especially if they were
> wearing a heavy helmet, which seems kinda good. It meant that you
> couldn't order characters around from across the entire width of the
> dungeon. It meant that when you were trying to be sneaky, you'd have to
> 'whisper' or stop giving orders entirely. It meant that deaf characters
> went out of control.
>
> On the other hand it was a bit of a pain at times, sometimes left you
> wondering 'why didn't they do what I told them?', and wouldn't fit well
> with a simpler orders interface, especially a point and click one.
>
> Not sure...

IMO, this is a really annoying feature. It is a cool feature, but still
annoying. In a party based game you should be able to give orders to any
of your party member without restrictions. I vote that you remove it.

> A.
>

/Björn

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Antoine wrote:
> > Is there any reason why the player would have a character who could be
> > sneaking not sneak?
>
> ALlows them to start casting spells and doing other normal stuff...

Possibly, then, there should just be a generic "follow me, but take no
action" type command which replaces the current thievery one; and make
it so characters always sneak if given the chance, but won't bother to
try and *stay* stealthy unless you ordered them to stay out of trouble.

After all, even if I order my thief to fire at will, I'd usually still
want them to be sneaking up until the point when they attack...
Likewise, even if I want my mage casting spells as necessary, it still
makes sense for him to sneak while moving around, so ambushes or
monsters attacking out of the shadows will be less likely to target
him.

Also, will thieves ever attempt backstabs on their own under the
current system? It seems like they should, but if ordering them to
sneak prevents them from attacking, then I guess they wouldn't.
Likewise, having them attempt to pickpocket monsters on their own could
sometimes be annoying, but it could also be funny at times.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

On 12 Sep 2005 02:30:58 -0700, "Antoine" <mail@guildgame.com> wrote:

>On the other hand it was a bit of a pain at times, sometimes left you
>wondering 'why didn't they do what I told them?', and wouldn't fit well
>with a simpler orders interface, especially a point and click one.
>
>Not sure...

In Guild, you're playing a party of adventurers, not an adventurer and
his pets/followers/mercenaries. Such a command system would be suitable
for a game in which you play a single character and have a number of NPC
followers, but when the party as a whole is supposed to be the PC, then
it is inappropriate.

--
R. Dan Henry = danhenry@inreach.com

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

In article <1126516904.789541.84660@g44g2000cwa.googlegroups.com>,
frogwind@gmail.com says...
>
> And you have to understand that the people who are asking for graphics
> aren't just asking for tiles. They want games that *use* those
> graphics, games with unique ways of displaying things and detailed
> graphical maps and similar things--gradients for light radiuses, for
> instance.

That's not necessarily the case at all. Of course it's nice to have
attractive graphic effects, but something like ZangbandTK has graphics
adequate for a roguelike. I think most who prefer tiles simply want a
dog and a dragon to be represented by pictures of a dog and a dragon,
rather than by a 'D'.

> They want simple mouse controls with no keys to remember.

That would obviously be good too, if the interface works, but it's
orthogonal to the issue of graphics. (I do think roguelikes should
usually use the arrow keys for movement, though I'm not convinced it is
necessary to resort to the keyboard for anything else.)

- Gerry Quinn

 

[skeksis]

Archived from groups: rec.games.roguelike.development (More info?)

"copx" <invalid@invalid.com> wrote in message
news:dfhinq$bb6$04$1@news.t-online.com...
>
> "Antoine" <mail@guildgame.com> schrieb im Newsbeitrag
> news:1125800713.947776.10180@g14g2000cwa.googlegroups.com...
> [snip]
>
> > -how the game could be improved to be more successful, or
>
> Graphics. There are probably only a few thousand people in the entire
world
> who play ASCII games.
>
> > -how the game could be marketed to be more successful...
>
> Put it on mainstream gaming sites (requires graphics).
>
>
> copx

Without meaning to sound dismissive or elitist, I think a large part of the
charm and atmosphere of many roguelikes lies in their visual minimalism. I
tend to turn all graphical features off in roguelikes in the same way that I
tend to turn off all shadows in multi-player FPS games; to allow greater
functional clarity. I for one would almost certainly be put off by graphics.
I guess it depends what kind of player you wish to attract.

--
Sig? What sig?

 

[Edward]

Archived from groups: rec.games.roguelike.development (More info?)

Gerry Quinn <gerryq@deletethisindigo.ie> wrote:
> orthogonal to the issue of graphics. (I do think roguelikes should
> usually use the arrow keys for movement, though I'm not convinced it is
> necessary to resort to the keyboard for anything else.)

I would agree that if you're going to have a mouse-driven interface,
it's good to have your other hand resting in only one place on the
keyboard, if you use it at all.

I'd still think it highly desirable to have the option of leaving both
hands on the keyboard and never being required to touch the mouse.

--
--jude hungerford.

 

[Antoine]

Archived from groups: rec.games.roguelike.development (More info?)

Antoine wrote:
> Antoine wrote:
> > Hi RGRDers,
> >
> > After finishing the Quickband project I've come back to Guild, and am
> > wondering what to do with it.
> >
> > Guild is looking alarmingly like YABDR (yet another born dead
> > roguelike) at this stage. I'm not quite sure why, but it's received
> > very little attention since it was first released - no discussion on
> > RGRD or RGRM to speak of, only a few emails and not one single YAVP. In
> > fact, I'm not sure if anyone but me has ever actually completed the
> > whole game (or even the second quest???)
> >
> > I'd appreciate any feedback on
> > -why Guild didn't take off
> > -from those who did try it, what they liked and/or disliked about it
> > -how the game could be improved to be more successful, or
> > -how the game could be marketed to be more successful...
> >
> > A.
>
> Thanks for the feedback, all,
>
> Here is my plan for getting Guild back on the rails - some small tweaks
> and some quite big changes. Any comments appreciated.
>
> 1. Publish the source (easy enough, I could put that on guildgame.com
> today)
>
> 2. Put frequent updates on RGRD describing new / interesting features
>
> 3. Fix the fatal 'wield' bugs
>
> 4. Reduce resource constraints (cheaper potions, higher healing limit
> in one dungeon trip, more fountains)
>
> 5. Less junk in drops?
>
> 6. Remove the mechanic which 'exhausts' dungeon levels that you visit
> often - it makes the dungeon too empty
>
> 7. Simplify NPC control - reduce the number of 'orders' (and perhaps
> display the current 'order' on the main console). Put one order
> instructing the whole party to target a specific monster, another one
> telling them to take up positions that you will specify. Consider
> disassociating orders from the sound system, which would mean you could
> give orders to a character who was far from your party leader.
>
> 8. Allow unarmed characters to punch and throw unlimited rocks - would
> reduce irritating 'nothing to wield' messages
>
> 9. Move to a graphic tile-based map. I was talking to a guy who was
> going to help me out with this by producing a tileset - must get back
> in touch... failing that I could use one of the standard tilesets.
>
> 10. In the process, move to a multi-platform set of libraries, thus
> allowing Linux and Mac ports
>
> 11. (and I'd want coder help with this) Move to more of a GUI, with
> graphic interfaces for inventory management, etc, and mouse control on
> the main map.
>
> A.

Hi,

Does anyone know a way in which I can extract this entire thread into a
text file, for later reference?

A.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Timothy Pruett wrote:
> Antoine wrote:
> > Hi,
> >
> > Does anyone know a way in which I can extract this entire thread into a
> > text file, for later reference?
>
> I'm not aware of any newsreader that comes with a feature to do that.
> The only way I can think of doing it would be to save all posts in the
> thread into their own text files (not sure if Thunderbird can do it all
> at once, but I'm pretty sure you can get nget to do it for you), and
> then just cat them all into one big file.

Go to Google Groups, view the messages as a thread, then copy all the
posts and paste them in a text editor. That's probably easier than
saving the posts individually.

- JH.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Antoine wrote:
> Hi,
>
> Does anyone know a way in which I can extract this entire thread into a
> text file, for later reference?

I'm not aware of any newsreader that comes with a feature to do that.
The only way I can think of doing it would be to save all posts in the
thread into their own text files (not sure if Thunderbird can do it all
at once, but I'm pretty sure you can get nget to do it for you), and
then just cat them all into one big file.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Joe Hewitt wrote:
> Timothy Pruett wrote:
>
>>Antoine wrote:
>>
>>>Hi,
>>>
>>>Does anyone know a way in which I can extract this entire thread into a
>>>text file, for later reference?
>>
>>I'm not aware of any newsreader that comes with a feature to do that.
>>The only way I can think of doing it would be to save all posts in the
>>thread into their own text files (not sure if Thunderbird can do it all
>>at once, but I'm pretty sure you can get nget to do it for you), and
>>then just cat them all into one big file.
>
>
> Go to Google Groups, view the messages as a thread, then copy all the
> posts and paste them in a text editor. That's probably easier than
> saving the posts individually.

With nget you could get it all done all at once. I'd say it's pretty
fast. You should be able to make it save all posts from the thread with
one line typed in the terminal, followed up by one more line using cat.
Granted, I haven't fiddled with nget in a long time, but I remember
their being easy ways of mass saving posts that fit certain criteria (by
thread, through filter, etc.).

Just to see, I went to Google Groups, to get an idea of how it would
look if he manually copied and pasted everything. Honestly, I was
rather surprised by the results, since copying and pasting it looked
rather nice in plain text, but it also added a more complete header at
the top of every post, providing a little bit too much information,
making it a bit of a chore to read. A fair amount of manual editing
would be required to make it comfortable to read.

Honestly, though, I'm not quite sure why Antoine thinks that saving the
entire thread to one huge text file would be a good thing. I suppose if
he wanted to print it out, but that seems kind of silly. If he wants to
save it all due to internet problems/concerns, I'd just make the thread
available for viewing offline, which you can do in Thunderbird in a few
seconds.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

On Fri, 23 Sep 2005 00:24:29 -0500, Timothy Pruett
<drakalor.tourist@gmail.com> wrote:

>Antoine wrote:
>> Hi,
>>
>> Does anyone know a way in which I can extract this entire thread into a
>> text file, for later reference?
>
>I'm not aware of any newsreader that comes with a feature to do that.

Agent will. I suspect any real newsreader (not a Microsoft virus
exchange program or web-browser afterthought or webpage claiming to be a
newsreader) will. However, his headers show he's using the second type
of quasi-newsreader and I don't have any advice for him. I just want to
point out that what you're assuming as exotic is pretty basic program
functionality.

--
R. Dan Henry = danhenry@inreach.com

 

[Antoine]

Archived from groups: rec.games.roguelike.development (More info?)

> [Antoine wrote]
> Here is my plan for getting Guild back on the rails - some small tweaks
> and some quite big changes. Any comments appreciated.
>
> 1. Publish the source (easy enough, I could put that on guildgame.com
> today)
>
> 2. Put frequent updates on RGRD describing new / interesting features
>
> 3. Fix the fatal 'wield' bugs

Incidentally, I have not encountered this bug (game crashes when you
try to wield something) myself. A bug report would be appreciated...

A.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

R. Dan Henry wrote:
> On 07 Sep 2005 13:22:17 +0100 (BST), David Damerell
> <damerell@chiark.greenend.org.uk> wrote:

[...]

> >It certainly makes sense to separate "wield" - what if you want to wield
> >something that isn't designed to be used as a weapon?
>
> Not just a theoretical consideration in Crawl, either. Magical staves
> and rods aren't "weapons", but must we wielded for effect. In fact, all
> the 'E'voked items must be wielded for use. And several spells require
> or benefit from wielding non-weapons.
>
> Wearing and putting on also work somewhat differently in Crawl, although
> whether this is of benefit is an open question.

Much though I love the Crawlster, I cannot -- and I daresay I know that
game as well as anyone -- think of a single benefit to separating W/T
from P/R, a single time where you would want to wear a necklace for a
hat or use your gloves as a ring or anything similar demanding the
separation. Nor is the collection of each sort of finery in one's
inventory large enough to reeeaally justify the "hey it's free
filtering!" argument. Maybe I'm just not thinking hard enough.

The worst bit is that you are much more likely to want to swap
jewellery than armour (jewellery is on average more likely to have
special effects without having an "undressing vulnerability window"),
but armour hogs W/T for itself and leaves the less comfortable (for us
terribly non-oldskool numpadders) P/R for jewellery.

e.