Salut tuturor!
Aceasta este o discuție pentru a vedea ce moduri pot gândi alții în jurul acestei probleme.

realizarea

Vreau să fac un inventar al mai multor articole care au o greutate totală
Obiectele echipate afectează statisticile (de exemplu, armele cresc DAM etc.)
De asemenea, vreau opțiunea de a arunca articolele menționate și de a le folosi atunci când este nevoie (să fac tabără noaptea etc.)

Unele articole sunt ușoare.
Dacă aveți rola de pat, se va activa butonul „doar dormiți aici” care avansează ceasul 8 ore, declanșează evenimentul „timpul trecut de 24” etc.

Mă lupt puțin cu cum să am personajul care poartă 5 poțiuni de sănătate, fiecare cântărind 1.

Probabil că sunt prea ambițios, dar nu pot fi singurul care încearcă să-mi dea capul în jurul acestui lucru!

(Folosind trestia de zahăr în Twine 1.4.2, dar sunt conținut pentru a utiliza orice alt format de construcție)

De asemenea, pentru oricine dorește doar un sistem de inventar, am descoperit acest lucru: https://strugglingwithtwine.blogspot.co.uk/2014/03/handling-inventory.html?showComment=1483911375627#c3406710617839643496 Înțeleg că este nevoie de puțină încălțăminte, dar cred că ar putea funcționa. dar nu va face ceea ce vreau aici.

Comentarii

Am creat unul pentru harlowe (sfoară 2.x), deci presupunând că doriți să refaceți toată munca noastră și să învățați un nou format.

mai întâi vreau să știu ce vrei să realizezi, pentru că al meu este poate mai complex decât ceea ce ai nevoie

vrei un sistem de magazin (care, de altfel, va dura mult timp)

ce tipuri de articole doriți

există o limită a inventarului sau este o gaură neagră infinită de obiecte

ce statistici vrei, ce statistici ai în joc

este un sistem de inventar cu adevărat util situației dvs., adică puteți renunța la echipament sau este doar înlocuit automat

dacă echipamentul este doar înlocuit, tot ce aveți nevoie este o hartă de date

indiferent de motivul pentru care doriți să aruncați echipamentul sau să scoateți echipamentul din pradă, aveți nevoie de un sistem de inventar

se bazează pe noroc de pradă sau este un element specific

stiva de unelte, dacă da, cât de mult stivă fiecare articol

Nu mă pot abține dacă ești prea al naibii de vag

[EDIT] Nu pot folosi sfoara 2 pentru că nu văd nimic pe ea.
Sunt daltonic și orice pe un fundal albastru este imposibil de văzut
Am umplut asta.

Fără magazin. Aceasta va fi bazată numai pe pradă
Articolele sunt în patru categorii: Armă. Armură. Alimente. Apă. (și monede, dar vor fi suficient de ușor de urmărit cu o variabilă +1)
Va exista o limită. Pentru a evita ca jocul să devină prea ușor. Fiecare articol va fi echilibrat pentru a se potrivi cu biomul în care va fi găsit.
Statisticile actuale sunt: ​​Forță, Agilitate, Stealth, Inteligență, Ingeniozitate, Rezistență, Noroc, Transport, Daune, S-Daune, Apărare, S-Apărare, Critice, Mâini.
Un sistem de inventar ar fi foarte util pentru obiectele transportate, dar armele și armurile pot fi înlocuite, deoarece nu este nevoie să vă irosiți spațiul de buzunar pe el.
Fură este bazată pe noroc
Uneltele se vor stivui cât de mult permite greutatea (pentru discuție). Nu doriți să purtați altceva decât poțiuni vindecătoare și echipamentul dvs., sigur.

Nu am vrut să arunc toate detaliile jocului meu atunci când nu știu ce informații sunt relevante. Nu am menționat nicăieri un magazin și, dacă nu mi se cere, nici măcar nu m-aș fi gândit la asta.

sfaturi generale (deoarece nu există nici o harlowe în sfoara 1.x doresc să pot ajuta efectiv)

