Nota: non voglio aiuto per la codifica qui, sono attivo Programmersper un motivo. Voglio migliorare le mie capacità di pianificazione / scrittura del programma non (solo) la mia comprensione di Java .

Sto cercando di capire come realizzare un albero con un sistema di categorie arbitrario, basato sulle abilità elencate per questo gioco LARP qui . Il mio precedente tentativo aveva un effetto positivo sul fatto che un'abilità fosse anche una categoria. Cercare di codificarlo era disordinato. Disegnando il mio albero ho notato che solo le mie "foglie" erano abilità e avevo etichettato gli altri come categorie.

Quello che sto cercando è un modo per creare un albero che tenti di separare Modello e Vista e consentire l'aggiunta di un tipo arbitrario di nodo figlio (con un modo separato di essere modificato / reso) a un genitore arbitrario.

NB Tutto qui viene acquistato come un'abilità, anche dove sembra una proprietà. Gli utenti finali vedranno questo come capacità di acquisto (cosa che fanno su bancomat), quindi dovrebbero essere presentate come tali, tutte nella stessa pagina.

Spiegazione dell'albero: L'albero è "nato" con una serie di categorie di livello più elevato ( armi, fisica e mentale, medicina e altro). Da questo l'utente deve poter aggiungere un'abilità. Alla fine, ad esempio, vogliono aggiungere l' abilità "Specializzazione spada a una mano" ( non un oggetto). Per fare ciò, idealmente fai clic su 'aggiungi' con Weaponsselezionato e quindi seleziona One-handedda un nodo della casella combinata che appare su quel figlio, quindi fai clic di nuovo su Aggiungi e inserisci un nome in un campo di testo su quel nodo figlio che appare. Quindi fare di nuovo clic su Aggiungi per aggiungere / specificare un 'livello' o 'livello' per quella foglia; prima competenza, poi specializzazione (ad esempio).

Naturalmente, se vuoi acquistare un'abilità diversa, è un percorso completamente diverso dalla foglia. Potresti non aver bisogno di una casella combinata allo stesso livello in basso dell'albero come hai fatto con l'esempio dell'arma, e anche di avere qualche altra logica dietro di esso. Questo è ciò di cui ho difficoltà a districarmi e tanto meno a programmare; come creare un insieme di classi e non specificare in quale ordine collegarli insieme, ma comunque adattarli tutti.

Qual è un buon sistema per descrivere questo tipo di albero nel codice? Tutti gli altri esempi di JTree che ho visto hanno uno schema prevedibile , e il mio no . Non voglio codificare tutto questo in "valori letterali", con lunghi elenchi di quale tipo (casella combinata, campo di testo ecc.) Del nodo figlio dovrebbe essere consentito su quale genitore. Dovrei usare classi astratte? Interfacce?

Come posso rendere estensibile questo tipo di cluster di oggetti quando aggiungo altre abilità non elencate sopra che si comportano diversamente?

Se c'è non è un buon sistema per l'uso, c'è un processo buona per lavorare fuori come fare questo genere di cose?

Gli ingranaggi nella mia testa stanno girando:

Ho sempre bisogno di:

• Controlla il genitore
• Fornire opzioni in base al genitore

Sto cominciando a pensare a causa di questa comunanza ho bisogno di una sorta di skillclasse astratta / interfaccia che definisce / delinea metodi comuni per abilità e categoria. Posso (si spera) mettere regole e opzioni in un database e leggere da lì. La domanda è ora penso, tra un metodo astratto o di interfaccia e come implementarlo.

Semplice esempio JTree mutabile

