List (please add to!)
Antoine
-------------------------------------------------------------------------------
Invisibility
Polymorph-self
Charm monster
Stacking objects
Friendly NPCs in the dungeon
...?
Gamer_2k4
> Things which are harder to code than one might initially think
> -------------------------------------------------------------------------------
> Stacking objects
Stacking objects is easy - just use a vector or similar container.
Gamer_2k4
Antoine
I mean 'stacking' in the Angband sense - one torch plus one torch = a
single item 'two torches'
A.
Gerry Quinn
game...@gmail.com says...
There is much to be said for the simplistic beauty of
Square::m_ObjectID.
- Gerry Quinn
Gerry Quinn
ma...@guildgame.com says...
Are they so bad?
I'm not planning on invisibility, but it could be a flag.
Polymorph-self as I suggested earlier, I would only use as a special
skill.
Charm-monster is part of my design, it is a lesser version of Turn-
monster-into-pet.
Stacking objects - best avoided IMO.
Friendly NPCs - I have an allegiance system which ought to support
friendly monsters, and I will probably have shopkeepers etc. too.
OTOH, I have a concept where a lot of stuff happens when you go down a
new level. I could use it to remove shopkeepers and such from the
dungeon per se.
Still, I like friendlies, and I think I will avoid using that
particular abstraction intensively.
- Gerry Quinn
Gamer_2k4
> > Stacking objects is easy - just use a vector or similar container.
> I mean 'stacking' in the Angband sense - one torch plus one torch = a
> single item 'two torches'
Oh. Well even that was fairly easy. I jsut gave each item an amount
flag and overloaded the == operator. The program checks if the items
are then same, then deletes one and adds its amount to the other.
The alternative is this:
PACK CONTENTS:
A: an arrow
B: an arrow
C: an arrow
D: an arrow
E: an arrow
F: an arrow
G: an arrow
H: an arrow
I: an arrow
J: a bow
Unless you have a way around that...
Gamer_2k4
Radomir 'The Sheep' Dopieralski
Antoine wrote:
Selling items
Timed events
Animation
Persistent levels
Monsters moving between levels
Monsters with FOV
Pets
Random artifacts
Random monster races
Doors with keys
Throwing items
Monster inventory
Running
--
Radomir `The Sheep' Dopieralski
jice
Gamer_2k4 wrote:
> Oh. Well even that was fairly easy. I jsut gave each item an amount
> flag and overloaded the == operator. The program checks if the items
> are then same, then deletes one and adds its amount to the other.
>
This can be much more complicated. Think of two identical swords.
Inventory :
item 0 : 2 swords DMG 3d4 durability 100
Now you wear one sword, fight a monster and unwear the sword.
Inventory :
item 0 : 1 sword DMG 3d4 durability 100
item 1 : 1 sword DMG 3d4 durability 95
This means that there are lots of game events that can have impact on
your items stacks.
--
jice
Krice
> Polymorph-self
I guess this one, because it changes the fundamental ways of
how the player character functions.
Gerry Quinn
jice....@gmail.com says...
The easy way to handle this is to make items that have state non-
stackable.
- Gerry Quinn
JSwing
news:MPG.1eef6e227...@news1.eircom.net:
I think they're referring to the non-obvious implementation issues, things
that you might not thnk about on your first plan. One of them would be
when and how to search for item duplicates in inventory so that you know
when to stack and whne not to, and then presenting that data to the player
in a meaningful way.
Not difficult, just not obvious to the novice RL builder.
JSwing
JSwing
> In article <1149555950.5...@c74g2000cwc.googlegroups.com>,
> ma...@guildgame.com says...
>> Things which are harder to code than one might initially think
>> ----------------------------------------------------------------------
>> ---------
>>
>> Invisibility
>> Polymorph-self
>> Charm monster
>> Stacking objects
>> Friendly NPCs in the dungeon
>> ...?
>
> Are they so bad?
>
> I'm not planning on invisibility, but it could be a flag.
Invisibility impacts monster AI and game balance significantly, depending
on implementation.
I'd add teleport to that list for similar reasons.
> Polymorph-self as I suggested earlier, I would only use as a special
> skill.
Lots of tricky implementation issues: effects of inventory, non-human
forms, etc.
> Charm-monster is part of my design, it is a lesser version of Turn-
> monster-into-pet.
Similar to invisibility, it has significant game balance issues, plus some
AI impact. Whne a monster reverts, does it retain the same AI information
it had when it was charmed (allegiances, goals, etc)? If so you need a way
to recreate them.
> Friendly NPCs -
Like pets, the friendly NPCs exist (in theory) in a complex RL world.
There reactions tomonsters, the extent to which they help the player,
measures of how just friendly they are, these can easily balloon into
something complex.
It sounds like you've got a pretty good handle on your implementation plans
though, so these may not seem that complex. You're just ahead of the pack.
JSwing
Kornel Kisielewicz
>
Random Quests
Random Plot
Random Overworld
... no, seriously ;->
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"Gott weiss, Ich will kein Engel sein..." -- Rammstein /Engel/
stu
Phase Door (remember bards tale). I guess you could call it digging.
The ability to
dig depends on how you hold your levels in memory etc...
balance
sense of time
food
Q&A, Testing, Documenting, Planning
-stu
Kornel Kisielewicz
Oh man, I forgot about three most important ones:
Adding content
Balancing
Polishing
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
Carceri -- A prelude to GenRogue... Coming Soon
konijn_
Stealth !!
Cheers,
T.
Maxy-B
> Antoine napisal(a):
> > Things which are harder to code than one might initially think
> > -------------------------------------------------------------------------------
> >
> > Invisibility
> > Polymorph-self
> > Charm monster
> > Stacking objects
> > Friendly NPCs in the dungeon
> > ....?
> >
> Random Quests
> Random Plot
> Random Overworld
Anyone who starts out thinking these will be easy is delusional :)
--
Maxy-B
Gamer_2k4
> Inventory :
> item 0 : 2 swords DMG 3d4 durability 100
> Now you wear one sword, fight a monster and unwear the sword.
> Inventory :
> item 0 : 1 sword DMG 3d4 durability 100
> item 1 : 1 sword DMG 3d4 durability 95
> This means that there are lots of game events that can have impact on
> your items stacks.
True. But even that wasn't too hard too implement. I had two hatchets
that got damaged as you used them, and they worked fine.
I'd still prefer:
PACK
a: 24 arrows
b: 1 sword [98]
c: 1 sword [100]
instead of:
PACK
a: arrow
b: arrow
c: arrow
d: arrow
e: arrow
f: arrow
g: arrow
h: arrow
i: 1 sword [98]
j: 1 sword [100]
Gamer_2k4
Radomir 'The Sheep' Dopieralski
Gamer_2k4 wrote:
>> This means that there are lots of game events that can have impact on
>> your items stacks.
> True. But even that wasn't too hard too implement. I had two hatchets
> that got damaged as you used them, and they worked fine.
It's not something impossible to implement.
But it something more complicated than it looks at the first sight.
Because there are all those special cases.
And it complicates most of your other code too.
Gamer_2k4
Oh right...that's what this discussion was about. Ok, I agree that
it's tricky than it may seem initially.
Gamer_2k4
Ray Dillinger
Rope.
You can mistake rope for a simple idea, but if you
try to implement it, the Gods will laugh in your general
direction. I can think of no roguelike right now that has
a good implementation of rope.
Bear
Antoine
JSwing wrote:
> Gerry Quinn <ger...@DELETETHISindigo.ie> wrote in
> news:MPG.1eeeeb3ef...@news1.eircom.net:
>
> > In article <1149555950.5...@c74g2000cwc.googlegroups.com>,
> > ma...@guildgame.com says...
> >> Things which are harder to code than one might initially think
> >> ----------------------------------------------------------------------
> >> ---------
> >>
> >> Invisibility
> >> Polymorph-self
> >> Charm monster
> >> Stacking objects
> >> Friendly NPCs in the dungeon
> >> ...?
> >
> > Are they so bad?
> >
> > I'm not planning on invisibility, but it could be a flag.
>
> Invisibility impacts monster AI and game balance significantly, depending
> on implementation.
>
> I'd add teleport to that list for similar reasons.
Especially monsters with controlled teleport.
A.
stu
Ray Dillinger wrote:
>
> Rope.
>
> You can mistake rope for a simple idea, but if you
> try to implement it, the Gods will laugh in your general
> direction. I can think of no roguelike right now that has
> a good implementation of rope.
aaah I remember all the rope discussions in rec.*.int-fiction...
they have similar problems with fire and water. if you give someone a
lighter they will try and burn/set fire to everything in the game.
but it also comes down to how they model their gameworld.
> cut rope in half
"You have some rope and some rope"
> cut some rope in half
"Guru Meditation!"
-stu
Gamer_2k4
> they have similar problems with fire and water. if you give someone a
> lighter they will try and burn/set fire to everything in the game.
> but it also comes down to how they model their gameworld.
> > cut rope in half
> "You have some rope and some rope"
> > cut some rope in half
> "Guru Meditation!"
It's best to abstract that sort of thing to feet of rope. The lighter
idea is interesting though. I would assume every item would just burn
(get destroyed), unless it had a special property.
Gamer_2k4
Kornel Kisielewicz
>> This can be much more complicated. Think of two identical swords.
>> Inventory :
>> item 0 : 2 swords DMG 3d4 durability 100
>
>> Now you wear one sword, fight a monster and unwear the sword.
>> Inventory :
>> item 0 : 1 sword DMG 3d4 durability 100
>> item 1 : 1 sword DMG 3d4 durability 95
>
>> This means that there are lots of game events that can have impact on
>> your items stacks.
>
> True. But even that wasn't too hard too implement. I had two hatchets
> that got damaged as you used them, and they worked fine.
>
> I'd still prefer:
> PACK
> a: 24 arrows
> b: 1 sword [98]
> c: 1 sword [100]
DoomRL uses this approach. Some things are stackable (ammo, medpacks)
and some aren't (weapons, armor). Works fine, especialy with the
stacking cap and slot system. The only hard part was to make the stacks
rearange themselves at use and at pickup.
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"From what I've read, a lot of people believe that GenRogue
exists and will be released some day" -- Arxenia Xentrophore
stu
thats the whole point, you cant just burn up everything in the game.
"you cut some rope in half. you have 1.5 inches of rope and 1.5 inches
of rope."
> tie 1.5 inches of rope into a gordian knot.
"which 1.5 inches of rope, the 1.5 inches of rope or the 1.5 inches of
rope?"
how do you model infinity? how many grains of sand make up a sandy
beach? how many times can I dig a hole until I reach china? Which is
better, having the player read "You can see a grain of sand, a grain of
sand, a grain of sand, a grain of sand" or not let
the player take 'grains of sand' from the beach to start?
the gameworld isnt built to model grains of sand, infinity or burning
everything in sight.
similar situations with roguelikes exist, modeling time, speed, food,
etc.
If I am playing ADOM and in the overland, cast a fireball in a forest,
should the entire forest burn down? Can I freeze the river and walk
across the lake? Does a fireball melt rock? If I dont have a backpack,
how can I carry 20 scrolls, 10 potions, 8 swords, 4 rations, 3 suits
of armour AND weild a shield and mace at the same time??
:)
-stu
Jeff Lait
>
> If I am playing ADOM and in the overland, cast a fireball in a forest,
> should the entire forest burn down? Can I freeze the river and walk
> across the lake? Does a fireball melt rock? If I dont have a backpack,
> how can I carry 20 scrolls, 10 potions, 8 swords, 4 rations, 3 suits
> of armour AND weild a shield and mace at the same time??
I'm actually thinking about allowing forest fires in POWDER. Mind you,
any overland I have is 1:1 scale, so you can already freeze rivers to
cross over if you so desire.
Forest fires would make more use of the Direct Wind spell, at least.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
JSwing
news:1149682987....@u72g2000cwu.googlegroups.com:
> If I dont have a backpack,
> how can I carry 20 scrolls, 10 potions, 8 swords, 4 rations, 3 suits
> of armour AND weild a shield and mace at the same time??
Well obviously you strap everything to yourself with the rope. :)
JSwing
Gamer_2k4
> should the entire forest burn down?
This works in Gearhead.
> Can I freeze the river and walk across the lake?
In ADOM, yes.
Gamer_2k4
R. Dan Henry
<kisie...@gazeta.pl> wrote:
>Antoine napisa?(a):
>> Things which are harder to code than one might initially think
>> -------------------------------------------------------------------------------
>>
>> Invisibility
>> Polymorph-self
>> Charm monster
>> Stacking objects
>> Friendly NPCs in the dungeon
>> ....?
>
>Oh man, I forgot about three most important ones:
>
>Adding content
>Balancing
>Polishing
But these don't *seem* easy -- that's why so many "engine" projects get
started, to avoid this obviously hard work.
--
R. Dan Henry = danh...@inreach.com
Michal Bielinski
> Things which are harder to code than one might initially think
> -------------------------------------------------------------------------------
>
> Invisibility
> Polymorph-self
> Charm monster
> Stacking objects
> Friendly NPCs in the dungeon
Fights between two monsters that both are hostile to player.
I wanted my wild cat to track down all rats in cave then kill them and
eat. It seemed easy because my monsters already could do this to
player. But player will react if attacked and rats weren't prepared to
do so and din't oppose when wild cat was slaughtering them! That turned
out a lot harder than I supposed it to be.
crichmon
> Things which are harder to code than one might initially think
> --------------------------------------------------------------
>
> Invisibility
> Polymorph-self
> Charm monster
> Stacking objects
> Friendly NPCs in the dungeon
> ...?
random generation of detailed maps, be the maps overworld terrain, dungeons,
castles, towns, cloud cities, whatever...
ships. like i had an idea for the character to be on a prison ship, and the
prisoners on the ship escape. the ship is floating down river per turn.
that could translate to "moving terrain".
crichmon
>>
>> Gamer_2k4 wrote:
>>> Oh. Well even that was fairly easy. I jsut gave each
>>> item an amount flag and overloaded the == operator.
>>> The program checks if the items are then same, then
>>> deletes one and adds its amount to the other.
>>
>> This can be much more complicated. Think of two identical
>> swords. Inventory :
>> item 0 : 2 swords DMG 3d4 durability 100
>>
>> Now you wear one sword, fight a monster and unwear the
>> sword. Inventory :
>> item 0 : 1 sword DMG 3d4 durability 100
>> item 1 : 1 sword DMG 3d4 durability 95
>>
>> This means that there are lots of game events that can
>> have impact on your items stacks.
>
> The easy way to handle this is to make items that have
> state non-stackable.
whenever an item enters an inventory, stack it if there is/are already (an)
item(s) that are identical. if there are complex states that will make
items unique, then make a massive equality operator.
crichmon
>>
>>>> Things which are harder to code than one might initially think
>>>> --------------------------------------------------------------
>>>>
>>>> Polymorph-self
>>>> Charm monster
>>>> Stacking objects
>>>> Friendly NPCs in the dungeon
>>>> ...?
>>>
>>> Are they so bad?
>>>
>>> I'm not planning on invisibility, but it could be a flag.
>>
>> Invisibility impacts monster AI and game balance significantly,
>> depending on implementation.
>>
>> I'd add teleport to that list for similar reasons.
>
> Especially monsters with controlled teleport.
implementing teleport could be as easy as implementing monsters that move
between levels. essentially going up or down stairs is "teleporting" to a
different level. controlled teleport would be teleporting towards player
when attacking and teleporting away otherwise... the monster would have to
know specific locations to teleport to, which could be simplified if
monsters have some knowledge of the dungeon, at least to where the monster
has been previous.
Elsairon
"crichmon" <crichmon_at_fractalbase_dot_net> wrote in message
news:mLSdnVv01sY4NRrZ...@comcast.com...
And if there are battles between two ships? A lot more work than
anticipated.
--
Elsairon
Elethiomel
I've seen a few people on this newsgroup (not recently, though) that
have claimed that content addition is "tedious data entry" rather than
actual game mechanics work, and thus just boring and not hard.
--
A good signature is a concise and original summary of personality. This
is not a good signature.
jice
crichmon wrote:
> "Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote:
> >>
> >>
> >> have impact on your items stacks.
> >
> > The easy way to handle this is to make items that have
> > state non-stackable.
>
> whenever an item enters an inventory, stack it if there is/are already (an)
> item(s) that are identical. if there are complex states that will make
> items unique, then make a massive equality operator.
There is indeed a need for a massive equality operator that depends on
item properties that can vary during game.
But I disagree with the trigger event : 'whenever an item enters an
inventory'.
What about apples that rot in the inventory. You start with a stack of
two apples. One of them is older than the other, but that doesn't
appears in the inventory description :
2 apples
during a world update, you increase the apples age and one of them
becomes a 'rotten apple'. You have to break the stack :
1 apple
1 rotten apple
The only way I see to avoid stack checks everywhere in the code is to
have item with generic properties. Each property has a flag which
indicate if it has an impact on the stack. Then you need a generic
property modification function which eventually checks the inventory
stacks.
Note that there is another tricky stuff here : the "2 apples" stack is
not a single item with a 'quantity' property of 2, because the two
items are different (not same age), but they have the same inventory
description. Thus, there two type of stacks :
- stacks of cloned items (14 arrows) which can really be implemented as
a single item with a quantity property
- stacks of similar items : items are different, but the difference
doesn't appear in the inventory
--
jice
Krice
> - stacks of similar items : items are different, but the difference
> doesn't appear in the inventory
If items have different properties then you don't make them stackable
at all. The easy way to prevent self-made problems like this is avoid
using fancy properties that have no use in the gameplay.
Erik Piper
> crichmon wrote:
> > "Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote:
> What about apples that rot in the inventory. You start with a stack of
> two apples. One of them is older than the other, but that doesn't
> appears in the inventory description :
> 2 apples
>
> during a world update, you increase the apples age and one of them
> becomes a 'rotten apple'. You have to break the stack :
> 1 apple
> 1 rotten apple
[...]
Well, *that* one's no trouble get around! You can things make the
rotting of one apple automatically spoil all other apples in the stack.
I doubt any players will dare to claim that one rotten apple doesn't
spoil the bunch. :-)
e.
jice
Ok, but there are some basic RL game mechanism that rely on such
properties, like sword or candle durability. The brute-force method you
propose would lead to :
You have :
- a candle (dur 95)
- a candle (dur 94)
- a candle (dur 95)
- a worn candle (dur 35)
instead of :
You have
- 3 candles
- a worn candle
which is more sexy ;)
--
jice
Gerry Quinn
jice....@gmail.com says...
> Ok, but there are some basic RL game mechanism that rely on such
> properties, like sword or candle durability. The brute-force method you
> propose would lead to :
> You have :
> - a candle (dur 95)
> - a candle (dur 94)
> - a candle (dur 95)
> - a worn candle (dur 35)
>
> instead of :
> You have
> - 3 candles
> - a worn candle
>
> which is more sexy ;)
But there's no real need to use such mechanisms. Maybe they are magic
candles that can only be lit once, and disappear when doused.
Or they can be lumped:
You have:
- enough candles for 2 hours and 46 minutes of light
Doesn't everyone in Angband switch from torches to oil lamps as soon as
they can? Oil lamps work the second way - flasks of oil can't be half
poured.
- Gerry Quinn
crichmon
> crichmon wrote:
>> "Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote:
>>>
>>>> This means that there are lots of game events that can
>>>> have impact on your items stacks.
>>>
>>> The easy way to handle this is to make items that have
>>> state non-stackable.
>>
>> whenever an item enters an inventory, stack it if there
>> is/are already (an) item(s) that are identical. if there
>> are complex states that will make items unique, then make
>> a massive equality operator.
>
> There is indeed a need for a massive equality operator that
> depends on item properties that can vary during game. But I
> disagree with the trigger event : 'whenever an item enters
> an inventory'.
>
> What about apples that rot in the inventory. You start with
> a stack of two apples. One of them is older than the other,
> but that doesn't appears in the inventory description :
> 2 apples
>
> during a world update, you increase the apples age and one
> of them becomes a 'rotten apple'. You have to break the
> stack :
> 1 apple
> 1 rotten apple
Well then don't stack them because of the difference in age.
Or stack them, and when one of the apples becomes rotten, have the object
representing the apple notify the inventory. Essentially, the rotten apple
is removed from inventory and re-added, which could allow stacking with any
other rotten apples:
2 apples
1 rotten apple
might become:
1 apple
2 rotten apples
Just an example. Although my implementation might not stack the apples if
they are of different age.
However, if an item's state can change due to other factors, such as RNG, or
the Master Lich decides to curse some of your items, then yeah,
unstack/restack methods will be required. Although that might target
inventory items through inventory, so that'd be easier to implement then
having items notify the stacking of the containing inventory.
The point is that there are solutions!
crichmon
Ray Dillinger
> "Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote:
>>The easy way to handle this is to make items that have
>>state non-stackable.
>
>
> whenever an item enters an inventory, stack it if there is/are already (an)
> item(s) that are identical. if there are complex states that will make
> items unique, then make a massive equality operator.
The equality operator should just compare what the character
*knows* about the items and stack accordingly. This presumes
that stacking is for generating display only, and not for
data representation purposes.
So stack unidentified items that have the same unidentified
name, and stack identified items that have the same identified
name. Stack identified and explicated items that have identical
names and explications. Stacking always reflects character
knowledge.
Thus, you have "15 daggers" but then you identify them in
a basic way and you have "10 plain daggers" and "3 undead
slaying daggers" and 2 "magically accurate daggers." Then
you find a way to identify them more completely, and suddenly
you have a bunch of smaller stacks, depending on specific
bonuses, durability, wear, etc.
Bear
Jeff Lait
Actually, I think the problem is that people *do* think that those
tasks are easy. Thus, they figure they'll tackle the "Hard" task of
Invisibility first. All the content/balancing/polishing can then be
done in a fortnight once their game engine is complete.
Polishing, especially, is a very difficult task.
Gamer_2k4
>
> You have:
> - enough candles for 2 hours and 46 minutes of light
That's actually a pretty good idea.
a: candles [166 minutes]
This is a case where reality has reached the proper level of
abstraction, IMO. You have a logical amount of detail, but the player
is not bogged down with constantly changing or renew candles. What
other situations could this be applied to?
Gamer_2k4
Gamer_2k4
> *knows* about the items and stack accordingly. This presumes
> that stacking is for generating display only, and not for
> data representation purposes.
> So stack unidentified items that have the same unidentified
> name, and stack identified items that have the same identified
> name. Stack identified and explicated items that have identical
> names and explications. Stacking always reflects character
> knowledge.
> Thus, you have "15 daggers" but then you identify them in
> a basic way and you have "10 plain daggers" and "3 undead
> slaying daggers" and 2 "magically accurate daggers." Then
> you find a way to identify them more completely, and suddenly
> you have a bunch of smaller stacks, depending on specific
> bonuses, durability, wear, etc.
Wow, this is a lot more complicated than we initially thought ;). That
would make sense as far as gameplay goes, plus it would make the game
slightly harder. For example, in other games you might have 10 potions
of gain attributes in 3 different stacks. If you've identified two of
the stacks to be blessed and uncursed, you aren't going to drink from
the other stack, which must be cursed. If the player doesn't know the
status, the items should all be stacked together. Of course, this
would make identify scrolls a lot less useful, because you'd have to
identify items one at a time (which may or may not be a good thing).
Gamer_2k4
Gerry Quinn
game...@gmail.com says...
Rope ;-)
Seriously, it could be workable:
===> inv
You have 72 ft of rope (p)
===> use p
What do you want to do with rope [72 ft]?
a. Make a lasso [42 ft]
b. Make a snare [16 ft ]
===> do a
You have 30 ft of rope (p)
You have a lasso (q)
===>wield q
You wield a lasso (q)
You unwield a sword (q)
===> use p
What do you want to do with the rope [30 ft]?
a. Make a lasso [42 ft] (not enough rope)
b. Make a snare [16 ft ]
===> do b
Select square [NESW]
===> e
You set a snare trap in the square to the east
===> inv
You have 14 ft of rope (p)
You have a sword (q)
- Gerry Quinn
Gerry Quinn
says...
> So stack unidentified items that have the same unidentified
> name, and stack identified items that have the same identified
> name. Stack identified and explicated items that have identical
> names and explications. Stacking always reflects character
> knowledge.
>
> Thus, you have "15 daggers" but then you identify them in
> a basic way and you have "10 plain daggers" and "3 undead
> slaying daggers" and 2 "magically accurate daggers." Then
> you find a way to identify them more completely, and suddenly
> you have a bunch of smaller stacks, depending on specific
> bonuses, durability, wear, etc.
Also a game that will never be completed, and if completed, will
probably be bugged...
[Personally, I'm more inclined to do away with the identification
mechanic.]
- Gerry Quinn
R. Dan Henry
<torespon...@hotmail.com> wrote:
>R. Dan Henry wrote:
>> On Tue, 06 Jun 2006 14:23:19 +0200, Kornel Kisielewicz
>> <kisie...@gazeta.pl> wrote:
>>
>> >Antoine napisa?(a):
>> >> Things which are harder to code than one might initially think
>> >> -------------------------------------------------------------------------------
>> >>
>> >> Invisibility
>> >> Polymorph-self
>> >> Charm monster
>> >> Stacking objects
>> >> Friendly NPCs in the dungeon
>> >> ....?
>> >
>> >Oh man, I forgot about three most important ones:
>> >
>> >Adding content
>> >Balancing
>> >Polishing
>>
>> But these don't *seem* easy -- that's why so many "engine" projects get
>> started, to avoid this obviously hard work.
>
>Actually, I think the problem is that people *do* think that those
>tasks are easy. Thus, they figure they'll tackle the "Hard" task of
>Invisibility first. All the content/balancing/polishing can then be
>done in a fortnight once their game engine is complete.
That's the justification sometimes given. But to know what people really
believe, you have to look at what they do, not what they say. And the
work people put off is the [perceived] hard work.
R. Dan Henry
>Note that there is another tricky stuff here : the "2 apples" stack is
>not a single item with a 'quantity' property of 2, because the two
>items are different (not same age), but they have the same inventory
>description.
Then they shouldn't stack. In Crawl, corpse chunks with the same
description don't stack in general, because they'll be different ages.
For that matter, unidentified items easily have the same description,
but shouldn't stack if not identical (and arguably even if they are,
since that gives you information about them).
Christopher Brandt
I think the hardness of adding stuff like that depends on how your
general engine works. For me this stuff was pretty easy because the only
difference between the player and NPCs is how they are controlled. So
the monster just took the first enemy it saw and attacked it which
worked pretty fine. After some time it decided which one to attack by
checking which one is the weakest.
Same is for charm monster or friendly NPCs in the dungeon.
Polymorph-self was the hardest thing I had to realize because there are
some flags the player is supposed to keep and some ought to be changed.
Invisibility? Just one flag and two if's for me...
Things I found hard to realize (of which I didn't think they should be)
were:
preedited dungeons, opening and closing doors (for some strange
reasons), unintelligent monsters (making stupid mistakes and stuff),
calculating subattributes depending on attributes AND equipment
(accumulization and percental changes ... which one when?).
Christopher Brandt
Radomir 'The Sheep' Dopieralski
Christopher Brandt wrote:
> Michal Bielinski schrieb:
>> Antoine wrote:
> Invisibility? Just one flag and two if's for me...
The problem is not in the code you have to write.
The problem is in the code that already exist, and
how it interacts with the new code.
Adding invisibility late is surely hard. Adding it
right at the beginning (or leaving place for it)
makes it much easier.
--
Radomir `The Sheep' Dopieralski
Corremn
Antoine wrote:
> Things which are harder to code than one might initially think
> -------------------------------------------------------------------------------
>
> Invisibility
> Polymorph-self
> Charm monster
> Stacking objects
> Friendly NPCs in the dungeon
> ...?
umm, writing a rogue-like....
David Damerell
>The equality operator should just compare what the character
>*knows* about the items and stack accordingly. This presumes
>that stacking is for generating display only, and not for
>data representation purposes.
This precludes a limited-size inventory, I would think.
--
David Damerell <dame...@chiark.greenend.org.uk> Distortion Field!
Today is Second Gouday, June.
Ray Dillinger
> Quoting Ray Dillinger <be...@sonic.net>:
>
>>The equality operator should just compare what the character
>>*knows* about the items and stack accordingly.
> This precludes a limited-size inventory, I would think.
It precludes a very peculiar kind of limited-size, I think.
Just because it happens to be the kind of limited-size that
*band uses, doesn't mean it is, or ever was, a good idea.
Bear
Gamer_2k4
Not necessarily. If only the descriptions are stacked (arrow and arrow
show up as "2 arrows") you can still figure out a maximum amount of
items one can hold, or maintain weight and bulk limits. Also, some
items could have a 'stack' flag that counts all instances of it as one
item, for size purposes. This way you could have a limit of 20 items,
but the arrows only take up one slot. Either way, the inventory could
still be limited.
Gamer_2k4
David Damerell
And NetHack, and - well - every game with a limited-size inventory that
springs to mind.
What are _you_ thinking of?
--
OPTIONS=name:Kirsty,menustyle:C,female,lit_corridor,standout,time,showexp,hilit
e_pet,catname:Akane,dogname:Ryoga,fruit:okonomiyaki,pickup_types:"!$?=/,scores:
5 top/2 around,color,boulder:0,autoquiver,autodig,disclose:yiyayvygyc,pickup_bu
rden:burdened,!cmdassist,msg_window:reversed,!sparkle,horsename:Rumiko,showrace
David Damerell
>David Damerell wrote:
>>Quoting Ray Dillinger <be...@sonic.net>:
>>>The equality operator should just compare what the character
>>>*knows* about the items and stack accordingly. This presumes
>>>that stacking is for generating display only, and not for
>>>data representation purposes.
>>This precludes a limited-size inventory, I would think.
>show up as "2 arrows") you can still figure out a maximum amount of
>items one can hold, or maintain weight and bulk limits.
Weight and bulk limits are not what I'm talking about, obviously. I mean
interface limits like those in Angband or NetHack. Now I don't think those
are actually a good thing - although Angband does have a peculiar slot
management subgame - but they certainly make an inventory easier to
program.
Ray Dillinger
> Quoting Ray Dillinger <be...@sonic.net>:
>>David Damerell wrote:
>>>This precludes a limited-size inventory, I would think.
>>It precludes a very peculiar kind of limited-size, I think.
>>Just because it happens to be the kind of limited-size that
>>*band uses, doesn't mean it is, or ever was, a good idea.
> And NetHack, and - well - every game with a limited-size inventory that
> springs to mind.
> What are _you_ thinking of?
I don't think it makes any sense to limit the number of
*kinds* of thing someone can carry. Do you think it should
be harder to carry fifteen arrows if they're of all different
kinds, than it is to carry fifteen arrows all alike? Why?
To me the inventory limitations that make sense are pack
size vs object size and strength versus weight. If the name
of the game is inventory management, let's give choices that
respond to limits a little less arbitrary than "number of
different kinds," yes?
Bear
Ray Dillinger
> Weight and bulk limits are not what I'm talking about, obviously. I mean
> interface limits like those in Angband or NetHack. Now I don't think those
> are actually a good thing - although Angband does have a peculiar slot
> management subgame - but they certainly make an inventory easier to
> program.
Ah. Well, there you go. A limited number of "Slots" are exactly
the peculiar kind of limited-size I was thinking of, and it
appears that you agree with me that they're not a good thing.
Bear
Adam White
[snip inventory discussion]
> I don't think it makes any sense to limit the number of *kinds* of thing
> someone can carry. Do you think it should be harder to carry fifteen
> arrows if they're of all different kinds, than it is to carry fifteen
> arrows all alike? Why?
It *is* harder if you're expected to know the difference between each
immediately on sight (as it is in RLs).
In my dev-RL-that-may-never-actually-be-finished I had originally planned
to have items which are described identically (subject to level of
identification performed, of course) stack into piles. I'm still tossing
that idea around - because I also like the concept of limited inventory
space. Nethack's 52 item limit in inventory and containers might be very
arbitrary, but it forces you to only carry what you need. ADOM's limitless
inventory breaks suspension of disbelief, for me.
The two concepts (superior stacking and limited inventory) don't play well
- what do you do if a quick /identify/ shows the pile of 52 arrows to be
all individually unique? Do you drop all-but-one of them because they no
longer stack and your inventory is already full?
The easiest solution is to have items stack only if they truly are
identical. It gives more knowledge to the player, of course, but I believe
that to be a good thing.
(Actually, for me, arrows are a special case - they automatically go into
a quiver slot, which is actually a container, so 52 unique arrows still
only take up the one quiver space in inventory).
Cheers,
Adam
Erik Piper
> Quoting Gamer_2k4 <game...@gmail.com>:
> >David Damerell wrote:
> >>Quoting Ray Dillinger <be...@sonic.net>:
> >>>The equality operator should just compare what the character
> >>>*knows* about the items and stack accordingly. This presumes
> >>>that stacking is for generating display only, and not for
> >>>data representation purposes.
> >>This precludes a limited-size inventory, I would think.
> >Not necessarily. If only the descriptions are stacked (arrow and arrow
> >show up as "2 arrows") you can still figure out a maximum amount of
> >items one can hold, or maintain weight and bulk limits.
>
> Weight and bulk limits are not what I'm talking about, obviously.
Incidentally, are there any roguelikes with *bulk* limits at *all*,
actually? I've never seen one.
Since I'm already off-topic, I might note that while bulk limits are
certainly realistic, would they be a good thing? E.g. your wizard's hat
probably needs to stay conical, and the hollow part probably is
unwieldy for squeezing things carrying capacity out of, and thus it
should be more of a problem to carry than a lead bar of the same weigh.
But can it really be *fun* to care about that? Maybe with enough
abstraction; maybe.
> I mean interface limits like those in Angband or NetHack.
MHO is that while these are obviously artificial, the spare time for
other features that they give the developer and the choices they force
upon the player, however heavy-handedly, outweigh the small blow to
suspension of disbelief. They also (very) roughly simulate the notion
of bulk and a backpack limited not only by weight, but also by volume.
Of course, if you didn't care about making things easy for the
programmer and interface designer, you could just have a volume- or
bulk-limited backpack directly. Why not, really?
One slight complication that I would add in such a system, though*, is
to charge "overhead bulk" for the mere existence of an inventory slot
-- even a single arrow is going to require some inefficiency in the
usage of your backpack to make sure it doesn't skewer your wizard's
hat. Of course this applies more for certain item types than others,
but perhaps that could be abstracted to a single average overhead value
while still feeling realistic.
* in the unlikely case that I ever actually design a roguelike... :-)
e.
Gerry Quinn
dame...@chiark.greenend.org.uk says...
> Quoting Ray Dillinger <be...@sonic.net>:
> >David Damerell wrote:
> >>Quoting Ray Dillinger <be...@sonic.net>:
> >>>The equality operator should just compare what the character
> >>>*knows* about the items and stack accordingly.
> >>This precludes a limited-size inventory, I would think.
> >It precludes a very peculiar kind of limited-size, I think.
> >Just because it happens to be the kind of limited-size that
> >*band uses, doesn't mean it is, or ever was, a good idea.
>
> And NetHack, and - well - every game with a limited-size inventory that
> springs to mind.
>
> What are _you_ thinking of?
Daggerfall had a seemingly unlimited wagon inventory.
- Gerry Quinn
Gerry Quinn
spu...@iinet.net.au says...
> The two concepts (superior stacking and limited inventory) don't play well
> - what do you do if a quick /identify/ shows the pile of 52 arrows to be
> all individually unique? Do you drop all-but-one of them because they no
> longer stack and your inventory is already full?
>
> The easiest solution is to have items stack only if they truly are
> identical. It gives more knowledge to the player, of course, but I believe
> that to be a good thing.
Haven't we forgotten the Rogue option?
You have:
(a) 9 puce arrows
(b) A plaid arrow
(c) 4 iridescent arrows
- Gerry Quinn
Gamer_2k4
> You have:
> (a) 9 puce arrows
> (b) A plaid arrow
> (c) 4 iridescent arrows
A plaid arrow...that's pretty funny (maybe we're referring to fletching
color). Btw, does anyone actually know what color puce is?
Gamer_2k4
Gamer_2k4
> Incidentally, are there any roguelikes with *bulk* limits at *all*,
> actually? I've never seen one.
Many people consider Castle of the Winds to be a roguelike, and that
game uses weight and bulk as pack limiters.
> Since I'm already off-topic, I might note that while bulk limits are
> certainly realistic, would they be a good thing? E.g. your wizard's hat
> probably needs to stay conical, and the hollow part probably is
> unwieldy for squeezing things carrying capacity out of, and thus it
> should be more of a problem to carry than a lead bar of the same weigh.
> But can it really be *fun* to care about that? Maybe with enough
> abstraction; maybe.
There's no reason to make this completely realistic. An arrow has low
bulk. A shield has high bulk. A lead bar has low bulk but is heavy.
A wizard's hat is compressable, so it probably has low bulk. This
method IMO is better than the current model of "I have Strength of
Atlas on, so I can carry dozens of plate mails!" Speaking of which,
remember that ring mails would have a very low bulk (remember the
mithril armor in LoTR?)
Jeff Lait
> David Damerell wrote:
> >
> > Weight and bulk limits are not what I'm talking about, obviously.
>
> Incidentally, are there any roguelikes with *bulk* limits at *all*,
> actually? I've never seen one.
Diablo has Bulk Limits but no Weight Limits. I seem to recall Baldur's
Gate, which is not a roguelike, has both Bulk and Weight limits.
One could argue that Nethack has bulk & weight limits with the "slots"
measuring the bulk. The idea that 10 copies of something has the same
bullk as one copy may not be too intuitive, but it does seem to be an
orthogonal limit to the weight requirement.
> Since I'm already off-topic, I might note that while bulk limits are
> certainly realistic, would they be a good thing? E.g. your wizard's hat
> probably needs to stay conical, and the hollow part probably is
> unwieldy for squeezing things carrying capacity out of, and thus it
> should be more of a problem to carry than a lead bar of the same weigh.
> But can it really be *fun* to care about that? Maybe with enough
> abstraction; maybe.
I'm not so convinced that *weight* is fun to keep track of. For
limitted inventory, a strict bulk based approach makes more sense to
me. It is easier to tell if another item will fit or not fit. Weight
based systems always seem to run into the issue of random
dropping/picking up to try and avoid the Burdened barrier.
> > I mean interface limits like those in Angband or NetHack.
>
> MHO is that while these are obviously artificial, the spare time for
> other features that they give the developer and the choices they force
> upon the player, however heavy-handedly, outweigh the small blow to
> suspension of disbelief. They also (very) roughly simulate the notion
> of bulk and a backpack limited not only by weight, but also by volume.
>
> Of course, if you didn't care about making things easy for the
> programmer and interface designer, you could just have a volume- or
> bulk-limited backpack directly. Why not, really?
A volume or bulk-limitted backpack would be easier for the programmer
than Nethack's slot based system. The problem is it would become a lot
harder for the player who has to deal with two hidden variables
tracking what they can carry.
E. Liddell
>Btw, does anyone actually know what color puce is?
It's in the dark red to purple range, apparently.
The word derives from the French for "flea".
Radomir 'The Sheep' Dopieralski
Gamer_2k4 wrote:
From WordNet (r) 2.0 [wn]:
puce
n : a color varying from dark purplish brown to dark red
Erik Piper
> Erik Piper wrote:
> > David Damerell wrote:
[DD: inventory limiting methods -- what do folks think of NH/*band
style limited slots? EP: meandering off to bulk/volume limitation]
> One could argue that Nethack has bulk & weight limits with the "slots"
> measuring the bulk.
Considering my comments later on in my original post (which I may snip
below) it looks like great minds think alike. :-)
> The idea that 10 copies of something has the same
> bullk as one copy may not be too intuitive, but it does seem to be an
> orthogonal limit to the weight requirement.
^^^^^^^^^^
Would that be "Of or relating to a matrix whose transpose equals its
inverse" or "Of or relating to a linear transformation that preserves
the length of vectors"? (Unfortunately, it almost certainly won't be
"relating to or composed of right angles," as in orthogonal
(POWDER-style) movement, which I can at least understand.)
B-b-b-b-b-b-b...
> > Since I'm already off-topic, I might note that while bulk limits are
> > certainly realistic, would they be a good thing? E.g. your wizard's hat
> > probably needs to stay conical, and the hollow part probably is
> > unwieldy for squeezing [...] carrying capacity out of, and thus it
> > should be more of a problem to carry than a lead bar of the same weigh.
> > But can it really be *fun* to care about that? Maybe with enough
> > abstraction; maybe.
>
> I'm not so convinced that *weight* is fun to keep track of. For
> limitted inventory, a strict bulk based approach makes more sense to
> me. It is easier to tell if another item will fit or not fit.
For the programmer it seems it would be the same -- comparing bulk to
bulk_capacity vs. weight to weight_capacity, all the same, no? Unless
we go with a M&M VI-VIII model (more on that in a bit), where it seems
it almost certainly would be harder than a weight-based system. (Usual
disclaimer: IANAP, just an inquisitive layman with some source-diving
experience.)
> Weight
> based systems always seem to run into the issue of random
> dropping/picking up to try and avoid the Burdened barrier.
Is that a problem if realism isn't a concern? I know at least two
people where I could dig up posts [1] claiming it isn't: myself and
RDH, and that view may be more widespread than that (how widespread
depends on how much internal consistency and promoting suspension of
disbelief is counted into realism in the discussion; I certainly *am* a
fan of both of these, especially the latter).
[1] Maybe not for myself, actually. But I guess we can now count this
one.
It may indeed still be a problem in terms of a futzy little thing with
a large effect, penalizing people who don't like to do futzy little
things, which is, I assert, non-controversially Bad. So, in the end,
OK.
Though I raise my eyebrows at "random" -- at least two major roguelikes
(Crawl and ADOM) provide weight information and burden level threshold
information quite transparently, so the player won't be doing that
randomly. (Perhaps you used the word for dramatic effect.)
> > > I mean interface limits like those in Angband or NetHack.
> >
> > MHO is that while these are obviously artificial, the spare time for
> > other features that they give the developer and the choices they force
> > upon the player, however heavy-handedly, outweigh the small blow to
> > suspension of disbelief. They also (very) roughly simulate the notion
> > of bulk and a backpack limited not only by weight, but also by volume.
> >
> > Of course, if you didn't care about making things easy for the
> > programmer and interface designer, you could just have a volume- or
> > bulk-limited backpack directly. Why not, really?
>
> A volume or bulk-limitted backpack would be easier for the programmer
> than Nethack's slot based system.
You wouldn't give Nethack/Angband ease-of-programming points for the
fact that you can map every possible inventory slot onto something that
the player can enter directly from the keyboard? Or they just wouldn't
count for enough to outweigh the ease-of-programming benefits for
bulk-limiting?
There's one bulk-limiting implementation hinted at above that I've seen
that's really neat, but about which I doubt you'd make the above
assertion. Volumes 6-8 (at least) of the Might and Magic series have a
rectangle of tiles for each character's inventory, and objects each
cost some rectangle of tiles (with 1x1 as a possibility). It's quite
clear, quite simple, and yet yet challenging in its own way for the
player. (Though ISTR some unpleasant interface quirks that made it not
as good as it could have been.) It would be way harder to program than
a weight/slot limit even outside of its practically forcing one to do a
graphical roguelike, though.
"Bulk out of proportion to volume" was elegantly, if hackishly (but
isn't that the same thing? :-)) represented in that system by things
like the gaping whitespace around the top of one's conical hat. :-) Of
course, a pure-bulk system is probably plenty just-fine-elegant as well
-- no player is going to raise eyebrows when they see that a what must
be [2] a few ounces of pillow costs as much bulk as what must be a
pound of gold.
[2] or "what is stated as", if it's a hybrid "don't exceed bulk OR
weight limit" system.
> The problem is it would become a lot
> harder for the player who has to deal with two hidden variables
> tracking what they can carry.
Only if they're hidden in the first place! I already despise the single
hidden variable in Nethack -- I think it's for good reason that Crawl,
Angband, and ADOM make it explicit. Nethack's ounce of bulky realism
costs it a pound of gameplay here in my eyes. :-)
And with a bulk system, any eventual realism fanatics have a lot less
to complain about/ base argumentation on -- are you really going to
claim that the player can't tell if they can put something in their
backpack or not? They try to cram it in, and (possibly with
modification for a packing skill of course) they're either able to, or
not, what's "hard for the PC to know" about *that*?
Actually, with a hybrid system, maybe realists could be somewhat
appeased and item weights *could* viably stay hidden or approximated
("It is light/heavy/very heavy"), since unless you implement a Backpack
of Doom or a Packing Skill of Doom (so don't implement those, then), I
suspect hard [3] bulk limits will come long before hard weight limits,
and if soft weight limits are implemented Angband-style or even less
granularly, the incentive to game the thresholds can perhaps be kept to
a minimum.
[3] Hmm... soft bulk limits? "Putting more +3 socks into this Feydor's
Curious Suitcase may cause permanent damage to other items. Continue
anyway?" :-D Probably a bad design idea...
Erik Piper, armchair game designer extraordinaire
Elethiomel
> Jeff Lait wrote:
>>The idea that 10 copies of something has the same
>>bullk as one copy may not be too intuitive, but it does seem to be an
>>orthogonal limit to the weight requirement.
>
> ^^^^^^^^^^
>
> Would that be "Of or relating to a matrix whose transpose equals its
> inverse" or "Of or relating to a linear transformation that preserves
> the length of vectors"? (Unfortunately, it almost certainly won't be
> "relating to or composed of right angles," as in orthogonal
> (POWDER-style) movement, which I can at least understand.)
> B-b-b-b-b-b-b...
>
I believe it is here meant to mean "not intristically linked", and thus
has more to do with right angles than it would seem at first. A change
in bulk does not neccessitate a change in weight (your wizard's hat was
crushed and is no longer a stiff cone, but still weighs the same), and
vice versa (you fill a bottle with water, it now weighs more but does
not take the same volume) - thus the weight limit and the bulk limit are
on axes orthogonal to each other, that is axes that are on right angles
compared to one another so that if you add something along one axis, it
doesn't directly influence the value along the other axis.
Um. Was that clear at all?
--
A good signature is a concise and original summary of personality. This
is not a good signature.
Elethiomel
> vice versa (you fill a bottle with water, it now weighs more but does
> not take the same volume) - thus the weight limit and the bulk limit are
Doh, it weighs more but *still* takes the same volume.
Gerry Quinn
Or to put it another way, the problem space now has two dimensions,
because a value on one axis cannot be transformed into that on the
other.
- Gerry Quinn
Jeff Lait
Erik Piper wrote:
> Jeff Lait wrote:
>
> > bullk as one copy may not be too intuitive, but it does seem to be an
> > orthogonal limit to the weight requirement.
> ^^^^^^^^^^
>
> Would that be "Of or relating to a matrix whose transpose equals its
> inverse" or "Of or relating to a linear transformation that preserves
> the length of vectors"? (Unfortunately, it almost certainly won't be
> "relating to or composed of right angles," as in orthogonal
> (POWDER-style) movement, which I can at least understand.)
> B-b-b-b-b-b-b...
It is certainly "relating to or composed of right angles". It is
another way of saying that bulk and weight are independent variables.
With real coefficients for bulk and weight, we can define a vector
space span{b, w} where b and w are the unit of bulk and unit of weight
vectors. To say that b & w are orthogonal is to say that the inner
(dot) product of b and w is 0.
For a visual comparison, consider the two dimensional vectors (1, 1)
and (1, 0). The first is a diagonal arrow going up and right, the
second an arrow going right along the x-axis. Note that span{(1,1),
(1,0)} = R2, ie, every value in the plane can be expressed as a
combination of these two vectors. We can, for every point (x,y) on the
plane, find two unique numbers "b" and "w" such that (x,y) = b(1,1) +
w(1,0). This would thus give a way to derive a bulk & weight value
from a two dimensional space where the bulk and weight are not
orthogonal. The inner product is 1, not 0.
I do appreciate the POWDER reference.
> > I'm not so convinced that *weight* is fun to keep track of. For
> > limitted inventory, a strict bulk based approach makes more sense to
> > me. It is easier to tell if another item will fit or not fit.
>
> For the programmer it seems it would be the same -- comparing bulk to
> bulk_capacity vs. weight to weight_capacity, all the same, no? Unless
> we go with a M&M VI-VIII model (more on that in a bit), where it seems
> it almost certainly would be harder than a weight-based system. (Usual
> disclaimer: IANAP, just an inquisitive layman with some source-diving
> experience.)
I was indeed referring to the M&M model (despite not having played it).
My model in question was Diablo II which uses the same box + shaped
item approach to inventory management.
This isn't that much harder for the programmer, especially as one isn't
expected to find the optimal sort for the user, but leave that box
packing problem as a minigame for the player.
> > Weight
> > based systems always seem to run into the issue of random
> > dropping/picking up to try and avoid the Burdened barrier.
>
> Is that a problem if realism isn't a concern? I know at least two
> people where I could dig up posts [1] claiming it isn't: myself and
> RDH, and that view may be more widespread than that (how widespread
> depends on how much internal consistency and promoting suspension of
> disbelief is counted into realism in the discussion; I certainly *am* a
> fan of both of these, especially the latter).
>
> [1] Maybe not for myself, actually. But I guess we can now count this
> one.
>
> It may indeed still be a problem in terms of a futzy little thing with
> a large effect, penalizing people who don't like to do futzy little
> things, which is, I assert, non-controversially Bad. So, in the end,
> OK.
>
> Though I raise my eyebrows at "random" -- at least two major roguelikes
> (Crawl and ADOM) provide weight information and burden level threshold
> information quite transparently, so the player won't be doing that
> randomly. (Perhaps you used the word for dramatic effect.)
I used the word because I've played too much Nethack :> I think we
both agree about the correct implementation of weight based systems.
> > A volume or bulk-limitted backpack would be easier for the programmer
> > than Nethack's slot based system.
>
> You wouldn't give Nethack/Angband ease-of-programming points for the
> fact that you can map every possible inventory slot onto something that
> the player can enter directly from the keyboard? Or they just wouldn't
> count for enough to outweigh the ease-of-programming benefits for
> bulk-limiting?
Mapping every inventory letter to a keyboard letter is harder
programming than the traditional approach of just presenting people
pages of text to scroll through. As soon as you do that, you also run
into the sticky inventory letter issue which adds lots of interesting
issues.
> There's one bulk-limiting implementation hinted at above that I've seen
> that's really neat, but about which I doubt you'd make the above
> assertion. Volumes 6-8 (at least) of the Might and Magic series have a
> rectangle of tiles for each character's inventory, and objects each
> cost some rectangle of tiles (with 1x1 as a possibility). It's quite
> clear, quite simple, and yet yet challenging in its own way for the
> player. (Though ISTR some unpleasant interface quirks that made it not
> as good as it could have been.) It would be way harder to program than
> a weight/slot limit even outside of its practically forcing one to do a
> graphical roguelike, though.
This sounds very much like the Diablo method that I referred to as an
example of a bulk only approach.
R. Dan Henry
>Since I'm already off-topic, I might note that while bulk limits are
>certainly realistic, would they be a good thing?
While in some sense realistic, any implementation simple enough to
actually enact is going to be unrealistic, unless your world issues
items in the form of standardized boxes. Although it does allow for a
Packing skill to increase your bulk limit as you arrange your goods more
efficiently.
David Damerell
>David Damerell wrote:
>>And NetHack, and - well - every game with a limited-size inventory that
>>springs to mind.
>>What are _you_ thinking of?
>I don't think it makes any sense to limit the number of
>*kinds* of thing someone can carry.
I don't think it makes much sense, but that's what I mean by a
limited-size inventory as opposed to weight or bulk limits. What else
might I have meant?
[And I think you tend to get one because of the ease of inventory
management commands under such a constraint.]
--
David Damerell <dame...@chiark.greenend.org.uk> Kill the tomato!
Today is Mania, Presuary.
David Damerell
>Jeff Lait wrote:
>>One could argue that Nethack has bulk & weight limits with the "slots"
>>measuring the bulk.
>Considering my comments later on in my original post (which I may snip
>below) it looks like great minds think alike. :-)
Well, I wouldn't. 250 identical potions fit in a slot, giving them the
same bulk as one, but 2 potions that look just the same (but have
different BUC state) don't?
>You wouldn't give Nethack/Angband ease-of-programming points for the
>fact that you can map every possible inventory slot onto something that
>the player can enter directly from the keyboard?
I suggested to TDT, when the limit of 52 is exceeded, popping open one
slot into 26 double-letter slots (not 52, because the Shift-bouncing for
that would be nightmarish). They weren't keen, but it seems to me it
preserves the ease of the single-letter inventory unless the player
deliberately decides to have a vast stack of junk. 52's a lot, too - it's
actually reasonably hard to overflow it without falling afoul of the
weight limits.
Erik Piper
> Quoting Erik Piper <er...@sky.cz>:
> >Jeff Lait wrote:
> >>One could argue that Nethack has bulk & weight limits with the "slots"
> >>measuring the bulk.
> >Considering my comments later on in my original post (which I may snip
> >below) it looks like great minds think alike. :-)
>
> Well, I wouldn't. 250 identical potions fit in a slot, giving them the
> same bulk as one, but 2 potions that look just the same (but have
> different BUC state) don't?
"Highly, *very* highly abstracted, causing gross oversimplifications
with silly artifacts" is not the same as "not present at all."
e.
R. Dan Henry
<dame...@chiark.greenend.org.uk> wrote:
>Well, I wouldn't. 250 identical potions fit in a slot, giving them the
>same bulk as one, but 2 potions that look just the same (but have
>different BUC state) don't?
It's like a form of magnetism, only with 3 poles and a rule of "alike
attracts, different repels", so you have to store blessed, uncursed, and
cursed potions separately, or the whole thing will going flying apart.
Crypt
> Things which are harder to code than one might initially think
> -------------------------------------------------------------------------------
>
> Invisibility
> Polymorph-self
> Charm monster
> Stacking objects
> Friendly NPCs in the dungeon
> . ..?
>
>
>
IMO display/hiding of walls when using a LOS and lighting sources.
Determining wich wall must be displayed when the character see/doesn't see the
lighting source but see the light coming from it and the source is behind the
wall, etc..... can be very tricky.
Crypt
> In article ,
I did not planned stacking but i find it strange you all speak of it as a
difficult task.
Maybe i don't see the iceberg but i think this problem must not be solved by
"stacking the objects" but simply by "stacking the display of them" in the
inventory.
I mean the inventory array must never have stacked objects inself.
The stacking analysis (whatever it would be) would only occur when displaying
inventory informations to the player.
Then the stacking rules are purely a matter of taste and can follow options
(stacking similar kind of objects or true clones with similar values, etc)
Is the stacking analysis so hard ?
Ray Dillinger
> Is the stacking analysis so hard ?
I'm with you - the stacking analysis isn't hard at all.
Names visible to player are identical -> stack.
Names visible to player are different -> don't stack.
The difficulty with stacking only afflicts those who
have decided for UI reasons that they will enforce a
"No more than 24 different kinds of thing in
inventory" rule. Once you do that, you have a lot of
tradeoffs to consider, none of which seem worthwhile
to sweat over to me.
Inventory limitation to me means character strength,
number of hands, and pack volume.
Bear
Gerry Quinn
> On 2006-06-06 03:05:50, "Antoine" <ma...@guildgame.com> wrote:
>
> > Things which are harder to code than one might initially think
> > -------------------------------------------------------------------------------
> >
> > Invisibility
> > Polymorph-self
> > Charm monster
> > Stacking objects
> > Friendly NPCs in the dungeon
> IMO display/hiding of walls when using a LOS and lighting sources.
> Determining wich wall must be displayed when the character see/doesn't see the
> lighting source but see the light coming from it and the source is behind the
> wall, etc..... can be very tricky.
Even if the only lighting source is a character, it's not all that
trivial, if you are to consider partially-visible squares.
Currently my algorithm for those is simply wrong, but usually not
embarrassingly so. Since it usually looks okay, and affects only what
you can see, it's on a very low priority for fixing.
Fortunately, centre-to-centre visibility is easy to implement
rigorously, and is the only LOS you need that has tactical
consequences.
- Gerry Quinn
Gerry Quinn
> I did not planned stacking but i find it strange you all speak of it as a
> difficult task.
> Maybe i don't see the iceberg but i think this problem must not be solved by
> "stacking the objects" but simply by "stacking the display of them" in the
> inventory.
> I mean the inventory array must never have stacked objects inself.
> The stacking analysis (whatever it would be) would only occur when displaying
> inventory informations to the player.
> Then the stacking rules are purely a matter of taste and can follow options
> (stacking similar kind of objects or true clones with similar values, etc)
That is one approach, but I'm not sure it is so great. I do not say it
can't be done, but you do have an issue when an effect transparent to
the player disappears.
For example, suppose the inventory contains 9 arrows of fire and 15
arrows of fire, and the display is 24 arrows of fire. If the 9 and 15
are held separately, the bow must choose to change to the 15 arrows of
fire, rather than the 8 arrows of poison, when the 9 arrows of fire
have run out.
I find stacking works okay, but I limit it to certain kinds of
'charged' objects. If I take possession of a stackable object that is
identical to an object in the inventory except for its unique object ID
and its number of charges, it is destroyed, and its charges are added
to those of the inventory object. If the resulting charge exceeds the
stacking limit, a new object is created to hold the excess. Potions
are stackable to 5, arrows to 100, wands are not stackable. It's that
simple.
Every time Player::TakeItem(Item&) is called, it runs through the
inventory to find an item that the taken item can be stacked with. If
I do Identify scrolls at some point, they will take away the
unidentified items, and then give identified ones to the player.
Currently, I kludge miscellaneous useless objects that I want to make
stackable by giving them a null spell with one charge (which makes them
stackable by default) but I will probably develop a more formal system
in time.
= Gerry Quinn
Crypt
> In article , crypt...@free.fr says...
> > On 2006-06-06 03:05:50, "Antoine" wrote:
> >
> > > Things which are harder to code than one might initially think
> > > -------------------------------------------------------------------------------
> > >
> > > Invisibility
> > > Polymorph-self
> > > Charm monster
> > > Stacking objects
> > > Friendly NPCs in the dungeon
>
> > IMO display/hiding of walls when using a LOS and lighting sources.
> > Determining wich wall must be displayed when the character see/doesn't see the
> > lighting source but see the light coming from it and the source is behind the
> > wall, etc..... can be very tricky.
>
> Even if the only lighting source is a character, it's not all that
> trivial, if you are to consider partially-visible squares.
>
> Currently my algorithm for those is simply wrong, but usually not
> embarrassingly so. Since it usually looks okay, and affects only what
> you can see, it's on a very low priority for fixing.
>
> Fortunately, centre-to-centre visibility is easy to implement
> rigorously, and is the only LOS you need that has tactical
> consequences.
>
> - Gerry Quinn
>
>
In the current version of CryptRL i have the following problem =
A wall, a lighting source and the character.
When the lighting source and the character are on the same side of the wall,
it's OK =
http://cryptmaster.free.fr/cryptrl/Screenshots/test/crl1ok.jpg
When the character is on the other side (the dark one) of the wall and DOESN'T
see the lighting source, it's still OK =
http://cryptmaster.free.fr/cryptrl/Screenshots/test/crl2ok.jpg
But when the character is on the other side (the dark one) of the wall and SEES
the lighting source there is a problem = some walls are displayed which sould
realistically not be =
http://cryptmaster.free.fr/cryptrl/Screenshots/test/crl3wrong.jpg
Crypt
>arrows of fire, and the display is 24 arrows of fire.
I wouldn't do that, i would use an inventory array containing 24 differents
objects.
I think that in a MVC model point of view you should not solve the stacking
problem by stacking objects in mutiple arrays because the only goal of stacking
is to help the ***player*** having a clear view of the character inventory.
It has nothing to do with the "computer point of view".
Crypt
> R. Dan Henry wrote:
> > On Tue, 06 Jun 2006 14:23:19 +0200, Kornel Kisielewicz
> > wrote:
> >
> > >Antoine napisa?(a):
> > >> Things which are harder to code than one might initially think
> > >> -------------------------------------------------------------------------------
> > >>
> > >> Invisibility
> > >> Polymorph-self
> > >> Charm monster
> > >> Stacking objects
> > >> Friendly NPCs in the dungeon
> > >> ....?
> > >
> > >Oh man, I forgot about three most important ones:
> > >
> > >Adding content
> > >Balancing
> > >Polishing
> >
> > But these don't *seem* easy -- that's why so many "engine" projects get
> > started, to avoid this obviously hard work.
>
> Actually, I think the problem is that people *do* think that those
> tasks are easy. Thus, they figure they'll tackle the "Hard" task of
> Invisibility first. All the content/balancing/polishing can then be
> done in a fortnight once their game engine is complete.
lol, this is exactly the way i think....
I would not say adding content/balancing is 'easy' but i think it's not the main
problem. IMHO, having a strong classes structure and a flexible engine is the
priority.
Gerry Quinn
> >For example, suppose the inventory contains 9 arrows of fire and 15
> >arrows of fire, and the display is 24 arrows of fire.
>
> I wouldn't do that, i would use an inventory array containing 24 differents
> objects.
That's a big array - in a typical roguelike one could have thousands of
arrows.
> I think that in a MVC model point of view you should not solve the stacking
> problem by stacking objects in multiple arrays because the only goal of stacking
> is to help the ***player*** having a clear view of the character inventory.
> It has nothing to do with the "computer point of view".
I think you have misinterpreted me. A stack of arrows is not an array
of arrows - it's a single object with a charge equivalent to the number
of arrows.
At any time I can combine two such objects by destroying one and adding
its charge to the other, or split it by creating a new object of the
same kind and dividing the charge between them.
Like potions, arrow objects will be destroyed when their charge reaches
zero.
- Gerry Quinn
Crypt
Imagine one of the arrow of fire is cursed while the others are not.
If you create a new PackOfFireArrows how do you keep this property ?
If you only stack real clones then this cursed arrow would not be stacked with
the others and the player would know that it's not equals to the others
arrows.
Of course you can solve this by using temporary objects which would keep the
individual stacked arrows properties but it would be non-sense because arrays
of objects are a lot more simpler and more efficients.
Crypt
> > objects.
>
> That's a big array - in a typical roguelike one could have thousands of
> arrows.
>
ArrayList, Vector, etc... i don't know how it's name in the langage you used can
contains any number of objects.
IMO, thousands of objects in the inventory array would not be the main source of
memory problems. (what i say is very general, it depends on how you use this
array)
> > I think that in a MVC model point of view you should not solve the stacking
> > problem by stacking objects in multiple arrays because the only goal of stacking
> > is to help the ***player*** having a clear view of the character inventory.
> > It has nothing to do with the "computer point of view".
>
> I think you have misinterpreted me. A stack of arrows is not an array
> of arrows - it's a single object with a charge equivalent to the number
> of arrows.
>
IMO putting containers (arrays) into containers would have been the less
problematic non-display solution.
I think creating a new object instead of putting arrows in an array* is even
worse and could lead to a lot of confusions
Where are the single arrows when you create this PackOfArrows object ?
Do you destroy/recreacte them each time you need to ?
* which in fact is probably an object in the language you use.
Crypt
of course the PackOfFireArrows could have a NUMBEROFCURSEDOBJECT
property.........but how many such counting properties would you finally have
to add ?
lochok
Hint: See ADOM... it works fine there
From what I can see, about a 1/4 are blessed, 1/2 are uncursed and another
1/4 are blessed. Therefore, you don't know which stack are cursed until
its too late (mwa ha ha ha ha)
Lochok
Crypt
implement arrows in my game)
right now i think i will use a class called Pack which in fact would contains*
similar objects (depending on the object type, all 'arrows of fire', all
'rocks', etc.)
This pack could contains not so similar objects : for instance 9 normal fire
arrows and 1 cursed fire arrow as long as the character has not identified this
cursed property.
When the cursed arrow is identified then it would be remove from the pack and
add to the inventory.
* the fact that this Pack actually contains other objects is the main difference
with your solution.
The Pack could have thousands of objects without losing any of there hidden
properties.
Gerry Quinn
> > I think you have misinterpreted me. A stack of arrows is not an array
> > of arrows - it's a single object with a charge equivalent to the number
> > of arrows.
> >
> IMO putting containers (arrays) into containers would have been the less
> problematic non-display solution.
>
> I think creating a new object instead of putting arrows in an array* is even
> worse and could lead to a lot of confusions
>
> Where are the single arrows when you create this PackOfArrows object ?
> Do you destroy/recreacte them each time you need to ?
The single arrows never existed. I create an object, say ten arrows,
on the stack, and then I offer it to something that can carry objects
(players with inventories, the dungeon map, a trader etc.). If it
accepts, it copies the object onto whatever data structure it uses to
hold its objects. Then the object I created goes out of scope and
disappears.
If I give it to a character, and I subsequently offer him seven arrows
of the same kind, he will accept, but instead of copying it, will add
seven charges to the current ten.
Later, as he fires arrows, the charges drop by one each time. When
they reach zero, the arrows object is destroyed. Potions are destroyed
when they reach zero charges too.
By contrast, wands don't stack, and stick around when they reach zero
charges.
- Gerry Quinn
Gerry Quinn
> and...
>
> Imagine one of the arrow of fire is cursed while the others are not.
> If you create a new PackOfFireArrows how do you keep this property ?
>
> If you only stack real clones then this cursed arrow would not be stacked with
> the others and the player would know that it's not equals to the others
> arrows.
Correct. That is what will happen. By the same token, non-identified
objects of a kind will not stack with identified objects of the same
kind.
That is all assuming that I have identification and cursing in the
first place - I don't consider them very important. Probably
identification will be present in some form for rare objects, though.
An example I have thought of where this will happen is that you may
have a poison potion which you can dip arrows with. It can poison up
to (say) twenty arrows. If you use it on 86 arrows, you will get 66
arrows and 20 poisoned arrows, which will be separate items.
> Of course you can solve this by using temporary objects which would keep the
> individual stacked arrows properties but it would be non-sense because arrays
> of objects are a lot more simpler and more efficients.
I don't see the issue as a problem to be solved. Non-clones don't
stack, it's that simple. Objects can't be stacked if they differ other
than in their charges, and the unique object ID that each object is
given at creation. Some types of objects such as wands can never
stack.
- Gerry Quinn
Gerry Quinn
ger...@DELETETHISindigo.ie says...
> In article <e8irt0$hg0$1...@news.vol.cz>, crypt...@free.fr says...
>
> > > I think you have misinterpreted me. A stack of arrows is not an array
> > > of arrows - it's a single object with a charge equivalent to the number
> > > of arrows.
> > >
> > IMO putting containers (arrays) into containers would have been the less
> > problematic non-display solution.
> >
> > I think creating a new object instead of putting arrows in an array* is even
> > worse and could lead to a lot of confusions
> >
> > Where are the single arrows when you create this PackOfArrows object ?
> > Do you destroy/recreacte them each time you need to ?
>
> The single arrows never existed. I create an object, say ten arrows,
> on the stack, and then I offer it to something that can carry objects
> (players with inventories, the dungeon map, a trader etc.). If it
> accepts, it copies the object onto whatever data structure it uses to
> hold its objects. Then the object I created goes out of scope and
> disappears.
It occurs to me that you may be assuming that arrows that miss will end
up littering the dungeon. I wasn't planning to bother with that at all
- ammo, once fired, is gone. Picking up arrows is boring.
But if I want to create single arrows and drop them on a floor square
(i.e. offer them to the dungeon map) when I miss, I can do that without
difficulty. I'd probably then want to implement stacking for the
single item a square can hold, though.
- Gerry Quinn
Crypt
> In article , crypt...@free.fr says...
so you don't use real containing objects like quivers ?
Gerry Quinn
> well, maybe the pure display solution is not the good one (i don't have yet
> implement arrows in my game)
I don't either, but I have darts and they work fine.
> right now i think i will use a class called Pack which in fact would contains*
> similar objects (depending on the object type, all 'arrows of fire', all
> 'rocks', etc.)
> This pack could contains not so similar objects : for instance 9 normal fire
> arrows and 1 cursed fire arrow as long as the character has not identified this
> cursed property.
>
> When the cursed arrow is identified then it would be remove from the pack and
> add to the inventory.
>
> * the fact that this Pack actually contains other objects is the main difference
> with your solution.
> The Pack could have thousands of objects without losing any of there hidden
> properties.
If the hidden properties of otherwise identical objects are important
to your game concept, you should go for it. For me it smacks of
'simulationism'. I can still have hidden properties of objects, and I
don't see any major gameplay issues arising from the restriction on
stackability.
Of course a pack is a reasonable solution even if restricted to
identical objects. Maybe my simple charge-based system will come back
to bite me. But I think it's adequate.
- Gerry Quinn
Gerry Quinn
> so you don't use real containing objects like quivers ?
No. I thought they were an unnecessary complication.
- Gerry Quinn
Gamer_2k4
> difficult task.
> Maybe i don't see the iceberg but i think this problem must not be solved by
> "stacking the objects" but simply by "stacking the display of them" in the
> inventory.
> I mean the inventory array must never have stacked objects inself.
> The stacking analysis (whatever it would be) would only occur when displaying
> inventory informations to the player.
> Then the stacking rules are purely a matter of taste and can follow options
> (stacking similar kind of objects or true clones with similar values, etc)
> Is the stacking analysis so hard ?
Ah, retrospect. I stacked the items in my game, and then displayed the
items as they were. Display stacking seems easier than item stacking,
but it's too late to change it now (translation: I really don't want to
do it). I suppose each system has different implications in terms of
coding as far as skill usage, spells, equipping, dropping, etc. I
don't think item stacking will become too big of a problem, but I may
be wrong. Is it better to fix it now or get used to it in the long
run?
Gamer_2k4