intelligent vs stupid slots

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

In some roguelikes items are intelligent. If you 'e'quip a weapon, it
appears in your weapon slot. If you 'e'quip boots, they appear on your
feet. And so on. Thanks to this, using the inventory screen does not
feel like you were dressing a paper doll.

In some roguelikes you decide what goes where. Doing obvious things
like putting on sandals takes at least two key presses, instead of
one. You gain two things: first, you feel like Rambo in the famous
equipping sequence (it was in Rambo, wasn't it?). Second, you can
equip a silver ring as a weapon to harm an enemy that is immune to
things other than silver - which is only an example of other cool,
unexpected features that might be possible with such a UI.

My game approached the magical point of no return, where I have to
choose one of these. Any thoughts?

regards,
Filip

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

Filip Dreger wrote:

> In some roguelikes items are intelligent. If you 'e'quip a weapon, it
> appears in your weapon slot. If you 'e'quip boots, they appear on your
> feet. And so on. Thanks to this, using the inventory screen does not
> feel like you were dressing a paper doll.
>
> In some roguelikes you decide what goes where. Doing obvious things
> like putting on sandals takes at least two key presses, instead of
> one. You gain two things: first, you feel like Rambo in the famous
> equipping sequence (it was in Rambo, wasn't it?). Second, you can
> equip a silver ring as a weapon to harm an enemy that is immune to
> things other than silver - which is only an example of other cool,
> unexpected features that might be possible with such a UI.
>
> My game approached the magical point of no return, where I have to
> choose one of these. Any thoughts?
>
> regards,
> Filip

Intelligent. It is a bad UI practice to ask a multiple choice question to a
user only to tell him after that 90% of the possible answers aren't
possible in fact. Unless you plan to create a meta UI game of course.

If you really want the special features of the out of place equip, you can
always provide a second equip command that does the "stupid slots" way.
Like e for "normal equip" and E for "stupid equip"

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

I like the idea to do both, where pressing "e" will put your sandals on
your feet, but pressing ALT-e (alt as in alternative, makes sense) asks
you where you want to equip it. The player then has the chance to come
up with a great idea, like equipping his silver-buckled-sandles in his
hand to wack the werewolf with. But of course, you if the player tries
to equip the sandles on, say, his head, you could simply reply with
"That is impossible".

It is rewarding for the player to think of a thing to do that isn't
obviously possible, like equiping the sandles in the hand. If you
explicitly give him/her the choice to equip it in his hand, then it's
not quite as rewarding.

Let the player try to do whatever the player wants, and just say no if
it's obviously impossible. More coding, but roguelike games are great
because of the huge amount of freedome players have in the game. Final
Fantasy doesn't have squat on NetHack!

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

Filip Dreger wrote:
> In some roguelikes items are intelligent. If you 'e'quip a weapon, it

> appears in your weapon slot. If you 'e'quip boots, they appear on
your
> feet. And so on. Thanks to this, using the inventory screen does not
> feel like you were dressing a paper doll.
>
> In some roguelikes you decide what goes where. Doing obvious things
> like putting on sandals takes at least two key presses, instead of
> one. You gain two things: first, you feel like Rambo in the famous
> equipping sequence (it was in Rambo, wasn't it?). Second, you can
> equip a silver ring as a weapon to harm an enemy that is immune to
> things other than silver - which is only an example of other cool,
> unexpected features that might be possible with such a UI.
>
> My game approached the magical point of no return, where I have to
> choose one of these. Any thoughts?

I think you should go with the first option. Leave the
wear-your-smoky-ring-on-your-left-leg stuff to Nethackers.

A.

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

Filip Dreger wrote:
> In some roguelikes items are intelligent. If you 'e'quip a weapon, it

> appears in your weapon slot. If you 'e'quip boots, they appear on
your
> feet. And so on. Thanks to this, using the inventory screen does not
> feel like you were dressing a paper doll.
>
> In some roguelikes you decide what goes where. Doing obvious things
> like putting on sandals takes at least two key presses, instead of
> one. You gain two things: first, you feel like Rambo in the famous
> equipping sequence (it was in Rambo, wasn't it?). Second, you can
> equip a silver ring as a weapon to harm an enemy that is immune to
> things other than silver - which is only an example of other cool,
> unexpected features that might be possible with such a UI.
>
> My game approached the magical point of no return, where I have to
> choose one of these. Any thoughts?

There are several approaches to equipping:

1) Verb Based

This is what Nethack uses. 'w' signals you will put something in your
hands. 'W' signals that you want to wear something. You thus have no
extra keypresses to wield your robe in your hands.

2) Slot Based

This is what ADOM uses, IIRC. You look at your character sheet and
select a slot, like the Right Hand. You then get a list of items you
can put in your Right Hand. (This can be thought of as the same as
verb based, except with one verb per slot...)

3) Noun Based

This seems to be what you are starting with. One selects an item and
Equips it, and the right thing happens.

POWDER is entirely noun based so uses this approach. However, this
doesn't stop you from equipping silver rings in your right hand.

You go to the Inventory Screen and select an item. You then choose
"Equip". The cursor moves to the "right" slot for that action and you
can hit [A] to do the expect thing. You can also, however, move the
cursor to another slot to do something unusual.

I don't know what you mean by "point of no return".

The real difficulty of allowing "Wield Anything" is making sure
wielding a Plate Mail doesn't give you massive AC, etc. (It did for
quite a while in POWDER :> )

