Harap dicatat: Saya tidak ingin bantuan pengkodean di sini, saya ada Programmerskarena suatu alasan. Saya ingin meningkatkan kemampuan perencanaan program / penulisan saya bukan (hanya) pemahaman saya tentang Java .

Saya mencoba mencari cara membuat pohon yang memiliki sistem kategori sewenang-wenang, berdasarkan keterampilan yang tercantum untuk permainan LARP ini di sini . Usaha saya sebelumnya memiliki bool untuk apakah skill juga kategori. Mencoba kode di sekitar yang berantakan. Menarik pohon saya, saya perhatikan bahwa hanya 'daun' saya yang memiliki keterampilan dan saya memberi label yang lain sebagai kategori.

Apa yang saya kejar adalah cara untuk membuat pohon yang mencoba memisahkan Model dan Tampilan, dan memungkinkan menambahkan tipe arbiter dari simpul anak (dengan cara terpisah diedit / dirender) ke orangtua yang sewenang-wenang.

NB Semuanya di sini dibeli sebagai keterampilan, bahkan di tempat yang tampaknya seperti properti. Pengguna Akhir akan melihat ini sebagai keterampilan membeli (yang mereka lakukan di atm kertas) sehingga harus disajikan seperti itu, semua di halaman yang sama.

Penjelasan pohon: Pohon itu 'lahir' dengan seperangkat kategori tingkat tinggi kode keras ( Senjata, Fisik dan Mental, Medis dan banyak lagi dll). Dari ini pengguna harus dapat menambahkan keterampilan. Pada akhirnya mereka ingin menambahkan skill 'Pedang Spesialisasi Satu Tangan' ( bukan item) misalnya. Untuk melakukannya Anda akan idealnya klik 'add' dengan Weaponsdipilih dan kemudian pilih One-handeddari node combobox yang muncul pada anak itu, lalu klik tambahkan lagi dan masukkan nama dalam bidang teks pada yang node anak yang muncul. Kemudian klik tambahkan lagi untuk menambah / menentukan 'level' atau 'tingkat' untuk daun itu; kemahiran pertama, kemudian spesialisasi (misalnya).

Tentu saja jika Anda ingin membeli keterampilan yang berbeda, itu adalah rute yang sama sekali berbeda dengan daun. Anda mungkin tidak memerlukan kotak kombo pada tingkat yang sama di bawah pohon seperti yang Anda lakukan dengan contoh senjata, dan memerlukan logika lain di belakangnya. Inilah yang saya mengalami kesulitan untuk mendapatkan kepala saya apalagi pemrograman; bagaimana membuat satu set kelas dan tidak menentukan urutan untuk melampirkannya, tetapi masih memiliki semuanya cocok.

Apa sistem yang baik untuk menggambarkan pohon semacam ini dalam kode? Semua contoh JTree lainnya yang saya lihat memiliki beberapa pola yang dapat diprediksi , dan milik saya tidak . Saya tidak ingin harus mengkode semua ini dalam 'literal', dengan daftar panjang jenis apa (kombo-kotak, bidang teks dll) dari simpul anak-anak harus diizinkan pada orang tua apa. Haruskah saya menggunakan kelas abstrak? Antarmuka?

Bagaimana saya bisa membuat sekelompok objek ini dapat diperluas ketika saya menambahkan keterampilan lain yang tidak tercantum di atas yang berperilaku berbeda?

Jika tidak ada sistem yang baik untuk digunakan, apakah ada proses yang baik untuk mengetahui bagaimana melakukan hal semacam ini?

Roda gigi di kepala saya berputar:

Saya selalu perlu:

• Periksa orang tua
• Berikan opsi berdasarkan induknya

Saya mulai berpikir karena kesamaan ini saya perlu semacam skillkelas abstrak / antarmuka yang mendefinisikan / menguraikan metode umum untuk keterampilan dan kategori. Saya dapat (mudah-mudahan) memasukkan aturan dan opsi ke dalam basis data dan membaca dari sana. Pertanyaannya adalah saya pikir sekarang, antara metode abstrak atau antarmuka dan bagaimana cara mengimplementasikannya.

Contoh JTree yang Dapat Dimatikan

Kode (dipatuhi dan diuji dengan Java 7 untuk membuat gambar di atas):

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;
        }
    }
}

