Coding > FPC Valkyrie

Inventory

(1/2) > >>

Igor Savin:
(OK, this might better suit the "DiabloRL" forum, but I'll just pretend "Valkyrie" one is created for programming stuff... and it's pretty empty here anyway, so it isn't that much of littering)

Looks like I'm getting spoiled with all the goodies I found in Valkyrie, and ideology of "make games not engines" overcomes me more and more... There's lots of things to, *ahem*, "borrow" from BerserkRL (I guess the appropriate credit for everything I make would be "All the hard stuff: K. K. Anubis; All the fun stuff: *me*"), but there's one important thing missing: yep, you guessed right. Inventory&equipment. Hell, I feel confident enough with TNodes already to implement class-using inventory, but I don't know if it'd be worth reinventing the wheel (and it would be inferior one anyway)... The system you coded for DiabloRL works fine for me, and you mentioned that it's *possible* you will open-source it one day.

So yeah, generally it's a plea to release sources sooner rather than later; I'll make a good use of them *foxish grin*

Is everything *that* unoptimized, anyway?

Kornel Kisielewicz:
Well, the DiabloRL inventory system IS complicated and unoptimized, mainly because of:
1) the "funny" way it presents equipment
2) the "slots" system it uses (object "volume")

I'll write something on inventories ASAP, stay tuned.

Before that you need to make some decisions tough:
1) fixed inv size (Angband, DoomRL) or open (DiabloRL/ADoM)
2) monster inventories?
3) equipment handling?
4) containers?

Testing code highliting (will be usefull in the future)...


--- Code: (delphi) ---procedure TPlayer.PrepareItemList(const ItemContainer : TGameObject;
                                  const Filter : TFlags);
var Scan  : TGameObject;
    Count : Word;
    Count2: Word;
    Skip  : Boolean;
begin
  Count := 0;
  Scan := TGameObject(ItemContainer.Child);
  while Scan <> nil do
  begin
    if (Scan.ClassType = TItem) then
      if (Filter = AllFlags) or (Filter*Scan.Flags <> []) then
      begin
        Skip := False;
        if ItemContainer = Self then
          for Count2 := 0 to EqSize-1 do
            if Eq[Count2] = Scan then begin Skip := True; break; end;
        if not Skip then
        begin
          ItemList[Count] := TItem(Scan);
          Inc(Count);
        end;
      end;
    Scan := TGameObject(Scan.Next);
  end;
  ItemList[Count] := nil;
  ItemListSize := Count;
end;

--- End code ---

Igor Savin:
\1) fixed inv size (Angband, DoomRL) or open (DiabloRL/ADoM)\

Open.

\2) monster inventories?\

Yep. (since TPlayer is TBeing too, one can simply move all inventory-related functions to the TBeing, if inventory is implemented for TPlyaer only, right? And write appropriate interface for TPlayer and AI for TBeing)

\3) equipment handling?\

What are possible options here? I think ADoM's system is rather good (yet I don't see how much it is different from GearHead... or DiabloRL in that matter))...

(BTW, DiabloRL quickslots ARE something that really should be reuused somewhere else - too convenient)


\4) containers?\

What's with them?

As I see them, they should be able to
1) Hold different items (>1 item stack)
2) Have locks&traps (unrelated to inventory)
3) Possess limited capacity.
4) Both give and take items.

Is there something I missed?


Why won't you create class Inventory? I think it would have sense to define "PrepareItemList" for it, and then reuse it for everything, starting with chests and monsters, and ending with shops and PC...
Or is ItemContainer actually something like that? (since ItemContainer might be "= self")

Kornel Kisielewicz:

--- Quote from: Igor Savin on December 02, 2006, 05:51 ---\3) equipment handling?\

What are possible options here? I think ADoM's system is rather good (yet I don't see how much it is different from GearHead... or DiabloRL in that matter))...

--- End quote ---

There's a difference in the internals between the DiabloRL/DoomRL way and for example Carceri. In Carceri equipment items are kept as children of TBeing, and just flagged as Equipment and added to a static array of Equipment pointers. In DiabloRL/DoomRL they are moved to that separate array and are no longer a Child of TBeing. Both methods have their advantages/disadvantages. The Carceri way is more proper in the OO sense, and allows easier handling of all items at the same time. But the DRL way is easier to implement, handle maintain.


--- Quote from: Igor Savin on December 02, 2006, 05:51 ---\4) containers?\

What's with them?

--- End quote ---
If you want items within items this is going to be a pain to code and maintain ;-)



--- Quote from: Igor Savin on December 02, 2006, 05:51 ---Why won't you create class Inventory? I think it would have sense to define "PrepareItemList" for it, and then reuse it for everything, starting with chests and monsters, and ending with shops and PC...
Or is ItemContainer actually something like that? (since ItemContainer might be "= self")

--- End quote ---
No, this function prepares a global item list for any container given (it may be TPlayer if browsing own inventory, or TBeing if stealing... etc). As for a TItemContainer class, I used that approach for GenRogue and it prooved to be messy unfortunately :(. The point was that we had to keep a initialized TItemContainer for every map cell... anyway... do you want multiple items on a single map square? If so, you will need to do a TItemContainer class anyway...

Igor Savin:
Hmmm... I guess that DoomRL approach will be more appropriate for now.


\If you want items within items this is going to be a pain to code and maintain ;-)\

It's pain merely to think about it ;). Strict "no".

\do you want multiple items on a single map square? If so, you will need to do a TItemContainer class anyway...\

It was nice in ADoM... yet I don't see it as a "must". For the sake of organization (and economy of memory) I'll stick to "one stack (ex. arrows) per tile" approach.
It worked for DoomRL.

Navigation

[0] Message Index

[#] Next page