Codice (rispettato e testato con Java 7 per creare l'immagine sopra):

import java.awt.*;
import javax.swing.*;
import javax.swing.tree.*;

public class SimpleTree extends JFrame {
    public static void main(String[] args) {
        new SimpleTree();
    }

    public SimpleTree() {
        super("Mutable Varied JTree");
        Container content = getContentPane();
        N root = new N("Root");

        N weapons = new N("Weapons").add(
            new N("One-handed").add(
                new N("Sword").add("Proficiency", "Specialization"), 
                new N("Mace").add("Proficiency")),
            new N("Bow").add("Proficiency"));
        root.add(weapons);

        N phys = new N("Physical & Mental").add(
            new N("Life"),
            new N("Strength").add(
                "Double", "Triple", "Quadruple"));

        root.add(phys);
        N med = new N("Medical");
        med.add(new N("Bind Wounds"));
        med.add(new N("Set Broken Bones"));
        root.add(med);

        JTree tree = new JTree(root);
        content.add(new JScrollPane(tree), BorderLayout.CENTER);
        setSize(275, 300);
        setVisible(true);
    }

    private class N extends DefaultMutableTreeNode {
        public N(String s) { super(s); }
        public N add(String... strs) {
            for (String s : strs) {
                super.add(new N(s));
            }
            return this;
        }
        public N add(N... ns) {
            for (N n : ns) {
                super.add(n);
            }
            return this;
        }
    }
}

Un ringraziamento speciale a questo tutorial di JTree

Aggiornamento: discussione di possibili soluzioni

C'è un tutorial su come creare un albero dinamico , usando i pulsanti nella parte inferiore del riquadro per aggiungere / rimuovere / cancellare i nodi.

Per combo-box e simili, vuoi prendere oggetti della classe swing appropriata e farli diventare qualcosa come un JComboBox che implementa java.swing.tree.MutableTreeNode. Java Swing Tutorial ha un elenco di controlli .

È ancora necessario creare un elemento dell'interfaccia utente per consentire alle persone di scegliere il tipo di nodo che desiderano aggiungere e modificare il nodo. Se aggiungono una casella combinata, dovranno essere in grado di definire le scelte che la casella renderà disponibili.

È necessario un modello di dati sottostante per salvare i dati. È possibile utilizzare lo schema di serializzazione predefinito incorporato in tutti gli oggetti Java, ma è solo per la prototipazione: si romperà se si modifica il codice del programma. Dovrai utilizzare un database con JDBC o JPA o dovrai scrivere le tue routine di serializzazione (o utilizzare una libreria che gestisce la serializzazione per te) usando qualcosa come JSON o XML come formato di archiviazione.

Aggiornamento: soluzione proposta con panoramica del progetto

La soluzione più semplice potrebbe essere quella di dimenticare i database e trovare prima l'espressione XML dei dati, quindi modificare il file XML e visualizzare semplicemente i risultati come JTree senza speciali caselle combinate o altro. Penso che questo sia ciò che Chibueze Opata stava suggerendo con la sua risposta. Una rappresentazione XML parziale di questo albero potrebbe essere simile alla seguente:

<folder name="Physical &amp; Mental">
    <int name="Life">12</int>
    <drop-down name="Strength">
        <option name="Single" />
        <option name="Double" />
        <option name="Triple" />
        <option name="Quadruple" />
    </drop-down>
</folder>
<folder name="Medical">
    <text name="Bind Wounds" />
    <text name="Set Broken Bones" />
</folder>

Ecco alcune potenziali pietre miliari per te:

• Crea un formato dati XML o JSON, quindi scrivi un programma che legge un file di quel formato e lo visualizza come un JTree senza combo-box, solo cartelle e file.
• Aggiungi i controlli di oscillazione al display JTree
• Espandi il tuo programma per scrivere lo stesso file
• Creare un'interfaccia utente in modo che l'utente possa aggiungere e modificare nodi utilizzando la GUI

Assicurati di salvare un backup del tuo programma ogni volta che funziona alla fine di ogni pietra miliare. Un sistema di controllo del codice sorgente installato su un'altra macchina è l'ideale per questo. Puoi usare github, o sourceforge o qualche altro controllo del codice sorgente pubblico se non ti dispiace condividere il tuo codice e non vuoi impostare un server con controllo del codice sorgente.

Ognuna di queste soluzioni richiede molto lavoro e decisamente più grande di un progetto per principianti. Significa che passerai molto più tempo a imparare Java Swing e XML o JSON che a giocare con il tuo LARP, motivo per cui ho esplorato per la prima volta le opzioni per accontentarti di strumenti esistenti. Ma il modo migliore per imparare qualcosa è il modo in cui sei più motivato ad imparare. Quindi questo potrebbe essere un progetto perfetto per te.

Spero che aiuti.

Non credo che JTree sia la rappresentazione giusta per il problema che stai cercando di risolvere. Ho guardato il tuo sito web e vedo elenchi di cose. Questo è un ottimo inizio, ma penso che ci sia un design di dati sottostante che potresti avere, ma non vedo.

Vita e Forza mi sembrano attributi del personaggio. Double, Triple e Quadruple sembrano valori per l'attributo Strength. Poi vedo le abilità divise in Arma e Medicina. Penso alle armi come a possedimenti (che puoi acquistare, trovare o rilasciare) e presumo che l'abilità sia ciò che ti consente di essere efficace con una data arma. Ma per come la vedo io, le armi e la medicina non hanno abilità, il personaggio ha. In effetti, sospetto fortemente che il personaggio sia la figura centrale nella progettazione dei tuoi dati.

Ecco tre oggetti di dati che mi distinguono dal tuo progetto finora:

Character:
    Life (a value: e.g. 12)
    Strength (a value: e.g. double, triple, quadruple)
    Skills (list or set of weapon-skills, healing-skills)
    Possessions (list of weapons, armor and other possessions)
    WornArmor (maybe only wear one you possess at a time?)
    WieldedWeapon (one or two of your posessions)

Skill:
    Skill-Type (healing, manufacture, or weapon)
    RelevantWeapon (for this skill)

Weapon:
    IsOneHanded (boolean)
    IsBow (boolean)

Ora un personaggio può avere armi e abilità, ma per un attacco davvero buono, hanno bisogno di un'abilità specifica dell'arma che stanno usando. In ogni caso, ci sono relazioni uno-a-molti qui (un personaggio può avere molte abilità). Ma non vedo ancora alberi.

Prendi un blocco di carta e nella prima pagina metti il ​​personaggio al centro della pagina ed elenca i 5-10 oggetti più importanti del mondo di gioco attorno ad esso. Scopri quali dati sono semplicemente un attributo di un altro oggetto (come Vita e Forza sono parti inseparabili del personaggio) e quali sono le relazioni più importanti tra gli oggetti, senza pensare ad alberi o campi di testo o caselle combinate. Traccia linee tra oggetti per rappresentare le relazioni Quindi scopri quali relazioni sono 1: 1, quali sono 1: molte e quali sono molte: molte ed etichettale. Potrebbero esserci anche "has-a" e "is-a" e altri tipi di relazioni.

Puoi decidere di aver bisogno di rappresentazioni separate per una WeaponSkill vs. HealingSkill vs. ManufactureSkill. Oppure puoi decidere che sono così simili da appartenere a una tabella delle abilità (nel mio esempio sopra) con un campo che determina il tipo di abilità che è.

È un buon segno che non sei soddisfatto dei tuoi tentativi finora - significa che sei disposto a considerare molte possibilità prima di sceglierne una. Più schizzi prendi in considerazione, migliore sarà il tuo progetto finale. Alla fine, il migliore diventerà il tuo diagramma dei dati. Quando questo è abbastanza ben definito, puoi tornare a pensare a "caselle combinate" o "campi di testo", ma lascerei le decisioni dell'interfaccia utente fino alla fine.

Piuttosto che guardare JTrees, suggerirei di esaminare gli argomenti di Strutture dati, Progettazione di database e forse Data Modeling. EDIT-> O meglio ancora diagrammi di mappatura entità-relazione come suggerito da David Kaczynski! <-EDIT Se la progettazione dei dati è corretta, Java e l'interfaccia utente ne usciranno ovviamente e naturalmente. Ma se sbagli, nessuna quantità di Java-kung-fu o UI-beauty lo risolverà.

In bocca al lupo!

Mi concentrerò sul modello a oggetti.

Penso che per la flessibilità che desideri, probabilmente vuoi separare le tue classi in un livello di conoscenza (forse "definizione" è una parola migliore in questo caso) e un livello di transazione. Per "livello" intendo solo separarli logicamente nella tua testa. Il livello di conoscenza contiene la tua definizione di come strutturare l'albero e i dati in esso contenuti provengono da un game designer e il livello di dati memorizza scelte particolari per un determinato personaggio.

Il tuo livello di conoscenza sarà almeno leggermente disordinato, perché stai cercando di creare un gioco interessante piuttosto che un modello matematicamente pulito.

Cercando di organizzare ciò che hai finora, penso che tu abbia una classe SkillDefinition che abbia una proprietà Parent di tipo SkillDefinition. Hai anche sottoclassi di SkillDefinition (che possono diventare voci in una tabella DEF_SkillType nel database) per coprire alcuni casi.

"Armi", "Fisico e mentale" e "Medico" sembrano avere nient'altro che un titolo (e abilità infantili).

"One Handed", "Strength" e "Bind Wounds" sembrano avere una casella combinata associata (che significa qualcosa come una tabella DEF_SkillChoice nel database con una chiave esterna per DEF_Skill). Sword e Bow sembrano essere una stringa definita dall'utente (quindi nessuna tabella associata a livello di conoscenza, ma i dati verranno archiviati a livello di transazione).

"Life" sembra avere un numero intero associato. Potrebbe non essere in grado di condividere questa classe con caratteristiche future che utilizzano un numero intero, poiché esiste un comportamento implicito su come viene incrementato il numero intero. In ogni caso, al momento ha bisogno di una propria classe.

"Sword", "Bow", "Strength" e "Bind Wounds" sembrano avere livelli di abilità progressiva associati sotto di loro nell'albero. Nel caso di "Spada" e "Arco", questi livelli sono realmente associati alla loro abilità genitore. Penso che tu abbia bisogno di una classe ProgressiveSkillDefinition con una raccolta ordinata di valori legali (tabella DEF_SkillLevel con chiave esterna per DEF_Skill. A livello di conoscenza non è completamente chiaro quali regole stai modellando. Se "competenza" e "specializzazione" sono sempre disponibili per tutte le armi, potresti avere una tabella DEF_SkillLevel con i record "competenza" e "specializzazione" con chiavi esterne al record "Armi".

Questo copre ciò che sai a livello di conoscenza. Il livello di transazione (forse "livello di carattere" sarebbe un nome migliore?) Indica semplicemente il livello di conoscenza appropriato. Quindi, nel tuo esempio, avresti un oggetto Personaggio con un oggetto Abilità che ha una raccolta di abilità - proprio quelle che ha in realtà.

Quindi, il personaggio avrebbe un'abilità "Competenza" il cui genitore è l'abilità "spada" e il cui tipo è Skill_Level. Nel database il record TRANS_SkillDefinition ha una chiave esterna per il record di abilità transazionale "spada" e il record di livello di conoscenza DEF_SkillLevel con il nome "Competenza".

L'abilità di competenza avrebbe un oggetto genitore dell'abilità "spada", di tipo Skill_UserNamed. Nel database questo non avrebbe una chiave esterna per il livello di conoscenza, perché non c'è nulla di speciale definito per "spada" (è il nome dell'utente). Tuttavia ha anche una chiave esterna per il record transazionale principale, quindi sono disponibili ulteriori informazioni attraverso di esso.