Terima kasih khusus untuk tutorial JTree ini

Pembaruan: Diskusi Kemungkinan Solusi

Ada tutorial membuat pohon dinamis , menggunakan tombol di bagian bawah bingkai untuk menambahkan / Hapus / Hapus node.

Untuk kotak kombo dan sejenisnya, Anda ingin mengambil objek dari kelas swing yang sesuai dan menjadikannya seperti JComboBox yang mengimplementasikan java.swing.tree.MutableTreeNode. Java Swing Tutorial memiliki daftar kontrol .

Anda masih perlu membuat elemen antarmuka pengguna untuk memungkinkan orang memilih jenis simpul mana yang ingin mereka tambahkan, dan untuk mengedit simpul. Jika mereka menambahkan kotak kombo, mereka harus dapat menentukan pilihan mana kotak akan tersedia.

Anda memerlukan model data yang mendasarinya untuk menyimpan data Anda. Anda bisa menggunakan skema serialisasi default yang dibangun ke semua objek Java, tetapi itu hanya untuk prototyping - itu akan rusak jika Anda pernah mengubah kode program Anda. Anda perlu menggunakan database dengan JDBC atau JPA atau Anda harus menulis rutin serialisasi Anda sendiri (atau menggunakan perpustakaan yang menangani serialisasi untuk Anda) menggunakan sesuatu seperti JSON atau XML sebagai format penyimpanan.

Pembaruan: Usulan Solusi dengan Tinjauan Proyek

Solusi paling sederhana mungkin melupakan database dan menghasilkan ekspresi XML dari data terlebih dahulu, kemudian mengedit file XML dan hanya menampilkan hasilnya sebagai JTree tanpa kotak kombo khusus atau apa pun. Saya pikir inilah yang disarankan oleh Chibueze Opata dengan jawabannya. Representasi XML parsial dari pohon ini mungkin terlihat seperti berikut:

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

Berikut adalah beberapa tonggak potensi untuk Anda:

• Buat format data XML atau JSON, lalu tulis sebuah program yang membaca file format itu dan menampilkannya sebagai JTree tanpa kotak kombo, hanya folder dan file.
• Tambahkan kontrol ayun ke tampilan JTree
• Perluas program Anda untuk menulis file yang sama
• Buat antarmuka pengguna sehingga pengguna dapat menambah dan mengedit node menggunakan GUI

Pastikan untuk menyimpan cadangan program Anda setiap kali ia bekerja di akhir setiap tonggak sejarah. Sistem kontrol sumber yang dipasang pada mesin lain sangat ideal untuk ini. Anda dapat menggunakan github, atau sourceforge, atau kontrol sumber publik lainnya jika Anda tidak keberatan membagikan kode Anda dan tidak ingin mengatur server dengan kontrol sumber di dalamnya.

Salah satu solusi ini adalah banyak pekerjaan, dan pasti lebih besar dari proyek pemula. Itu berarti Anda akan menghabiskan lebih banyak waktu untuk belajar Java Swing dan XML atau JSON daripada memainkan LARP Anda. Itulah mengapa saya pertama kali mengeksplorasi opsi membuat puas dengan alat yang ada. Tetapi cara terbaik untuk mempelajari sesuatu adalah cara Anda paling termotivasi untuk belajar. Jadi ini mungkin proyek yang sempurna untuk Anda.

Saya harap itu membantu.

Saya tidak berpikir JTree adalah representasi yang tepat untuk masalah yang Anda coba selesaikan. Saya melihat situs web Anda, dan saya melihat daftar barang. Ini adalah awal yang baik, tetapi saya pikir ada desain data dasar yang mungkin Anda miliki, tetapi saya tidak melihat.

Kehidupan dan Kekuatan tampak seperti atribut karakter bagiku. Double, Triple, dan Quadruple terlihat seperti nilai untuk atribut Strength. Kemudian saya melihat keterampilan dibagi menjadi Senjata dan Medis. Saya menganggap senjata sebagai barang milik (yang bisa Anda beli, temukan, atau jatuhkan), dan saya kira keterampilan itulah yang memungkinkan Anda menjadi efektif dengan senjata yang diberikan. Tapi dari cara saya melihatnya, senjata dan obat-obatan tidak memiliki keterampilan, karakter tidak. Bahkan, saya sangat curiga bahwa Karakter adalah tokoh utama dalam desain data Anda.

