[Xagog]

#gamedev
Głowię się nad pewną rzeczą. Chcę zrobić inventory do gry. Rozumiem i wiem jak zrobić takie całkiem proste, gdzie Inventory składa się z obiektów typu ContainerSlot, który ma dwa pola:
- itemID - przechowuje informację jaki przedmiot znajduje się w slocie, to może być int lub string
- count - liczba wyrażająca ilość danego itema w danym slocie

Udało mi się sklecić takie oparte na powyższym schemacie i wygląda to jak na załączonym screenshocie.

A teraz co chciałbym zrobić. Chcę, żeby żywność w grze psuła się. Powiedzmy, że np. Item typu 'Sausage' zepsuje się po 3 dniach czasu gry więc chyba trzeba by w obiektach typu Item składować datę jego stworzenia i potem, np. po otwarciu kontenera, przelecieć w pętli wszystkie Itemy mogące się zepsuć w tym kontenerze, porównać czas i ewentualnie usunąć 'Sausage' i zastąpić Itemem typu 'SpoiledSausage', jeśli czas przydatności do spożycia minął.
Na mój laicki rozum takie podejście wymaga dosłownego składowania obiektów typu Item w slotach kontenerów(mogłyby być listami), ale z drugiej strony wydaje mi się to trochę bez sensu, bo tych itemów w grze może być olbrzymia ilość, a jeszcze gracz ma craftować dodatkowe no i trzeba to też jakoś zapisać do pliku. Nie mam pojęcia jak do tego podejść, nie wiem też jak to jest zrobione w innych grach posiadających to o czym napisałem. A w ogóle mam nadzieję, że opisałem problem w sposób zrozumiały.

[2phonepiotrus]

@Xagog Nie jestem into skrypterem ale nie da się tego zrobić na zasadzie przechowania informacji jako zmiennej, która automatycznie dodawała by rosła +1 po upłynięciu dnia i psuła się gdy osiągnie np 3?

[Xagog]

@2phonepiotrus: Bardziej chodzi mi o to, czy podejście typu "każdy mogący się zepsuć item to osobny obiekt" (z drugiej strony nie wiem czy to się w ogóle da zrobić inaczej) jest dobre, bo aktualizacja stanu tych obiektów to najmniejszy problem. Po prostu będzie ich naprawdę olbrzymia ilość w takim wypadku.

[zielonymirek]

@Xagog: Składuj itemy jako osobne obiekty. Nie przejmował bym się zbytnio, że będziesz musiał je potem przejrzeć w pętli, takie operacje nie powinny mieć dużego wpływu na wydajność. Dodatkowo itemy typu Sausage mogły by wtedy dziedziczyć z klasy bazowej przedmiotu jako np. PerishableItem z polami określającymi czas przydatności. Nie ma co utrudniać sobie życia. ( ͡° ͜ʖ ͡°)

[t.....o]

@Xagog przechowuje 12k obiektow o 8 zmiennych w apce mobilnej :) 0 lagow, save waży pare mb

[sierzchula]

@Xagog: ja bym w ogole trzymal wszystkie przedmioty jako obiekty, dzieki temu bedziesz mogl nadawac im unikalne cechy, jak np spoiltime. Wlasciwosci "stackable, amount, maxamount" tez moga byc przydatne ( ͡° ͜ʖ ͡°) a bym sobie pokodzil ( ͡° ͜ʖ ͡°)

[SirSajko]

@Xagog: z całą pewnością możesz się nie przejmować, robię takie rzeczy podobnie. Wyobraź sobie alternatywę, obok item & count masz jeszcze array/listę gdzie każde pole to czas zepsucia się kiełbachy, i tak musiałbyś robić pętelkę.

[H.....r]

@Xagog: Ja bym to zrobił na podstawie czasu od wytworzenia który byłby gdzieś zapisany. I przy wczytywaniu EQ odświeżał to.

[Colos]

@Xagog za wcześnie się przejmujesz optymalizacją

[Xagog]

@Colos: Pewnie tak, po prostu brak doświadczenia i wiedzy w dalszym ciągu.

[riizzlaa]

@Xagog w czym to robisz?

[Xagog]

@riizzlaa: To akurat w javie, dłubię przy tym od kilku miesięcy. W międzyczasie zdążyłem poznać trochę libgdx, więc planuję tam kontynuować. Tylko najpierw obczaję box2d lights, bo wtedy będę mógł cykl dnia i nocy wprowadzić.

[Colos]

@Xagog: Jeżeli okaże się, że ilość przedmiotów które będą traciły swoją ważność przekroczy jakąś wydajnościową barierę, to wtedy podzielisz sobie je na specjalną listę.

Możesz nawet zrobić strukturę danych która to będzie optymalizowała i kiedyśtam ją wepniesz zamiast Twojej normalnej listy.

Możesz na przykład podejść do tego tak, że ta struktura pod kapturem będzie miała osobne listy do przetrzymywania przedmiotów które kończą się coraz później

lista przedmiotów kończących się w ciągu

[ojel]

@Xagog: Można to rozwiązać na masę sposobów, chyba jednym z najgorszych z nich byłoby dziedziczenie po klasie bazowej "PsującySięItem" - imho nie ma nic gorszego niż wciskanie dziedziczenia żeby obsłużyć jedną mechanikę, zwłaszcza jeśli przedmioty mają się psuć w różnym tempie dając inny rezultat. Moje rozwiązanie też pewnie nie jest idealne, ale to pierwsze co mi przyszło do głowy:

Stwórz sobie interfejs, np. IPerishableItem, który będzie zawierał np.:
- int z