1. Reduceți cantitatea de statistici este un pic prea mult Nu am idee ce mâini ar putea fi, nici nu știu diferența dintre forță/daune, inteligență/ingeniozitate, rezistență/apărare, ca jucător, nu aș vrea un joc care să fie privire prea complicată la jocurile populare cu sandbox (presupun că faci un joc cu sandbox) ca Nu muri de foame sau Minecraft au aproximativ 3-4 statistici, chiar și cei mai mulți mmorpgs/rpgs nu au atât de mult

2. poate că vă puteți actualiza/încânta echipamentul pentru a obține statistici specifice pe care le căutați

noroc este regretabil că nu am putut fi de ajutor

Unele dintre acestea ar putea fi cel mai simplu: elementul dvs. de bază a fost un teanc, nu un singur articol. Deci, o poțiune vindecătoare ar fi un teanc de 1 poțiune vindecătoare. Ar trebui să stocați atributele elementelor individuale în baza stivei și să utilizați un widget (presupunând că utilizați Sugarcane 2 cu 1.4.2) pentru a recalcula atributele totale ale stivei:

mișcare_vindecare: < tag: 'Healing Potion',
unic: [1, 0, 0, 0, 0, 0]
număr: 3,
total: [3, 0, 0, 0, 0, 0]>

Matricea totală este pur și simplu matricea unică înmulțită cu numărul. Pentru a vă completa inventarul, trebuie doar să adăugați toate matricile totale individuale împreună.

Eticheta este utilizată pentru a localiza obiecte atunci când se mută unele dintre ele într-o locație nouă. Dacă puteți găsi un teanc de obiecte în noua locație, pur și simplu ajustați numărul și retotați fiecare teanc. Dacă un teanc se termină cu 0, distrugeți-l (dar urmăriți clona vs indicatorul - setați $ a la $ b pur și simplu face $ un punct la $ b, trebuie să setați $ a pentru a clona ($ b) pentru a obține un nou obiect care este independent de obiectul $ b.) Dacă nu puteți găsi o stivă existentă în noua destinație, va trebui să creați una nouă (adică prima dată când ridicați o poțiune de vindecare).

S-ar putea să puteți salva niște memorie cu o valoare de „tip” care indică o intrare dintr-o matrice unică master, dar care face lucrurile puțin mai complicate.

Sunt încă nou la toate acestea, am folosit Harlowe și SugarCube (concentrându-mă mai mult pe SC, deoarece pare mai puternic), dar aș vrea să îmi arunc opinia. Voi spune asta, fără să intru în funcțiile javascript și/sau să nu folosesc sistemul widget al SugarCube, vei avea timp să păstrezi lucrurile îngrijite, curate și utilizabile. În prezent, caut în moduri mai bune de utilizare a hărților de date sau a oricărei structuri cheie-valoare, astfel încât să pot crea obiecte complexe (cum ar fi elementele) din mers. Partea dificilă este crearea funcțiilor care se joacă frumos cu ele și scriptul Twine. Mi-am petrecut 95% din timp doar cercetând cum să funcționeze funcțiile Javascript personalizate, iar JS a fost prima mea limbă.

Când m-am jucat pentru prima dată cu Harlowe, am folosit o mulțime de variabile de pavilion (practic doar booleeni) pentru a acționa ca sistem de inventar și articol, și a fost un iad. Cu siguranță vă sugerez să analizați compartimentarea codului dvs. cât mai mult posibil.

În cele din urmă, însă, nu cred că este înțelept să încerci ceva la fel de complex ca un inventar în Harlowe. Nu-mi pasă în mod deosebit de formatul lui SugarCube și îmi place evidențierea culorilor pe Harlowe, dar pur și simplu nu are aceeași putere fundamentală ca SugarCube.

Sper că asta ajută puțin.

Sunt în aceeași bătălie. Sistemul meu de inventar se bazează pe greutatea articolului, numărul de articole și „fantele corpului”, cum ar fi mâinile, pieptul etc. Am făcut să funcționeze, inclusiv efectul drop/equip și statistic, dar inventarul frânează după o încărcare de salvare.

Ar fi minunat să vedem o soluție sau un cadru „pro” în legătură cu aceasta.