Berikut adalah tiga objek data yang menonjol bagi saya dari desain Anda sejauh ini:

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)

Sekarang karakter dapat memiliki senjata dan keterampilan, tetapi untuk serangan yang benar-benar bagus, mereka membutuhkan keterampilan khusus untuk senjata yang mereka gunakan. Bagaimanapun, ada hubungan satu-ke-banyak di sini (satu karakter dapat memiliki banyak keterampilan). Tapi saya belum melihat pohon.

Ambil kertas dan pada halaman pertama letakkan karakter di tengah-tengah halaman dan daftarkan 5-10 objek dunia game paling penting di sekitarnya. Cari tahu apa data hanyalah atribut dari objek lain (seperti Kehidupan dan Kekuatan menjadi bagian yang tidak dapat dipisahkan dari karakter) dan apa hubungan paling penting antara objek, tanpa memikirkan pohon atau bidang teks atau kotak kombo. Gambar garis-garis di antara objek untuk mewakili hubungan. Kemudian cari tahu hubungan mana yang 1: 1, yang mana 1: banyak, dan mana yang banyak: banyak dan beri label. Mungkin ada "memiliki-a" dan "adalah-a" dan jenis hubungan lainnya juga.

Anda dapat memutuskan bahwa Anda memerlukan representasi terpisah untuk WeaponSkill vs HealingSkill vs ManufactureSkill. Atau Anda dapat memutuskan mereka sangat mirip sehingga mereka termasuk dalam satu tabel Keterampilan (dalam contoh saya di atas) dengan bidang yang menentukan jenis keterampilan itu.

Ini pertanda baik bahwa Anda tidak puas dengan upaya Anda sejauh ini - itu berarti Anda bersedia mempertimbangkan banyak kemungkinan sebelum memilih satu. Semakin banyak sketsa yang Anda pertimbangkan, semakin baik desain akhir Anda. Akhirnya, yang terbaik akan menjadi diagram data Anda. Ketika itu diselesaikan dengan cukup baik, Anda dapat kembali berpikir tentang "kotak kombo" atau "bidang teks", tetapi saya akan membiarkan keputusan UI sampai akhir.

Daripada melihat JTrees, saya sarankan Anda melihat ke dalam topik Struktur Data, Desain Basis Data, dan mungkin Pemodelan Data. EDIT-> Atau diagram pemetaan hubungan entitas yang lebih baik seperti yang disarankan David Kaczynski! <-EDIT Jika Anda mendapatkan desain data yang benar, maka Java dan UI akan mengalir darinya dengan jelas dan alami. Tetapi jika Anda salah, maka tidak ada jumlah Java-kung-fu atau UI-beauty yang akan memperbaikinya.

Semoga berhasil!

Saya akan fokus pada model objek.

Saya pikir untuk fleksibilitas yang Anda inginkan, Anda mungkin ingin memisahkan kelas Anda menjadi pengetahuan (mungkin "definisi" adalah kata yang lebih baik dalam hal ini) lapisan dan lapisan transaksi. Dengan "lapisan", saya benar-benar hanya bermaksud memisahkan mereka secara logis di kepala Anda. Lapisan pengetahuan berisi definisi Anda tentang cara meletakkan pohon, dan data di dalamnya berasal dari perancang permainan dan lapisan data menyimpan pilihan tertentu untuk karakter tertentu.

Tingkat pengetahuan Anda akan setidaknya sedikit berantakan, karena Anda mencoba membuat game yang keren daripada model yang bersih secara matematis.

Mencoba mengatur apa yang Anda miliki sejauh ini, saya pikir Anda memiliki kelas SkillDefinition memiliki properti Induk tipe SkillDefinition. Anda juga memiliki subkelas SkillDefinition (yang dapat menjadi entri dalam tabel DEF_SkillType dalam database) untuk mencakup beberapa kasus.

"Senjata", "Fisik dan Mental", dan "Medis" tampaknya tidak memiliki apa-apa selain gelar (dan keterampilan anak).

