Item grouping

[Guest]

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

I'm currently trying to write item code in my game and I wonder how to
make items group. I see two ways to do this:
* Items would be grouped in code by adding "item count" property to
class. This would be very convenient way but would need adding some
spreaded code. One item object, which can represent many items, is bound
to one letter.
* They will be grouped only in players eyes. Program scans the list of
items to count how many of them are with the same properties and then
display list. This way is slow, but it will probably need only one big
algoritm. One letter is bound to one item too, but if this item is
dropped/changed/destroyed the letter must be bound to another item.

--
Milesss
m i l e s s s @ i n t e r i a . p l
www.milesss.mylog.pl
"/0"

 

[Guest]

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

Milesss wrote:
> I'm currently trying to write item code in my game and I wonder how to
> make items group. I see two ways to do this:
> * Items would be grouped in code by adding "item count" property to
> class. This would be very convenient way but would need adding some
> spreaded code. One item object, which can represent many items, is bound
> to one letter.
> * They will be grouped only in players eyes. Program scans the list of
> items to count how many of them are with the same properties and then
> display list. This way is slow, but it will probably need only one big
> algoritm. One letter is bound to one item too, but if this item is
> dropped/changed/destroyed the letter must be bound to another item.
>

well... in HA! I have every item as an individual object until it is
added to the player's inventory, at which point I check to see if the
player already has one of that item. If he/she does, then I just
increment the quantity property of the existing object in inventory and
destroy the other object. (This assumes they are identical items of course)

If at some point, the player decides to equip this item, I decrement the
quantity property of the item in inventory and then create a new object
of the specific instance of the item, which gets assigned to an
equippable body slot.

It works the same way if you pick something up and then later decide to
drop it. while it's in your inventory, it may be an object, or it may
just be reflected in the quantity of an object that was already there.
Once you decide to drop the item, I just decrement the quantity and
create a new object of the same type on the ground at your feet.

Works for me, it's easy to code and maintain (as well as add new stuff
to the mix without having to recode my inventory system)

S.

 

[Guest]

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

Dnia Thu, 26 May 2005 22:54:24 +0200,
Milesss napisal(a):

> I'm currently trying to write item code in my game and I wonder how to
> make items group. I see two ways to do this:
> * Items would be grouped in code by adding "item count" property to
> class. This would be very convenient way but would need adding some
> spreaded code. One item object, which can represent many items, is bound
> to one letter.
> * They will be grouped only in players eyes. Program scans the list of
> items to count how many of them are with the same properties and then
> display list. This way is slow, but it will probably need only one big
> algoritm. One letter is bound to one item too, but if this item is
> dropped/changed/destroyed the letter must be bound to another item.

It depends on what you want to do with items in your game. The latter is
more universal, but if you don't need it -- well, you don't need it .

In my project I go for a hybrid approach -- the inventory slots are
containers, and as such can hold multiple (even different) items.
Whenever you issue on them a command that only works on a single item,
a random item is selected.

--
Radomir @**@_ Bee! The quest for the Real World:
`The Sheep' ('') 3 Try #2: goto -1
Dopieralski .vvVvVVVVVvVVVvv.

 

[Guest]

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

On Thu, 26 May 2005 22:54:24 +0200, Milesss wrote:

> I'm currently trying to write item code in my game and I wonder how to
> make items group. I see two ways to do this:
> * Items would be grouped in code by adding "item count" property to
> class. This would be very convenient way but would need adding some
> spreaded code. One item object, which can represent many items, is bound
> to one letter.
> * They will be grouped only in players eyes. Program scans the list of
> items to count how many of them are with the same properties and then
> display list. This way is slow, but it will probably need only one big
> algoritm. One letter is bound to one item too, but if this item is
> dropped/changed/destroyed the letter must be bound to another item.

I would suggest that you have an ItemCollection class (assuming OOP, of
course) which is itself an item. For example, the player picks up an
apple, which is an Item instance. Then they pick up a second apple, and
you instantiate an ItemCollection, put the two apples into it and put it
in the inventory slot in place of the first apple. The inventory only
needs to know how to deal with Items and the ItemCollection can
encapsulate the methods for selecting one, some or all of the Items it
represents. The ItemCollection could even hold Items of different types,
if you want - a bag could be a subclass/specialized version of an
ItemCollection.

Of course, if you're not using OOP, this is of little use... just my two
cents.

Andy

 

[Guest]

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

Dnia Fri, 27 May 2005 11:15:12 +0100,
Andy Driver napisal(a):

> On Thu, 26 May 2005 22:54:24 +0200, Milesss wrote:

> I would suggest that you have an ItemCollection class (assuming OOP, of
> course) which is itself an item. For example, the player picks up an
> apple, which is an Item instance. Then they pick up a second apple, and
> you instantiate an ItemCollection, put the two apples into it and put it
> in the inventory slot in place of the first apple. The inventory only
> needs to know how to deal with Items and the ItemCollection can
> encapsulate the methods for selecting one, some or all of the Items it
> represents. The ItemCollection could even hold Items of different types,
> if you want - a bag could be a subclass/specialized version of an
> ItemCollection.
> Of course, if you're not using OOP, this is of little use... just my two
> cents.

Actually it's a pretty good approach, even without OOP. I used it in my
first (never finished) roguelike project, YARG, written in Turbo Pascal.

Another benefit of this approach is not caring for multiple items on floor
sqare -- you just put a single item there -- an ItemCollection. You can
assign it looks of the item that was recently added (and thus is 'at the
top') or just use different representation for piles of items, like some
Angband variants did.

You also use the same dialogue for accessing containers and picking
multiple items up.

--
Radomir @**@_ Bee! The quest for the Real World:
`The Sheep' ('') 3 Try #2: goto -1
Dopieralski .vvVvVVVVVvVVVvv.

 

[Guest]

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

The Sheep wrote:
> Actually it's a pretty good approach, even without OOP. I used it in my
> first (never finished) roguelike project, YARG, written in Turbo Pascal.

It's still OOP, even without using an OO language or any variation of
the noun "class" appearing in your programming code.

--
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."