The other difficulty is if you have overlay graphics - you need to
reposition the overlays to allow arbitrary equipping. I finally got
around to that in 065 in POWDER when I allowed anything to be equipped
in the left hand as well as the right.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)

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

The Sheep wrote:
> Dnia Fri, 22 Apr 2005 18:19:00 +0200,
> Filip Dreger napisal(a):
>
> > In some roguelikes you decide what goes where. such a UI.
> <snip>
> > My game approached the magical point of no return, where I have to
> > choose one of these. Any thoughts?
>
> I have established the idea of how I'm going to do it.
>
> I want to separate the items and their kinds (physical objects,
> with attributes light weight, size, material, looks, position, etc.),
> and the 'usages', being in fact things you can do with the items, and
> having things like AC bonus, damage bonus, magical effect, etc.
> The usages further separated from equipment slots, which are simply
flags
> telling whether your upper arm is already occupied.
>

Maybe flags aren't such a good idea? If you have alot of usages as
flags and most items only use then as a subset then maybe there's a
better way. I'm not sure what language your using, but if it can
refrence data structures you might consider giving each item a list or
array of properties. If your using c or c++ then you could just
refrence a list of structs. An example would be.

struct Property
{
const char * nameOfProperty;
const char * decriptionOfProperty;
int propertyIdentifier; // probably an enum
void propertyUsage(); // youcould script this depending on the
property
};

If you have a bunch of these then you'll have all the information for
all of the properties an item might have but only those properties that
it has. Voila, no more switch statements, just search the list for the
proper PropertyID and execute it's script. If you don't have scripting
this could be a good reason to put it in, or you could make a function
pointer (If your language of choice allows it).

> Now, you don't really use/equip items. You equip usages. The usages
> require certain slots to be free in order to be equipped.
>
> You can only have one usage of given kind -- something like usage
slots.
> But since an item can have multiple usages, you can equip one ad the
same
> item into many usage slots -- for example, you could have your dirk
> equipped as a weapon (equip it's `weapon' usage into weapon usage
slot),
> and at the same time as a tin opener (equip it's 'open tin' usage
into
> tin opener slot).
>

I think your over analyzing here. Maybe you should take a step back and
consider creating a basic inventory with only one item in mind. Then
after you have that simple scenario working add another item of a
different sort and adapt as necessary. I know what it's like to start
analyzing and try to figure every nuance. Waterfall thinking can be
exciting but hard to recover from if something dosen't go right.
Believe me I know, I've been through a total of 15 rewrites, because of
this. Just something to consider.

> The items itself are offcourse also moved when you equip their usages
--
> yopu have basically your 'eqipment' inventory and your 'treasure bag'
> inventory. You can put something into your equipment inventory even
when
> you don't have any of it's usages equipped -- it just indicates
you've got
> it strapped somewhere on you, or maybe put into pocket.

I think this could be a boolean flag, An item could be equipped or not.
Sounds like a good candidate to me. Then you don't have the overhead of
managing two lists.