"One Handed", "Strength", dan "Bind Wounds" tampaknya memiliki kotak kombo yang terkait (yang berarti sesuatu seperti tabel DEF_SkillChoice pada database dengan kunci asing ke DEF_Skill). Pedang dan Busur tampaknya menjadi string yang ditentukan pengguna (jadi tidak ada tabel terkait di tingkat pengetahuan, tetapi data akan disimpan pada lapisan transaksi).

"Hidup" tampaknya memiliki bilangan bulat yang terkait dengannya. Mungkin tidak dapat berbagi kelas ini dengan karakteristik masa depan yang menggunakan integer, karena ada perilaku tersirat tentang bagaimana integer bertambah. Bagaimanapun, saat ini memang membutuhkan kelas sendiri.

"Pedang", "Busur", "Kekuatan", dan "Bind Wounds" semuanya tampaknya memiliki tingkat keterampilan progresif yang terkait di bawah mereka di pohon. Dalam kasus "Pedang" dan "Busur", level tersebut benar-benar terkait dengan keterampilan orang tua mereka. Saya pikir Anda memerlukan kelas ProgressiveSkillDefinition dengan koleksi nilai hukum yang diurutkan (DEF_SkillLevel table dengan kunci asing untuk DEF_Skill. Pada tingkat pengetahuan tidak sepenuhnya jelas aturan apa yang Anda modelkan. Jika "kemahiran" dan "spesialisasi" selalu tersedia untuk semua senjata, Anda mungkin memiliki tabel DEF_SkillLevel dengan catatan "kemahiran" dan "spesialisasi" yang memiliki kunci asing untuk catatan "Senjata".

Ini mencakup apa yang Anda ketahui di tingkat pengetahuan. Tingkat transaksi (mungkin "tingkat karakter" akan menjadi nama yang lebih baik?) Hanya menunjuk ke tingkat pengetahuan yang sesuai. Jadi, dalam contoh Anda, Anda akan memiliki objek Karakter dengan objek Keterampilan yang memiliki koleksi keterampilan - hanya yang dia miliki.

Jadi, karakter akan memiliki keterampilan "Kemahiran" yang orang tuanya adalah keterampilan "pedang" dan yang jenisnya adalah Skill_Level. Dalam basis data, catatan TRANS_SkillDefinition memiliki kunci asing ke catatan keterampilan "pedang" transaksional dan tingkat pengetahuan DEF_SkillLevel mencatat dengan nama "Kemahiran".

Skill kecakapan akan memiliki objek induk dari skill "pedang", dari tipe Skill_UserNamed. Dalam basis data ini tidak akan memiliki kunci asing ke tingkat pengetahuan, karena tidak ada yang khusus didefinisikan untuk "pedang" (itu adalah nama pengguna). Namun ia juga memiliki kunci asing ke catatan transaksi induk, sehingga lebih banyak informasi tersedia melalui itu.

Objek keterampilan "pedang" memiliki objek induk "satu tangan", karena pengguna memilih untuk memasukkan "pedang" dalam kategori "satu tangan". Ini adalah objek tipe SkillCategory. Dalam database itu memiliki kunci asing ke tabel DEF_SkillChoice untuk catatan "satu tangan", dan tidak ada induk transaksional karena semua data tambahan untuk keterampilan ini disimpan pada tingkat pengetahuan.

Dalam membangun pohon awal untuk karakter baru, hanya tingkat pengetahuan yang perlu ditanyakan. Untuk mengisi pilihan yang dibuat untuk karakter memerlukan tingkat transaksional.

Anda akan memerlukan kode untuk menerjemahkan model objek ke pohon, dan kembali. Seharusnya jelas, saya harap, apa yang perlu Anda lakukan - setiap jenis pada lapisan pengetahuan akan memiliki satu set kontrol terkait pada pohon, yang mendapatkan data yang sesuai untuk jenis itu.

Kemudian Anda mungkin ingin kelas untuk setiap pilihan dalam catatan SkillCategory, (jika "Spesialisasi" memiliki perilaku yang terkait dengannya, kode harus pergi ke suatu tempat), tetapi Anda belum memerlukannya untuk pohon ini, dan desain ini akan kompatibel dengan itu. Anda hanya perlu memiliki pabrik yang menggunakan informasi tingkat pengetahuan untuk membangun objek yang tepat.

Bagaimanapun, kami selalu berakhir dengan mengelola struktur hierarkis - baik itu hirarki kelas dari suatu program, atau program itu sendiri dibangun dari berbagai modul yang menghubungkan Anda ke "dunia internal" (GUI, koneksi DB, logika bisnis data terikat, dll.) . Tetapi ini adalah filosofi, bagaimana cara kerjanya dalam kasus Anda?

Anda memiliki node di pohon ini, setiap item adalah "instance objek"; sementara perilaku mereka (di mana Anda dapat menempatkan mereka, daftar node anak yang diizinkan, dll) adalah umum untuk beberapa set, seperti "kelas". Ya, ini seperti kode program. Jika Anda cukup mengenal Java refleksi, Anda bahkan dapat menggunakan kelas POJO dan hierarki warisan untuk membangun komponen ini, dengan wadah IoC atau mekanisme pabrik untuk membuat instance yang sebenarnya. Tapi saya pikir Anda tidak menginginkan itu, karena itu adalah peretasan bahasa yang berat, jadi ...

Pertama, buat objek "class" yang akan menjelaskan perilaku item. Itu berisi pengidentifikasi kelas, nama "bidang" dan jenis serta jumlah item yang diizinkan, dll. Contoh: kelas "root" adalah "Properti Pemain", memiliki bidang "Fisik / Mental", "Medis", "Senjata". Tipe ini "final": saat ini Anda tidak ingin memiliki tipe pemain yang berbeda. Petunjuk: nanti kamu bisa melakukannya, menggunakan alat yang sama untuk menangani "monster non-manusia" ... :-)