Se pare că ți-ai tăiat munca. De asemenea, sunt în proces de implementare a unui inventar. Acesta acceptă mai multe elemente care pot fi utilizate în același timp. Obiectele pot fi afectate de personaj (când lovești un inamic, sângele va rămâne pe sabie, de exemplu) și invers când obiectul este folosit (de exemplu: aruncarea unei vrăji dintr-o baghetă magică care are o utilizare limitată ). Obiectele pot afecta alte obiecte (de exemplu: bagheta magică poate fi reîncărcată folosind o piatră magică). Dacă aveți două baghete, atunci veți începe să utilizați una dintre baghete înainte de a trece la cealaltă care este încă încărcată. În același mod, dacă una dintre săbiile tale are sânge de dragon pe ea, va fi tratată ca o sabie fermecată și nu se va „aduna” cu celelalte săbii de același fel (altfel toate celelalte săbii ar fi afectate de sânge ).

Dezvolt acest sistem de inventar de săptămâni în urmă și încep doar să-l testez recent. Trebuie să spun că faza de proiectare și că prototiparea a fost un pic cam îndoială. Acum, mă gândesc la automatizarea unor teste pentru a ține toate mecanicile și sistemul de inventar sub control (deoarece este internă este destul de complicată și surprinzător de greu de testat).

Mi-aș dori să vin cu o soluție mai ușoară

Vă recomandăm să încercați mai întâi să proiectați sistemul de inventar pe pix și hârtie. Gândește-te la TOATE lucrurile pe care le pot face și pot afecta obiectele tale. Gândiți-vă la posibilitatea ca alte NPC-uri să vă manipuleze inventarul și invers. Există atât de multe lucruri care trebuie luate în considerare înainte de a începe să implementați un sistem de inventar pentru un joc. Abia recent am învățat acest lucru în mod greu

Folosind Twine 2.1.3 și Sugarcube 2.18.0

Tocmai am început să mă amestec atât cu Twine, cât și cu codarea în general, dar dacă nu îmi lipsește ceva, acest lucru nu pare prea complicat de făcut.

Tocmai am creat un sistem de inventar și un mic magazin pentru a-l încerca. Mai întâi ne-am configurat articolele și câteva alte lucruri în StoryInit:


Apoi creăm un widget pentru a gestiona cu ușurință comportamentul jocurilor atunci când jucătorul transportă prea mult:

Apoi am configurat pasajul „magazin” pentru a testa sistemul nostru de inventar:


Evident, totul este încă foarte brut și s-ar putea să dorim să îi adăugăm mult mai multe funcții, dar adăugarea lucrurilor nu va necesita mult efort de aici înainte și cred că acest lucru arată cum atât un sistem de inventar, cât și un magazin sistemul poate fi configurat foarte rapid și fără efort.

Este un început bun, dar codul poate deveni rapid complex și foarte personalizat.

de exemplu.
1. Permiteți jucătorului să cumpere articole pe care este posibil să nu le poată transporta.

2. Ce se întâmplă dacă există mai mult decât un singur magazin sau diferite tipuri de magazine.

3. Ce se întâmplă dacă un articol poate fi folosit de mai multe ori.
de exemplu, o poțiune cu mai mult de o singură doză, care este diferită de mai multe poțiuni.

4. Ce se întâmplă dacă există containere care pot conține alte articole.
de exemplu. plasarea unui sac/pungă mică care conține articole în rucsac.

5. Ce se întâmplă dacă elementele se pot degrada și, în cele din urmă, pot deveni inutilizabile.

6. Ce se întâmplă dacă elementele pot fi combinate împreună pentru a crea alte articole și cum urmăriți ce articole pot fi combinate împreună.

Practic, nu există un sistem de inventar „standard”, întrucât lista potențială de caracteristici necesită modificări de la joc la joc.

NOTĂ: Deoarece „valorile” fiecăruia dintre articolele dvs. din implementare nu se modifică, ar fi mai bine să le stocați obiecte în cadrul înființat obiect în loc de variabile din poveste, deși matricile legate de conținutul inventarului vor trebui să rămână variabile din poveste.

Motivul pentru stocarea articolelor în configurare este că starea tuturor variabilelor de poveste cunoscute este „clonată” la fiecare traversare a pasajului, stările originale sunt asociate cu trecerea lăsată și stocată în Sistemul istoric, iar „copierea” este pus la dispoziția următorului pasaj. Acest proces poate consuma rapid memoria Dacă aveți multe valori variabile ale poveștii neschimbate în poveste, cum ar fi elementele posibile din exemplul dvs.