L'oggetto abilità "spada" ha un oggetto padre di "una mano", perché l'utente ha scelto di mettere "spada" nella categoria "una mano". Questo è un oggetto di tipo SkillCategory. Nel database ha una chiave esterna per la tabella DEF_SkillChoice per il record "con una mano" e nessun parent transazionale perché tutti i dati aggiuntivi per questa abilità sono memorizzati a livello di conoscenza.

Nel costruire l'albero iniziale per un nuovo personaggio, solo il livello di conoscenza deve essere interrogato. Per popolare le scelte fatte per un personaggio è necessario il livello transazionale.

Sarà necessario il codice per tradurre il modello a oggetti in un albero e viceversa. Dovrei essere chiaro, spero, cosa devi fare: ogni tipo nel livello di conoscenza avrà un insieme associato di controlli sull'albero, che ottiene i dati appropriati per quel tipo.

In seguito potresti desiderare classi per ogni scelta nei record di SkillCategory (se "Specializzazione" ha un comportamento associato, il codice deve andare da qualche parte), ma non è ancora necessario per questo albero e questo design sarà compatibile con quello. Dovrai solo avere una fabbrica che utilizza le informazioni del livello di conoscenza per costruire l'oggetto giusto.

Dopotutto, finiamo sempre per gestire le strutture gerarchiche - che si tratti di una gerarchia di classi di un programma, o il programma stesso costruito da diversi moduli che ti collegano a un "mondo interno" (GUI, connessione DB, logica aziendale legata ai dati, ecc.) . Ma questa è filosofia, come dovrebbe funzionare nel tuo caso?