Bidang "Medis" adalah

• "singleton": pemain tidak dapat memiliki beberapa informasi "Medis"
• tipe anak diperbaiki, hanya objek tipe "Medis" yang dapat digunakan di sini
• diperlukan: ketika Anda membuat pemain, itu harus memiliki bidang "Medis"

Berlawanan: Anggota senjata tidak diperlukan, itu harus dibuat ketika senjata pertama ditambahkan ke pemain Anda. Ini berarti: ketika Anda "mengedit" objek "Anda (sekarang pemain), dan ingin memperbolehkan menambahkan item baru padanya, Anda tidak boleh membatasi pemilihan dengan properti aktual dari instance (yang sekarang tidak mengandung" Senjata " "), tetapi perlihatkan semua bidang dari definisi kelas, dan malas membuat bidang baru (simpul anak) saat pertama kali digunakan. Ini akan menciptakan lingkungan yang dapat diperluas. Kemudian, Anda dapat menambahkan bidang "Teman" dengan beberapa pemain ... eh ... referensi (lihat nanti).

Ikuti prosesnya dengan "kelas" yang sebenarnya. Ini akan membantu Anda memperbaiki ide-ide Anda, seperti: tampaknya lebih baik untuk memisahkan jenis senjata (pedang, belati, busur, ...), menangani amunisi entah bagaimana (mengetahui bahwa pemain TIDAK memiliki busur tetapi dapat mengumpulkan panah, tetapi menggunakan panah, tetapi menggunakan senjata tertentu membutuhkan dan mengurangi amunisi, beberapa di antaranya dapat ditemukan, yang lain hilang ...) di bawah kelas "Senjata": lebih mudah untuk disurvei, dan juga menunjukkan apakah pemain Anda hanya membawa item itu atau dapat menggunakannya juga ( memiliki keterampilan). Di sisi lain: Anda pasti akan mengubah struktur ini nanti, saat Anda mengembangkan game Anda.

Buat "toko kelas" yang tersedia secara global yang Anda inisialisasi ketika game Anda mulai, dan sajikan definisi kelas ketika ada yang menyebut nama mereka. Objek def kelas harus tidak berubah dalam kasus ini.

"Objek" lebih mudah: mereka dapat diturunkan dari kelas akar yang sama yang berisi referensi ke definisi kelas, dan akses umum ke bidang juga. Mungkin menggunakan HashMap untuk memuat anak-anak itu, yang diidentifikasi dengan nama bidang. Ingat: beberapa bidang tersebut berisi satu objek, yang lain seperangkat objek. Contoh-contoh ini tentu saja bisa berubah.