NOTĂ: Deoarece „valorile” fiecăruia dintre articolele dvs. din implementare nu se modifică, ar fi mai bine să le stocați obiecte în cadrul înființat obiect în loc de variabile din poveste, deși matricile legate de conținutul inventarului vor trebui să rămână variabile din poveste.

Motivul pentru stocarea articolelor în configurare este că starea tuturor variabilelor de poveste cunoscute este „clonată” la fiecare traversare a pasajului, stările originale sunt asociate cu trecerea lăsată și stocată în Sistemul istoric, iar „copierea” este pus la dispoziția următorului pasaj. Acest proces poate consuma rapid memoria Dacă aveți multe valori variabile ale poveștii neschimbate în poveste, cum ar fi elementele posibile din exemplul dvs.

Oh, mulțumesc - citisem undeva că variabilele care nu se schimbă ar trebui stocate în altă parte, dar nu era întotdeauna clar unde și de ce. Acest lucru clarifică lucrurile

Așa cum am spus, majoritatea completărilor se pot face rapid și ușor cu acest tip de configurare. Ceea ce va fi complicat sunt problemele numărul 4 și 5 pe care le menționați. Inițial am vrut să fac sistemul de inventar să funcționeze prin clonarea unui model de obiecte, apoi adăugarea clonei la matricele de inventar individuale - nu am început niciodată să experimentez cu clona (), de vreme ce nu sunt sigur cum să fac clone și mă tem de creșterea mereu o grămadă de clone ar putea avea în cele din urmă o problemă pentru memorie.
Există o modalitate de a crea și de a deschide clone?

Majoritatea celorlalte probleme pe care le-ați menționat pot fi rezolvate destul de repede. Tastez rapid soluțiile posibile, fără a încerca să le rulez - îmi pare rău dacă există greșeli sau greșeli de tipare în cod:

1. Împiedicați jucătorul să cumpere peste greutatea de transport

Jucătorul poate cumpăra în prezent câte obiecte dorește, dar dacă nu poate suporta greutatea, nu se va putea muta într-un alt pasaj, datorită widgetului nostru. Dacă am vrea să-i împiedicăm să le cumpere în primul rând, tot ce trebuie să facem este să modificăm puțin magazinul:

Putem adăuga deja cât mai multe magazine cu stocuri diferite la joc folosind configurarea curentă. Apoi putem adăuga cu ușurință informații suplimentare în magazine pentru a specifica ce fel de articole pot fi cumpărate și vândute acolo.

3. Elemente de utilizare multiplă

Dacă vrem ca o „Poțiune Vindecătoare” să dureze de patru ori, o putem reduce doar la utilizare cu 0,25.

Apoi îi lăsăm să vândă poțiuni nefolosite:


4. Elemente de depozitare:

Un singur articol de stocare poate fi creat cu ușurință prin adăugarea unui tablou unui obiect:
Deoarece avem doar un singur obiect de rucsac, totuși, vom întâmpina probleme dacă personajul nostru are două rucsaci cu mai multe inventare diferite. Probabil că am putea găsi o soluție prin crearea unui tablou pentru a stoca toate aceste informații: [1, 0, 2], [3, 4, 1]. ] - dar recunosc că acest lucru va fi enervant să se înființeze.


5. Arme degradante

La fel ca containerele de depozitare de mai jos, aceasta nu ar fi o problemă, dacă am avea o singură instanță a obiectului în cauză.

Dar de îndată ce avem mai multe instanțe ale aceluiași obiect care ar trebui să se afle în stări diferite de a fi uzate, ar trebui să creăm o altă matrice, la fel ca mai sus.


6. Ceva cum ar fi combinarea articolelor pentru a forma articole noi nu ar modifica în niciun fel sistemul de inventar propus. Ne putem descurca cu ceva de genul unui widget de artizanat, care elimină articolele folosite, apoi adaugă unul din articolele create în inventarul nostru. Va fi nevoie de multă muncă, în funcție de câte lucruri am dori să fim artizanali, dar aceasta este doar natura unui sistem de artizanat și nu va fi complicat să-l construim.