Hai nodi in questo albero, ogni elemento è una "istanza di oggetto"; mentre il loro comportamento (dove puoi metterli, l'elenco dei nodi figlio consentiti, ecc.) è comune per alcuni insiemi, come le "classi". Sì, è proprio come un codice di programma. Se conosci abbastanza la riflessione Java, puoi persino usare le classi POJO e la gerarchia di ereditarietà per costruire questo componente, con un contenitore IoC o un meccanismo di fabbrica per creare le istanze effettive. Ma penso che non lo desideri, perché si tratta di un linguaggio pesante, quindi ...

Innanzitutto, crea un oggetto "class" che descriverà il comportamento degli elementi. Contiene l'identificatore di classe, i nomi di "campo", i tipi consentiti e il conteggio degli oggetti, ecc. Esempio: la classe "radice" è "Proprietà giocatore", ha il campo "Fisico / Mentale", "Medico", "Armi". Questo tipo è "finale": in questo momento non vuoi avere diversi tipi di giocatori. Suggerimento: in seguito puoi farlo, utilizzando gli stessi strumenti per gestire "mostri non umani" ... :-)

Il campo "Medico" è

• "singleton": il giocatore non può avere più informazioni "mediche"
• il tipo figlio è fisso, qui è possibile utilizzare solo oggetti di tipo "Medico"
• richiesto: quando crei un giocatore, deve avere un campo "Medico"

Contrariamente: il membro delle armi non è richiesto, dovrebbe essere creato quando la prima arma viene aggiunta al tuo giocatore. Ciò significa: quando "modifichi" il tuo "oggetto" (ora il giocatore) e desideri consentire l'aggiunta di un nuovo oggetto, non dovresti limitare la selezione in base alle proprietà effettive dell'istanza (che ora non contiene "Armi" "), ma mostra tutti i campi della definizione della classe e crea pigramente il nuovo campo (nodo figlio) al primo utilizzo. Questo creerà un ambiente estensibile. Successivamente, puoi aggiungere il campo "Amici" con riferimenti a più giocatori ... er ... (vedi più avanti).

Seguire il processo con le "classi" effettive. Ti aiuterà a perfezionare le tue idee, come: sembra meglio separare i tipi di armi (spade, pugnali, archi, ...), maneggiare le munizioni in qualche modo (sapendo che forse il giocatore NON ha un arco ma può raccogliere frecce, ma usando alcune armi richiedono e diminuiscono le munizioni, alcune possono essere trovate, altre sono perse ...) nella classe "Armi": è più facile ispezionare e mostra anche se il tuo giocatore trasporta solo quell'oggetto o può usarlo anche ( ha le competenze). D'altra parte: sicuramente cambierai questa struttura in seguito, man mano che sviluppi il tuo gioco.

Crea un "class store" disponibile a livello globale da inizializzare all'avvio del gioco e pubblica le definizioni delle classi quando qualcuno fa riferimento al loro nome. Gli oggetti def di classe devono essere immutabili in questo caso.

Gli "oggetti" sono più semplici: possono essere derivati ​​dalla stessa classe radice che contiene un riferimento alla definizione della classe e anche l'accesso generico ai campi. Forse usa una HashMap per contenere quei figli, identificati dal nome del campo. Ricorda: alcuni di questi campi contengono un singolo oggetto, altri un insieme di oggetti. Queste istanze sono naturalmente mutabili.

Ora per l'interfaccia. Innanzitutto, dovresti controllare il tutorial di JTree ... e ora dovrebbe essere ovvio. Ogni "oggetto" può essere rappresentato da un DefaultMutableTreeNode, "userObject" del nodo dovrebbe essere il tuo oggetto (penso che il toString () di quel nodo sia visualizzato come etichetta del nodo, ma puoi creare un formattatore di celle personalizzato). Ogni volta che apri un nodo, sfogli i campi dell'oggetto e crei nodi figlio sotto il genitore (se vuoi farlo in modo dinamico) - oppure sfoglia l'intero albero e costruisci la struttura TreeNode quando visualizzi il JTree (suggerimento: lì è un constector JTree con un parametro TreeNode).

Quando si seleziona un nodo nella struttura, si ha l'istanza Object. Con la sua classe, puoi visualizzare un pannello dell'editor appropriato o uno generico generato dalla definizione della classe (come: pannelli tab con i campi, editor per il campo effettivo dalla dichiarazione del campo: un pulsante che crea un figlio del tipo corretto of ti consente di selezionare una delle classi disponibili e campi dell'editor per quell'istanza, come le proprietà dell'arma). Dopo aver modificato la struttura, è necessario aggiornare l'albero stesso: TreeModel e il suo fuoco ... le funzioni di cambio sono i tuoi amici.

Sembra bello? O troppo complesso? Bene, questa è una piccola parte della storia. Non ne ho parlato

• la gerarchia / o la classificazione delle definizioni di classe. È meglio utilizzarne uno quando supporterai l'aggiunta di classi diverse allo stesso campo (come diversi tipi di spade). Un professionista per la categorizzazione: una classe può avere più categorie, non un albero ereditario fisso, una buona cosa quando vuoi raccogliere "tutte le abilità" di un giocatore quando spendi l'XP per miglioramenti delle abilità ... :-)
• supporto di persistenza: devi creare una soluzione generica per archiviare la gerarchia di oggetti esternamente, come in un file proprietà o JSON. Usa un formato leggibile dall'uomo, NESSUNA serializzazione binaria, se vuoi mantenere il tuo cervello in buona forma.
• istanza di archiviazione: ti accorgerai presto che è meglio mantenere il "mondo" del tuo gioco in un unico posto. Una certa spada NON è una proprietà del tuo giocatore, ma un'entità nel mondo nel tuo gioco (il giocatore può perderla, qualcuno può trovarla, ecc.), Quindi molti di questi "oggetti" nel tuo albero sono in realtà RIFERIMENTI alle entità (mentre altri, come la salute del giocatore, sono in realtà solo attributi). Dovrai separare i due tipi, disporre di una memoria globale per le istanze in grado di risolvere i riferimenti. Questo ti salverà anche durante la serializzazione dello stato del gioco e più entità si riferiscono alla stessa altra entità (come la "Posizione" di più giocatori nello stesso tempio).
• (e per menzionare il vero cervello smerigliatrice: la somiglianza della memoria della classe e della memoria delle istanze; il fatto che la dichiarazione del tipo può essere istanze dell'oggetto stesso come i componenti del programma, le finestre attive, le sessioni utente, ecc. Questa è la terra di maniaci come me.)

Spero comunque che tu possa usare qualcosa di questa sessione di riscaldamento.

Non ho intenzione di darti una risposta lunga, ma ho affrontato questo tipo di situazione prima e, francamente, ho rinunciato a provare a utilizzare qualsiasi struttura di dati esistente. Ho semplicemente creato il mio oggetto in grado di accettare nuovi genitori e figli simili a un nodo XML.

Nel tuo caso, tuttavia, penso che l'utilizzo di una classe Xml ti aiuterà. È quindi possibile disporre di proprietà per ciascun nodo in grado di dirti se una classe è un'abilità e puoi facilmente ottenere genitori e figli di qualsiasi nodo che desideri utilizzare in una casella combinata o in altro modo.

Inoltre, vorrei aggiungere che non dovresti correre dal pensiero di avere molti testi / stringhe. I giochi di solito coinvolgono l'IA e l'IA di solito coinvolge molti testi.