Sekarang untuk antarmuka. Pertama, Anda harus memeriksa tutorial JTree ... , dan sekarang harus jelas. Setiap "objek" dapat diwakili oleh DefaultMutableTreeNode, "userObject" dari node harus menjadi objek Anda (saya pikir toString () dari node tersebut ditampilkan sebagai label node, tetapi Anda dapat membuat formatter sel khusus). Setiap kali Anda membuka simpul, Anda menelusuri bidang objek, dan membuat simpul anak di bawah induknya (jika Anda ingin melakukannya secara dinamis) - atau telusuri seluruh pohon dan bangun struktur TreeNode saat Anda menampilkan JTree (petunjuk: ada adalah JTree constuctor dengan parameter TreeNode).

Ketika Anda memilih simpul di pohon, Anda memiliki instance Object. Berdasarkan kelasnya, Anda dapat menampilkan panel editor yang tepat, atau generik yang dihasilkan oleh definisi kelas (seperti: panel tab dengan bidang, editor untuk bidang aktual dengan deklarasi bidang: tombol yang membuat anak dari jenis yang tepat of memungkinkan Anda memilih salah satu kelas yang tersedia, dan bidang editor untuk contoh itu, seperti properti senjata). Setelah memodifikasi struktur, Anda harus menyegarkan pohon itu sendiri - TreeModel dan fungsi perubahan ... api adalah teman Anda.

Terlihat bagus? Atau terlalu rumit? Nah, ini adalah sebagian kecil dari cerita. Saya belum membicarakannya

• hirarki definisi kelas / atau kategorisasi. Anda lebih baik menggunakan salah satu dari mereka ketika Anda akan mendukung menambahkan kelas yang berbeda ke bidang yang sama (seperti berbagai jenis pedang). Pro untuk kategorisasi: suatu kelas dapat memiliki beberapa kategori, bukan pohon warisan tetap, suatu hal yang baik ketika Anda ingin mengumpulkan "semua keterampilan" pemain ketika menghabiskan XP untuk peningkatan keterampilan ... :-)
• dukungan ketekunan: Anda harus membuat solusi umum untuk menyimpan hierarki objek secara eksternal, seperti pada properti atau file JSON. Gunakan format yang dapat dibaca manusia, TANPA serialisasi biner, jika Anda ingin menjaga otak Anda dalam kondisi yang baik.
• penyimpanan instan: Anda akan segera menyadari bahwa "dunia" gim Anda lebih baik disimpan di satu tempat. Pedang tertentu BUKAN milik pemain Anda, tetapi suatu entitas di dunia dalam permainan Anda (pemain bisa kehilangannya, seseorang dapat menemukannya, dll), begitu banyak dari "objek" di pohon Anda sebenarnya REFERENSI ke entitas (sementara yang lain, seperti kesehatan pemain benar-benar hanya atribut). Anda harus memisahkan kedua jenis, memiliki penyimpanan global untuk instance yang dapat menyelesaikan referensi. Ini juga akan menyelamatkan Anda saat membuat serial keadaan permainan, dan banyak entitas merujuk ke entitas lain yang sama (seperti "Lokasi" beberapa pemain ke kuil yang sama).
• (dan untuk menyebutkan penggiling otak nyata: kesamaan dari penyimpanan kelas dan penyimpanan contoh; fakta bahwa deklarasi tipe dapat objek contoh sendiri dengan cara yang sama seperti komponen program Anda, jendela aktif, sesi pengguna, dll. Ini adalah tanah orang gila seperti saya.)

Bagaimanapun, saya harap Anda dapat menggunakan sesuatu dari sesi pemanasan ini.

Saya tidak akan memberi Anda jawaban panjang, tetapi saya telah menghadapi situasi seperti ini sebelumnya dan terus terang, saya menyerah mencoba menggunakan struktur data yang ada. Saya hanya membuat objek sendiri yang bisa menerima orang tua dan anak baru yang mirip dengan XML Node.

Namun dalam kasus Anda, saya pikir menggunakan Kelas Xml akan membantu. Anda kemudian dapat memiliki properti untuk setiap node yang dapat memberi tahu Anda jika kelas adalah keterampilan dan Anda dapat dengan mudah mendapatkan orang tua dan anak-anak dari simpul apa pun yang Anda inginkan untuk digunakan dalam kotak kombo atau sebaliknya.

Juga, saya ingin menambahkan Anda tidak boleh lari dari pikiran memiliki banyak teks / string. Game biasanya melibatkan AI, dan AI biasanya melibatkan banyak teks.