>
> It's important, since you can drop your treasure bag in case of
emergency,
> and you don't want to drop all the healing potions with it.
>
> Now, usages have offcourse various 'kinds', and there are also some
> 'generic' usages (most hard and heavy items would have 'improvised
mace'
> usage which allows to equip them as a weapon).
>
> You don't have all your usage slots and item usages displayed all the
> time, offcourse.
>
> Most items have their 'default' usage, which gets called with 'u'se
> command. You can get full list of usages with 'U'se command.
>
> Only the usage slots that have a usage are displayed. When you cannot
> equip a useage bvecause of not having proper equipment slots free,
you get
> a message telling you exactly which usages are in the way.
>
> There might be also an alternative interface, where you have all your
> usage slots listed (in order of importance, I guess), and when you
select
> a usage slot, you have all usages of all items you have that fit into
that
> slot displayed. This might be more useful.
>
> Offcourse, there should be lots of 'convenience' usages, like
'default
> healing item' and 'default magic wand'.
>
> --
> Radomir @**@_ Bee! .**._ .**._ .**._ .**._ zZ
> `The Sheep' ('') 3 (..) 3 (..) 3 (..) 3 (--) 3
> Dopieralski
..vvVvVVVVVvVVVvVVVvVvVVvVvvVvVVVVVVvvVVvvVvvvvVVvVVvv.v.

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

On 22 Apr 2005 10:50:49 -0700, "jeremyo" <junk@jeremyo.com> wrote:

>I like the idea to do both, where pressing "e" will put your sandals on
>your feet, but pressing ALT-e (alt as in alternative, makes sense) asks
>you where you want to equip it. The player then has the chance to come
>up with a great idea, like equipping his silver-buckled-sandles in his
>hand to wack the werewolf with. But of course, you if the player tries
>to equip the sandles on, say, his head, you could simply reply with
>"That is impossible".

But it isn't. It just looks very silly and gives you a penalty to
reactions, except that it gives you a bonus to a "village idiot"
disguise and makes you acceptable in the Village of Shoes-on-Head.

R. Dan Henry
danhenry@inreach.com
Idiot boy, when are you going to post something useful?
Or better yet, get a job and stop being a welfare bum?

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

Dnia 22 Apr 2005 20:28:42 -0700,
Brent Ritchie napisal(a):

> The Sheep wrote:
>> Dnia Fri, 22 Apr 2005 18:19:00 +0200,
>> Filip Dreger napisal(a):

>
>> I want to separate the items and their kinds (physical objects,
>> with attributes light weight, size, material, looks, position, etc.),
>> and the 'usages', being in fact things you can do with the items, and
>> having things like AC bonus, damage bonus, magical effect, etc.
>> The usages further separated from equipment slots, which are simply
> flags
>> telling whether your upper arm is already occupied.


> Maybe flags aren't such a good idea? If you have alot of usages as
> flags and most items only use then as a subset then maybe there's a
> better way. I'm not sure what language your using, but if it can
> refrence data structures you might consider giving each item a list or
> array of properties. If your using c or c++ then you could just
> refrence a list of structs. An example would be.

Yes, Iprobably expressed it wrong.

Uasages are kept on a list in the item kind struct. Every item kind has
it's own list of usages.

Flags are for equipment slots, they tell whether you can wear one more
t-shirt or don your armor.

> If you have a bunch of these then you'll have all the information for
> all of the properties an item might have but only those properties that
> it has. Voila, no more switch statements, just search the list for the
> proper PropertyID and execute it's script. If you don't have scripting
> this could be a good reason to put it in, or you could make a function
> pointer (If your language of choice allows it).

I don't want to go scripting every single property.
Instead, there are several basic usage kinds (weapon, armor, magic item,
etc.) that have their attributes (damage bonus, AC bonus, magic effect).
What's the difference between switch statement and an array of function
pointer anyways?

> I think your over analyzing here. Maybe you should take a step back and
> consider creating a basic inventory with only one item in mind.

Done already.

> Then
> after you have that simple scenario working add another item of a
> different sort and adapt as necessary.

Done.

> I know what it's like to start
> analyzing and try to figure every nuance. Waterfall thinking can be
> exciting but hard to recover from if something dosen't go right.

Well, it's pretty clear. You start with only one usage per item -- it's
the same as with normal items, only you have a part of it's description
separated in another struct.
Then you change it into a list, and done -- mostly UI changes.

> Believe me I know, I've been through a total of 15 rewrites, because of
> this. Just something to consider.

Don't tell me about rewrites. To get to this idea with usages took me
several rewrites of item system.

>> The items itself are offcourse also moved when you equip their usages
> --
>> yopu have basically your 'eqipment' inventory and your 'treasure bag'
>> inventory. You can put something into your equipment inventory even
> when
>> you don't have any of it's usages equipped -- it just indicates
> you've got
>> it strapped somewhere on you, or maybe put into pocket.

> I think this could be a boolean flag, An item could be equipped or not.
> Sounds like a good candidate to me.

It's nor really that inportant how you mark thje items that are equipped.

> Then you don't have the overhead of
> managing two lists.

What overhead?
You mean those several bytes of additional memory? I can put everything
into constant size arrays, since there's a limit on the size of both
lists.

Or maybe you mean the CPU time needed to traverse the list?
But with two lists I only traverse the one that's needed -- it takes less
time.

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

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

The Sheep wrote:
> What's the difference between switch statement and an array of function
> pointer anyways?

None, if your compiler has a decent optimizer.

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

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

SZDev - Slash wrote:
> An advice Neo; try not to react to every comment made about you like
> this.

Excuse me? And let the bastard win? Yeah, right. This way he is forced
to choose between disrupting the group and minding his own goddam
business and shutting up about me. So far, he chooses to disrupt the
group and every thread he posts to.

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

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

The Sheep wrote:
> Dnia 22 Apr 2005 20:28:42 -0700,
> Brent Ritchie napisal(a):
>
> > The Sheep wrote:
> >> Dnia Fri, 22 Apr 2005 18:19:00 +0200,
> >> Filip Dreger napisal(a):
>
> >
> >> I want to separate the items and their kinds (physical objects,
> >> with attributes light weight, size, material, looks, position,
etc.),
> >> and the 'usages', being in fact things you can do with the items,
and
> >> having things like AC bonus, damage bonus, magical effect, etc.
> >> The usages further separated from equipment slots, which are
simply
> > flags
> >> telling whether your upper arm is already occupied.
>
>
> > Maybe flags aren't such a good idea? If you have alot of usages as
> > flags and most items only use then as a subset then maybe there's a
> > better way. I'm not sure what language your using, but if it can
> > refrence data structures you might consider giving each item a list
or
> > array of properties. If your using c or c++ then you could just
> > refrence a list of structs. An example would be.
>
> Yes, Iprobably expressed it wrong.
>
> Uasages are kept on a list in the item kind struct. Every item kind
has
> it's own list of usages.
>
> Flags are for equipment slots, they tell whether you can wear one
more
> t-shirt or don your armor.
>
> > If you have a bunch of these then you'll have all the information
for
> > all of the properties an item might have but only those properties
that
> > it has. Voila, no more switch statements, just search the list for
the
> > proper PropertyID and execute it's script. If you don't have
scripting
> > this could be a good reason to put it in, or you could make a
function
> > pointer (If your language of choice allows it).
>
> I don't want to go scripting every single property.
> Instead, there are several basic usage kinds (weapon, armor, magic
item,
> etc.) that have their attributes (damage bonus, AC bonus, magic
effect).
> What's the difference between switch statement and an array of
function
> pointer anyways?

Probably no difference in speed, but I you use switch statements for
more then a couple of things. It can turn to spaghetti prety quick, and
if you use function pointers you only have to iterate (or traverse, the
list with a sort). Iteration gets rid of switch statements, and is more
readable and compact(read 'Maintainable'), because loops tend to take
up fewer lines of code then switch statements.

>
> > I think your over analyzing here. Maybe you should take a step back
and
> > consider creating a basic inventory with only one item in mind.
>
> Done already.
>
> > Then
> > after you have that simple scenario working add another item of a
> > different sort and adapt as necessary.
>
> Done.
>

Glad to hear, I made these mistakes a few times.

> > I know what it's like to start
> > analyzing and try to figure every nuance. Waterfall thinking can be
> > exciting but hard to recover from if something dosen't go right.
>
> Well, it's pretty clear. You start with only one usage per item --
it's
> the same as with normal items, only you have a part of it's
description
> separated in another struct.
> Then you change it into a list, and done -- mostly UI changes.
>
> > Believe me I know, I've been through a total of 15 rewrites,
because of
> > this. Just something to consider.
>
> Don't tell me about rewrites. To get to this idea with usages took me
> several rewrites of item system.
>
> >> The items itself are offcourse also moved when you equip their
usages
> > --
> >> yopu have basically your 'eqipment' inventory and your 'treasure
bag'
> >> inventory. You can put something into your equipment inventory
even
> > when
> >> you don't have any of it's usages equipped -- it just indicates
> > you've got
> >> it strapped somewhere on you, or maybe put into pocket.
>
> > I think this could be a boolean flag, An item could be equipped or
not.
> > Sounds like a good candidate to me.
>
> It's nor really that inportant how you mark thje items that are
equipped.
>
> > Then you don't have the overhead of
> > managing two lists.
>
> What overhead?
> You mean those several bytes of additional memory? I can put
everything
> into constant size arrays, since there's a limit on the size of both
> lists.
>
> Or maybe you mean the CPU time needed to traverse the list?
> But with two lists I only traverse the one that's needed -- it takes
less
> time.

Maintnence overhead mostly, more code = more maintnence = more bugs(or
features if you prefer).

But having two lists _CAN_ be a dramatic overhead. First there is the
condition code, then the traversal. These would have to be performed
seperatly. for each item. Whereas, if you have one list, you eliminate
the conditional, if you use a flag you can traverse the list once and
change everything that needs to be changed. (If you log your changes in
the inventory screen, or something similar.) Plus less code .

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

Brent Ritchie

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

Dnia 23 Apr 2005 17:07:58 -0700,
Brent Ritchie napisal(a):

> The Sheep wrote:
>> Dnia 22 Apr 2005 20:28:42 -0700,
>> Brent Ritchie napisal(a):

>> > The Sheep wrote:
>> >> Dnia Fri, 22 Apr 2005 18:19:00 +0200,
>> >> Filip Dreger napisal(a):

>> > Then you don't have the overhead of
>> > managing two lists.

>> What overhead?
>> You mean those several bytes of additional memory? I can put
> everything
>> into constant size arrays, since there's a limit on the size of both
>> lists.

>> Or maybe you mean the CPU time needed to traverse the list?
>> But with two lists I only traverse the one that's needed -- it takes
> less
>> time.

> Maintnence overhead mostly, more code = more maintnence = more bugs(or
> features if you prefer).

Somehow I can't see how it's less code to have one big list and switch
statements inside the loop, than having multiple short lists and switch
outside of the loops.

> But having two lists _CAN_ be a dramatic overhead. First there is the
> condition code, then the traversal. These would have to be performed
> seperatly. for each item.

Somehow I can't understand it.
List traversal code is written once, put into a procedure, debugged.
Then I can call it with different lists to traverse and different code to
be performed on every item on the list.
Since some decission have been made outside of the loop, I can make that
code short and simple.

I don't do it for every list with items -- I only do it with the list
I need. The division into equipment and treasure bag is because those
items are treted different game-wise -- that's why it have sense.

When the player character triggers a rust trap, I only try to corrode his
equipment. When the player wants to browse his treasure, I only display
his treasure bag's contents.

I can hardly imagine having to check all items from all the lists -- but
even then I put the code that repeats into a separate function and call it
multiple times.

> Whereas, if you have one list, you eliminate
> the conditional, if you use a flag you can traverse the list once and
> change everything that needs to be changed. (If you log your changes in
> the inventory screen, or something similar.) Plus less code .

No, you don't eliminate the conditional. You just put it inside, where
it's harder to debug and maintain. IMHO offcourse.

I prefer to have everything in small, nicely separated pieces.

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

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

Twisted One <twisted0n3@gmail.invalid> wrote:
> None, if your compiler has a decent optimizer.

You compiler can design, write, code, profile, get help on newsgroups
and from others, redesign, rewrite, and recode?

--
Jim Strathmeyer

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

Twisted One <twisted0n3@gmail.invalid> wrote:
> Excuse me? And let the bastard win? Yeah, right. This way he is forced
> to choose between disrupting the group and minding his own goddam
> business and shutting up about me. So far, he chooses to disrupt the
> group and every thread he posts to.

I have never felt that Dan has disrupted the group. In fact, I consider
him the most helpful and constructive person here.

You, on the other hand... Do you black out when you post? And then wake
up the next day in a cold sweat, having no idea what you've done? Or do
you just totally not get human interaction?

--
Jim Strathmeyer

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

Jim Strathmeyer wrote:
> Twisted One <twisted0n3@gmail.invalid> wrote:
>
>>What?
>
> I wasn't talking to you.

What?
You aren't quoting enough context here. What was I quoting when I wrote
"What?"?

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

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

Twisted One <twisted0n3@gmail.invalid> wrote:
> Even though he's been tacking a bit of irrelevant flamebait at the end
> of nearly every post here for several days? You are clearly quite mad.

Yes, even though.

Clearly.

--
Jim Strathmeyer

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

Jim Strathmeyer wrote:

<clip>

Please stop making fun of the handicapped. If you don't
kick the crutches out from under cripples in person, don't
bait mental defectives on the newsgroup.

Bear

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

Ray Dillinger wrote:
[insult deleted]

You, sir, are quite the hypocrite. Insulting me by accusing me of being
a mental case, while simultaneously telling other people to quit flaming
and flamebaiting. Really.

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

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

Twisted One wrote:
> Killfiled who? The only Paul here is Paul Arthur, unless it's ABCGi or
> someone else who is using a 'nym.

Nah, as far as my Intelligence Agency tells me ABCGi is an "Adam"-named
being ;-)
--
At your service,
Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
"The name of GenRogue, has become a warning against excessively
complex design." -- RGRD FAQ

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

The Sheep wrote:
> Dnia Tue, 26 Apr 2005 16:31:13 +0200,
> Kornel Kisielewicz napisal(a):
>
>> Twisted One wrote:
>>> Killfiled who? The only Paul here is Paul Arthur, unless it's ABCGi
>>> or someone else who is using a 'nym.
>
>> Nah, as far as my Intelligence Agency tells me ABCGi is an
>> "Adam"-named being ;-)
>
> Waaaah. Now I regret posting my name openly.
> Nobody is going to investigate on me, and it seems like so much fun

Don't worry, you were investigated too ;-). I made contact with a person who
knows you personaly ;-)
--
At your service,
Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
"Well, the philosophy of the World of Shadows is based on most of the
degenerate, immoral and foremost amoral philosophical beliefs of our
world exagarated to the maximum." --Anubis

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

The Sheep wrote:
>> Don't worry, you were investigated too ;-). I made contact with a
>> person who knows you personaly ;-)
>
> That doesn't count
>
> Heh, reminds me how last year I met GSN -- he had some lectures here
> and he needed his login in our net. I was shocked -- I thought
> he'd be much older.

Yeah ;-). And I was shocked when 2 years ago the guy I was traveling for a
year with the bus home from my university turned out to be Piotr Wolny the
creator of Legends of Valdor ;-).
--
At your service,
Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
"Invalid thought detected. Close all mental processes and
restart body."

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

In article <426925f3$0$8481$636a15ce@news.free.fr>,
Christophe Cavalaria <chris.cavalaria@free.fr> wrote:
>Filip Dreger wrote:
[...]
>> My game approached the magical point of no return, where I have to
>> choose one of these. Any thoughts?

>Intelligent. It is a bad UI practice to ask a multiple choice question to a
>user only to tell him after that 90% of the possible answers aren't
>possible in fact.
[...]
>If you really want the special features of the out of place equip, you can
>always provide a second equip command that does the "stupid slots" way.
>Like e for "normal equip" and E for "stupid equip"

While I generally agree with this, I think that the real correct
answer is to do whatever is easiest to code, then go back and fix it
later once you've got a working game. It's a lot easier to add a
feature to a working program than to a non-working program.



--Chris


--
Chris Reuter http://www.blit.ca
"Feel free, as long as you only quote it in long trotskyite diatribes about
the evils of objectivism."
--Charlie Stross, granting permission to be quoted in a .sig

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

The Sheep wrote:
> Dnia Tue, 26 Apr 2005 16:57:35 +0200,
> Kornel Kisielewicz napisal(a):
>
>> The Sheep wrote:
>
>>> Heh, reminds me how last year I met GSN -- he had some lectures here
>>> and he needed his login in our net. I was shocked -- I thought
>>> he'd be much older.
>
>> Yeah ;-). And I was shocked when 2 years ago the guy I was traveling
>> for a year with the bus home from my university turned out to be
>> Piotr Wolny the creator of Legends of Valdor ;-).
>
> You know, there's a theory saying that there are only about 200 real
> people on this planet -- the rest is only for decoration.
>
> That's why you keep meeting the same people all the time, even in most
> bizzare places.

Sometimes I'm inclined to believe that...
--
At your service,
Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
"From what I've read, a lot of people believe that GenRogue
exists and will be released some day" -- Arxenia Xentrophore

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

Dnia Thu, 28 Apr 2005 12:30:53 -0400,
Chris Reuter napisal(a):

> Ask me how Smalltalk does flow control. I dare you.

It's not directed to me, but I'm curious.

How?

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

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

In article <slrnd7cvs2.mar.sheep@atos.wmid.amu.edu.pl>,
The Sheep <sheep@sheep.prv.pl> wrote:
>Dnia Mon, 2 May 2005 14:09:40 -0400,
> Chris Reuter napisal(a):
>
>> In article <slrnd72dau.3s5.sheep@atos.wmid.amu.edu.pl>,
>> The Sheep <sheep@sheep.prv.pl> wrote:
>>>Dnia Thu, 28 Apr 2005 12:30:53 -0400,
>>> Chris Reuter napisal(a):
>
>
>>>> Ask me how Smalltalk does flow control. I dare you.
>
>>>It's not directed to me, but I'm curious.
>>>How?
>
>> Long answer: Well, you asked. Now you have to read it.
>
>I'm very glad I asked. It's very interesting. And elegant.
>
>Somehow, reminds me of how TCL does it.
>
>Maybe because both ways are only possible when you can pass actual code
>as parameters?
>
>> In Smalltalk, everything[1] is done by sending "messages" to objects.
>> Sending a message is, for the purposes of this discussion, the same
>> thing as calling a method (aka "member function" ) so I'm going to
>> pretend they're the same thing, but I'll probably keep calling them
>> messages out of habit so I figured I'd warn you now.
>
>That's how OOP was defined in the first place, isn't it?

Depends on the language. Python doesn't (AFAIK) have a concept of a
message but has about the same level of flexibility. C++, on the
other hand, is far more restrictive. Java seems to be somewhere in
between, although I could be wrong.

Messages make a lot more sense if you look at Smalltalk-72, the
original version of the language. (Smalltalk underwent two different
major revamps. The version everyone uses now is actually
Smalltalk-80.)

In Smalltalk-72, the message was whatever text was to the right of the
object and the object would actually parse the message and do what it
wanted with it. This made for a really, really powerful language but
no two Smalltalk programs looked like they were written in the same
language.

Between then and 1980, they fixed that problem by limiting what
messages could be. Along the way, messages sort of turned into method
calls and most OO languages don't really have the concept at all.

In modern Smalltalk, messages mean:

1) Calling a method will work, regardless of its implementation or
the object's inheritance structure, so long as there's a method with
the expected name there.

2) If there's no method corresponding to the message, you can
catch that and add other behaviour.

For example, in QFP, I implement creature stats by making the stats
objects, then catching message sends that follow a particular naming
pattern and doing the right thing.

So when I do something like:

aMonster atStatStrength: 42

there is no method named "atStatStrength:". Instead, it calls
"doesNotUnderstand:", which gets the method name, sees the "atStat"
part, extracts the "Strength" part from the message name, pulls the
Strength object from its hash of stats and stores the argument (42)
there.

3) You can piece together message sends programmatically. For
example, you might create a string and send it as a message to an
object.

Now, I know you can do all of this in Python, and I'm pretty sure
Perl lets you do it as well and neither of those languages have a
concept of "message", so I'm inclined to believe that these days,
messages are more of a convention than anything else.


>> This is true even if the method that created the block has already
>> returned. Is that cool or what?!
>
>It's weird. How about when you destroy the method? (it's an object too,
>isnt it?)

Everything's garbage collected so you don't actually destroy methods,
you just remove them from the class. If a block context hangs around,
it keeps the method alive.

The same is true of method contexts (i.e. the data structure that
holds the local variables of a particular method call--in C, it's a
stack frame). If a method does something like this:

SomeGlobal := [a + b thingee].

the block will live on after the method call that created it returns
but the block will keep the method context alive since, after all, a
and b are local variables. You can then continue to evaluate the
block however often you want.

Also, blocks can contain returns. This:

SomeGlobal := [^a].
SomeGlobal value.

will cause the current method to return but the block that did the
return will still exist because a global keeps it alive. And if you
try to evaluate the block again, you'll get a runtime error because
you can't return more than once.


>Thank you very much for your time to write all this. I could probably find
>it in some SmallTalk tutorial, but I didn't expect it'd be so fun.

Yeah, Smalltalk is way fun. Join ussssssss. Join usssssss.


--Chris


--
Chris Reuter http://www.blit.ca
"Please stop putting my life in perspective. It's very annoying."
--Pearls Before Swine, 2004/7/23