Lütfen dikkat: Burada kodlama yardımı istemiyorum, Programmersbir nedenden dolayı varım . Program planlama / yazma becerilerimi geliştirmek (sadece) Java anlayışımı geliştirmek değil .

Bu LARP oyun için listelenen becerilerine dayalı keyfi bir sınıflandırma sistemi vardır bir ağaç, nasıl anlamaya çalışıyorum burada . Önceki girişimim, bir becerinin de bir kategori olup olmadığı konusunda bir bool vardı. Kodlamayı denemek dağınıktı. Ağacımı çıkarırken sadece 'yapraklar'mın beceri olduğunu fark ettim ve diğerlerini kategori olarak etiketledim.

Neyin peşindeyim, Modeli ve Görünümü ayırmayı deneyen ve keyfi bir ebeveyne arbiter tipte bir çocuk düğümü (ayrı bir şekilde düzenlenerek / işlenerek) eklenmesine izin veren bir ağaç oluşturmanın bir yoludur.

Not Buradaki her şey bir mülk gibi görünse bile bir beceri olarak satın alınır. Son Kullanıcılar bunu satın alma becerileri olarak görürler (kağıt atm'de yaptıkları), bu yüzden hepsi aynı sayfada sunulmalıdır.

Ağacın açıklaması: Ağaç, bir dizi sabit kodlanmış en üst düzey kategoriyle ( Silahlar, Fiziksel ve Zihinsel, Tıbbi vb.) 'Doğar' . Bundan, kullanıcının bir beceri ekleyebilmesi gerekir. Nihayetinde, örneğin 'Tek elle kullanılan Kılıç Uzmanlığı' becerisini ( eşya değil ) eklemek istiyorlar . Eğer ideal olan 'eklentiyi' tıklıyordunuz Bunu yapmak için Weaponsseçilen ve ardından seçmek One-handedtekrar eklemek bir combobox düğümden o çocuk üzerinde görünür, daha sonra 'yi tıklayın ve bir metin alanına bir isim girin o çocuk düğüm olduğunu görünür. Ardından, o yaprak için bir 'düzey' veya 'katman' eklemek / belirtmek üzere tekrar ekle'yi tıklayın; önce uzmanlık, sonra uzmanlık (örneğin).

Tabii ki farklı bir beceri almak istiyorsanız, yaprak için tamamen farklı bir yoldur. Silah örneğiyle yaptığınızla aynı seviyede bir açılan kutuya ihtiyacınız olmayabilir ve arkasında başka bir mantığa da ihtiyacınız olabilir. Bu, programlama yapmama izin vermek için başımı döndürmekte sorun yaşıyorum; nasıl sınıflar kümesi yapmak ve değil birlikte bunları bağlamak için hangi sırayla belirtmek, ama yine de hepsini bir uyum var.

Bu tür bir ağacı kodda tanımlamak için iyi bir sistem nedir? Gördüğüm diğer tüm JTree örneklerinde tahmin edilebilir bir desen var ve benimki de yok . Ben tüm bu 'değişmez' kodlamak zorunda istemiyorum, ne tür (açılan kutu, metin alanı vb) çocuk düğümü hangi ebeveyn üzerinde izin verilmelidir uzun listeleri ile . Soyut dersler mi kullanmalıyım? Arabirimler?

Yukarıda listelenmeyen ve farklı davranan başka beceriler eklediğimde, bu tür nesneler kümesini genişletilebilir hale nasıl getirebilirim?

Yoksa değil kullanımına iyi bir sistem, bu tür bir şey yapmak nasıl çalışmak için iyi bir süreç var mı?

Kafamdaki dişliler dönüyor:

Her zaman yapmam gerek:

• Ebeveyni kontrol et
• Ebeveyne dayalı seçenekler sunun

skillBeceri ve kategori için ortak yöntemleri tanımlayan / özetleyen bir tür soyut / arabirim sınıfına ihtiyacım var bu ortaklığın nedeni düşünmeye başladım . (Umarım) bir veritabanına kurallar ve seçenekler koyabilir ve oradan-okumak. Soru şu an, soyut veya arayüz yöntemi ile bunun nasıl uygulanacağı arasında düşünüyorum.

Basit Değiştirilebilir JTree Örneği

Kod (yukarıdaki görüntüyü yapmak için Java 7 ile uyumlu ve test edilmiştir):

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

Bu JTree öğreticisine özel teşekkürler

Güncelleme: Olası Çözümlerin Tartışılması

Düğüm eklemek / Kaldır / Temizle düğümleri için çerçevenin altındaki düğmeleri kullanarak dinamik bir ağaç yapma hakkında bir öğretici vardır .

Birleşik giriş kutuları ve benzerleri için, uygun swing sınıfının nesnelerini almak ve java.swing.tree.MutableTreeNode uygulayan bir JComboBox gibi bir şey olmasını istersiniz. Java Swing Eğitimi'nde bir kontrol listesi vardır .

İnsanların ne tür bir düğüm eklemek istediklerini seçmelerine ve düğümü düzenlemelerine izin vermek için yine de bir kullanıcı arabirimi öğesi oluşturmanız gerekir. Birleşik giriş kutusu eklerse, kutunun hangi seçenekleri sunacağını tanımlayabilmeleri gerekir.

Verilerinizi kaydetmek için temel alınan bir veri modeline ihtiyacınız vardır. Tüm Java nesnelerine yerleşik varsayılan serileştirme şemasını kullanabilirsiniz, ancak yalnızca prototipleme içindir - program kodunuzu değiştirirseniz bozulur. Depolama biçimi olarak JSON veya XML gibi bir şey kullanarak JDBC veya JPA ile bir veritabanı kullanmanız veya kendi serileştirme yordamlarınızı yazmanız (veya sizin için serileştirmeyi işleyen bir kitaplık kullanmanız) gerekecektir.

Güncelleme: Projeye Genel Bakış ile Önerilen Çözüm

En basit çözüm, veritabanlarını unutmak ve önce verilerin XML ifadesini bulmak, daha sonra XML dosyasını düzenlemek ve sonuçları özel birleşik giriş kutuları veya herhangi bir şey olmadan bir JTree olarak görüntülemek olabilir. Sanırım Chibueze Opata'nın cevabı ile önerdiği buydu. Bu ağacın kısmi bir XML temsili aşağıdaki gibi görünebilir:

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

İşte sizin için bazı potansiyel kilometre taşları:

• Bir XML veya JSON veri formatı oluşturun, ardından bu formattaki bir dosyayı okuyan ve birleşik giriş kutusu, yalnızca klasörler ve dosyalar olmadan bir JTree olarak görüntüleyen bir program yazın.
• JTree ekrana salınım kontrolleri ekleme
• Aynı dosyayı yazmak için programınızı genişletin
• Kullanıcının GUI'yi kullanarak düğüm ekleyip düzenleyebilmesi için bir kullanıcı arabirimi oluşturun

Her kilometre taşının sonunda çalıştığında programınızın bir yedeğini kaydettiğinizden emin olun. Bunun için başka bir makineye kurulmuş bir kaynak kontrol sistemi idealdir. Kodunuzu paylaşmayı düşünmüyorsanız ve üzerinde kaynak kontrolü olan bir sunucu kurmak istemiyorsanız, github veya sourceforge veya başka bir genel kaynak kontrolü kullanabilirsiniz.

Bu çözümlerden herhangi biri çok iş ve kesinlikle yeni başlayan bir projeden daha büyük. Bu, Java Swing ve XML veya JSON öğrenmek için LARP'nizi oynamaktan çok daha fazla zaman harcayacağınız anlamına gelir, bu yüzden ilk önce mevcut araçlarla yapma seçeneklerini araştırdım. Ancak bir şeyi öğrenmenin en iyi yolu, öğrenmek için en fazla motive olduğunuz yöntemdir. Bu sizin için mükemmel bir proje olabilir.

Umarım bu yardımcı olur.

JTree'nin çözmeye çalıştığınız problem için doğru temsil olduğunu düşünmüyorum. Web sitenize baktım ve malzeme listeleri görüyorum. Bu harika bir başlangıç, ama sahip olabileceğiniz temel bir veri tasarımı olduğunu düşünüyorum, ama görmüyorum.

Yaşam ve Güç bana karakter nitelikleri gibi geliyor. Double, Triple ve Quadruple, Strength özelliği için değerlere benziyor. Sonra silah ve tıbbın ayrıldığını görüyorum. Silahları mülkler olarak düşünüyorum (satın alabileceğiniz, bulabileceğiniz veya düşürebileceğiniz) ve belirli bir silahla etkili olmanızı sağlayan yetenek olduğunu düşünüyorum. Ama bakış açımdan, silahların ve tıbbın yetenekleri yok, karakter var. Aslında, karakterin veri tasarımınızın merkezi figürü olduğundan şüpheleniyorum.

Şimdiye kadar tasarımınızdan öne çıkan üç veri nesnesi:

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)

Artık bir karakterin silahları ve becerileri olabilir, ama gerçekten iyi bir saldırı için kullandıkları silaha özgü bir beceriye ihtiyaçları vardır. Her durumda, burada bire çok ilişkiler vardır (bir karakterin birçok yeteneği olabilir). Ama henüz ağaç göremiyorum.

Bir sayfa kağıt alın ve ilk sayfada karakteri sayfanın ortasına koyun ve etrafındaki 5-10 en önemli oyun dünyası nesnesini listeleyin. Hangi verilerin yalnızca başka bir nesnenin (Yaşam ve Güç'ün karakterin ayrılmaz parçaları olması) bir özelliği olduğunu ve ağaçlar, metin alanları veya birleşik kutular düşünülmeden nesneler arasındaki en önemli ilişkilerin neler olduğunu anlayın. İlişkileri temsil etmek için nesneler arasında çizgiler çizin Daha sonra hangi ilişkilerin 1: 1, hangilerinin 1: çok olduğunu ve hangilerinin çok olduğunu: çoğunu bulun ve etiketleyin. "Has-a" ve "is-a" ve başka türden ilişkiler de olabilir.

Bir WeaponSkill ve HealingSkill vs.ManufactureSkill için ayrı temsillere ihtiyacınız olduğuna karar verebilirsiniz. Ya da o kadar benzer olduklarına, bir beceri tablosuna ait olduklarına (yukarıdaki örneğimde), hangi tür beceri olduğunu belirleyen bir alana sahip olduklarına karar verebilirsiniz.

Şimdiye kadar yaptığınız girişimlerden memnun olmadığınızın iyi bir işaretidir - birini seçmeden önce birçok olasılığı düşünmeye istekli olduğunuz anlamına gelir. Ne kadar çok eskiz düşünürseniz, son tasarımınız o kadar iyi olur. Sonunda, en iyisi veri diyagramınız olacak. Bu oldukça iyi bir şekilde çözüldüğünde, "birleşik kutular" veya "metin alanları" hakkında düşünmeye geri dönebilirsiniz, ancak kullanıcı arayüzü kararlarını sonuna kadar bırakırım.

JTrees'e bakmak yerine Veri Yapıları, Veritabanı Tasarımı ve belki de Veri Modelleme konularına bakmanızı öneririm. EDIT-> Ya da David Kaczynski'nin önerdiği gibi daha iyi ama varlık-ilişki haritalama diyagramları! <-EDIT Veri tasarımını doğru yaparsanız, Java ve UI açıkça ve doğal olarak ondan akacaktır. Ancak yanlış anlarsanız, hiçbir Java-kung-fu veya UI-güzellik bunu düzeltmeyecektir.

İyi şanslar!

Nesne modeline odaklanacağım.

İstediğiniz esneklik için, muhtemelen sınıflarınızı bir bilgi (belki de "tanım" bu durumda daha iyi bir kelime) katmanına ve bir işlem katmanına ayırmak istiyorsunuz. "Katman" ile gerçekten onları mantıksal olarak kafanızda ayırmak istiyorum. Bilgi katmanı, ağacın nasıl yerleştirileceği ile ilgili tanımınızı içerir ve içindeki veriler bir oyun tasarımcısından gelir ve veri katmanı belirli bir karakter için belirli seçenekleri saklar.

Bilgi seviyeniz en azından biraz dağınık olacaktır, çünkü matematiksel olarak temiz bir model yerine havalı bir oyun yapmaya çalışıyorsunuz.

Şimdiye kadar sahip olduklarınızı organize etmeye çalışırken, bir SkillDefinition sınıfınız olduğunu düşünüyorum SkillDefinition türünde bir Parent özelliği var. Ayrıca birkaç örneği kapsamak için SkillDefinition (veritabanındaki DEF_SkillType tablosuna girişler olabilir) alt sınıflarınız da vardır.

“Silahlar”, “Fiziksel ve Zihinsel” ve “Tıbbi” unvanı (ve çocuk becerileri) dışında bir şeyleri yok gibi görünüyor.

"One Handed", "Strength" ve "Bind Wounds" ilişkili bir birleşik giriş kutusuna sahip gibi görünüyor (DEF_Skill için yabancı anahtar ile veritabanında DEF_SkillChoice tablosu gibi bir şey anlamına geliyor). Kılıç ve Yay kullanıcı tanımlı bir dize gibi görünüyor (bu nedenle bilgi düzeyinde ilişkili tablo yok, ancak veriler işlem katmanında saklanacak).

"Hayat" ile ilişkili bir tamsayı var gibi görünüyor. Bu sınıfı, tamsayı kullanan gelecekteki herhangi bir özellikle paylaşamayabilir, çünkü tamsayı nasıl artırıldığına dair ima edilen davranış vardır. Her durumda, şu anda kendi sınıfına ihtiyacı var.

"Kılıç", "Yay", "Kuvvet" ve "Bağlama Yaraları" nın hepsinin ağaçta altlarında ilerleyici beceri seviyeleri olduğu görülüyor. "Kılıç" ve "Yay" durumunda, bu seviyeler gerçekten ebeveyn yetenekleriyle ilişkilidir. Bence yasal değerleri sıralı bir koleksiyon (DEF_Skill için yabancı anahtar ile DEF_SkillLevel tablosu) içeren bir ProgressiveSkillDefinition sınıfına ihtiyacınız var. Bilgi düzeyinde hangi kuralları modellediğiniz tam olarak açık değil. tüm silahlar için, "Silahlar" kaydının yabancı anahtarları olan "uzmanlık" ve "uzmanlık" kayıtlarına sahip bir DEF_SkillLevel masanız olabilir.

Bu, bilgi düzeyinde bildiklerinizi kapsar. İşlem seviyesi (belki de "karakter seviyesi" daha iyi bir isim olabilir mi?) Sadece uygun bilgi seviyesine işaret eder. Yani, örneğinizde, bir beceri koleksiyonuna sahip bir Skills nesnesi olan bir Karakter nesnesine sahip olacaksınız - sadece sahip oldukları.

Yani, karakterin üstü "kılıç" yeteneği olan ve türü Skill_Level olan bir "Yeterlilik" becerisine sahip olacaktır. Veritabanında TRANS_SkillDefinition kaydının işlemsel "kılıç" beceri kaydına ve "Proficiency" adıyla bilgi düzeyi DEF_SkillLevel kaydına yabancı bir anahtarı vardır.

Yeterlilik becerisi, Skill_UserNamed türünde "kılıç" becerisinin bir üst nesnesine sahip olacaktır. Veritabanında bunun bilgi seviyesine yabancı bir anahtarı yoktur, çünkü "kılıç" için özel bir şey tanımlanmamıştır (kullanıcının adıdır). Bununla birlikte, ana işlem kaydının da yabancı bir anahtarı vardır, bu nedenle daha fazla bilgi elde edilebilir.

"Kılıç" beceri nesnesinin "tek elle" bir üst nesnesi vardır, çünkü kullanıcı "tek elle" kategorisine "kılıç" koymayı seçmiştir. Bu SkillCategory türünde bir nesnedir. Veritabanında, "tek elle" kaydı için DEF_SkillChoice tablosuna yabancı bir anahtar vardır ve bu beceri için tüm ek veriler bilgi düzeyinde depolandığından işlem üst öğesi yoktur.

Yeni bir karakter için başlangıç ​​ağacını oluştururken, sadece bilgi seviyesinin sorgulanması gerekir. Bir karakter için yapılan seçimleri doldurmak için işlem düzeyi gerekir.

Nesne modelini bir ağaca ve geri çevirmek için koda ihtiyacınız olacaktır. Umarım ne yapmanız gerekir - bilgi katmanındaki her türün ağaç üzerinde, bu tür için uygun verileri alan ilişkili bir kontrol kümesi olacaktır.

Daha sonra SkillCategory kayıtlarındaki her seçim için sınıflar isteyebilirsiniz ("Uzmanlık" ile ilişkili davranış varsa, kod bir yere gitmelidir), ancak bu ağaç için buna ihtiyacınız yoktur ve bu tasarım uyumlu olacaktır Bununla. Doğru nesneyi oluşturmak için bilgi düzeyi bilgilerini kullanan bir fabrikaya sahip olmanız yeterlidir.

Sonuçta, her zaman hiyerarşik yapıları yönetmeyle bitiririz - bir programın sınıf hiyerarşisi veya programın kendisi sizi "iç dünyaya" (GUI, DB bağlantısı, veri bağlantılı iş mantığı, vb.) Bağlayan farklı modüllerden oluşturulmuştur. . Ama bu felsefe, sizin durumunuzda nasıl işler?

Bu ağaçta düğümleriniz var, her öğe bir "nesne örneği" dir; davranışları (bunları koyabileceğiniz yerlerde, izin verilen alt düğümlerin listesi vb.) "sınıflar" gibi bazı kümeler için ortaktır. Evet, bu bir program kodu gibi. Java yansımasını yeterince biliyorsanız, bu bileşenleri oluşturmak için bir IoC kapsayıcısı veya gerçek örnekleri oluşturmak için bir fabrika mekanizmasıyla POJO sınıflarını ve miras hiyerarşisini bile kullanabilirsiniz. Ama bence bunu istemiyorsun, çünkü bu ağır bir dil saldırısı, yani ...

İlk olarak, öğelerin davranışını tanımlayacak bir "sınıf" nesnesi oluşturun. Sınıf tanımlayıcısı, "alan" adları ve izin verilen tür ve öğe sayısı vb. İçerir. Örnek: "kök" sınıfı "Oyuncu Özellikleri" dir, "Fiziksel / Zihinsel", "Tıbbi", "Silahlar" alanına sahiptir. Bu tür "final" dir: şu anda farklı oyuncu türlerine sahip olmak istemezsiniz. İpucu: daha sonra "insan olmayan canavarlar" için aynı araçları kullanarak yapabilirsiniz ... :-)

"Tıp" alanı

• "singleton": oynatıcıda birden fazla "Tıbbi" bilgi olamaz
• alt tür sabittir, burada yalnızca "Tıp" türündeki nesneler kullanılabilir
• gerekli: bir oyuncu oluşturduğunuzda, onun bir "Tıbbi" alanı olmalıdır

Aksine: Silah üyesi gerekli değildir, oyuncunuza ilk silah eklendiğinde oluşturulmalıdır. Bu şu anlama gelir: "nesnenizi" (şimdi oynatıcınızı) "düzenlediğinizde" ve buna yeni bir öğe eklemenize izin vermek istediğinizde, seçimi örneğin (Silahlar içermeyen) gerçek özelliklerine göre sınırlandırmamalısınız. ") içerir, ancak sınıf tanımının tüm alanlarını gösterir ve ilk kullanıldığında yeni alanı (alt düğüm) tembel olarak oluşturun. Bu, genişletilebilir bir ortam yaratacaktır. Daha sonra, çoklu oynatıcı ... er ... referanslarıyla "Arkadaşlar" alanını ekleyebilirsiniz (daha sonra bakınız).

Süreci gerçek "sınıflar" ile takip edin. Fikirlerinizi geliştirmenize yardımcı olacak, örneğin: silah türlerini (kılıçlar, hançerler, yaylar, ...) ayırmak, bir şekilde cephaneyi idare etmek daha iyi görünüyor (belki de oyuncunun bir yayı OLMADI ancak okları toplayabildiğini bilmek, ancak bazı silahlar cephane gerektirir ve azaltır, bazıları bulunabilir, bazıları kaybolur ...) "Silahlar" sınıfı altında: Anket yapmak daha kolaydır ve ayrıca oyuncunuzun sadece bu öğeyi taşıdığını veya kullanıp kullanamayacağını gösterir ( yetenekleri vardır). Öte yandan: oyununuzu geliştirdikçe bu yapıyı daha sonra kesinlikle değiştireceksiniz.

Oyununuz başladığında başlattığınız, dünya çapında kullanılabilir bir "sınıf mağazası" oluşturun ve birisi ismini ifade ettiğinde sınıf tanımlarını sunun. Bu durumda sınıf def nesneleri değiştirilemez olmalıdır.

"Nesneler" daha kolaydır: sınıf tanımına başvuru ve alanlara genel erişim içeren aynı kök sınıfından türetilebilirler. Alan adıyla tanımlanan bu çocukları içermek için bir HashMap kullanın. Unutmayın: bu alanlardan bazıları tek bir nesne, diğerleri bir dizi nesne içerir. Bu örnekler elbette değişebilir.

Şimdi arayüz için. İlk olarak, JTree öğreticisini kontrol etmelisiniz ... ve şimdi açık olmalıdır. Her "nesne" bir DefaultMutableTreeNode tarafından temsil edilebilir, düğümün "userObject" nesneniz olmalıdır (Ben bu düğümün toString () düğümün etiketi olarak görüntülendiğini düşünüyorum, ancak özel hücre biçimlendirici oluşturabilirsiniz). Bir düğümü açtığınızda, nesnenin alanlarına göz atarsınız ve üst öğenin altında (dinamik olarak yapmak istiyorsanız) alt düğümler oluşturursunuz - veya JTree'yi görüntülerken ağacın tamamına göz atar ve TreeNode yapısını oluşturur (ipucu: orada bir TreeNode parametresine sahip bir JTree yapıcıdır).

Ağaçta bir düğüm seçtiğinizde, Object örneğine sahip olursunuz. Sınıfına göre, uygun bir düzenleyici panelini veya sınıf tanımıyla oluşturulan genel bir paneli görüntüleyebilirsiniz (örneğin: alanlı sekme panelleri, alan bildirimi ile gerçek alan için editörler: uygun türde bir alt öğe oluşturan bir düğme , kullanılabilir sınıflardan birini seçmenize olanak tanır ve bu örnek için silah özellikleri gibi editör alanları). Yapıyı değiştirdikten sonra, ağacın kendisini yenilemeniz gerekir - TreeModel ve ateş ... değiştirme işlevleri arkadaşlarınızdır.

Güzel gözüküyor? Yoksa çok mu karmaşık? Bu hikayenin küçük bir kısmı. Hakkında konuşmadım

• sınıf tanımı hiyerarşisi / veya kategorizasyonu. Aynı alana farklı sınıflar eklemeyi destekleyeceğiniz zaman bunlardan birini kullanmanız daha iyi olur (farklı kılıç türleri gibi). Bir sınıflandırma uzmanı: bir sınıf, XP'yi beceri geliştirmelerine harcarken, bir oyuncunun "tüm becerilerini" toplamak istediğinizde sabit bir miras ağacı değil, birden fazla kategoriye sahip olabilir ... :-)
• kalıcılık desteği: Nesne hiyerarşisini harici olarak depolamak için bir özellikte veya JSON dosyasında olduğu gibi genel bir çözüm oluşturmanız gerekir. Beyninizi iyi durumda tutmak istiyorsanız, insan tarafından okunabilir bir format kullanın, ikili serileştirme YOK.
• örnek depolama: Yakında oyununuzun "dünyasının" tek bir yerde tutulmasının daha iyi olacağını fark edeceksiniz. Belirli bir kılıç, oyuncunuzun bir mülkü DEĞİLDİR, ancak oyununuzdaki dünyadaki bir varlık (oyuncu onu kaybedebilir, biri bulabilir, vb.), Yani ağacınızdaki bu "nesnelerin" çoğu aslında varlıklara REFERANSLARDIR (oyuncunun sağlığı gibi diğerleri gerçekten sadece özelliklerdir). İki türü ayırmanız, başvuruları çözebilecek örnekler için genel bir depolama alanına sahip olmanız gerekir. Bu, oyun durumunu serileştirirken sizi de kurtaracak ve birden çok varlık aynı diğer varlığa atıfta bulunacaktır (birden fazla oyuncunun aynı tapınağa "Konumu" gibi).
• (ve gerçek beyin öğütücüsünden bahsetmek gerekirse: sınıf depolamasının ve örnek depolamasının benzerliği; tür bildiriminin, program bileşenleriniz, aktif pencereleriniz, kullanıcı oturumlarınız vb. gibi nesne örnekleri olabileceği gerçeği. benim gibi manyakların.)

Her neyse, umarım bu ısınma oturumunun bir kısmını kullanabilirsiniz.

Size uzun bir cevap vermeyeceğim, ama daha önce bu tür bir durumla karşılaştım ve açıkçası, mevcut herhangi bir veri yapısını kullanmaya çalışmaktan vazgeçtim. Basitçe XML Düğümüne benzer yeni ebeveynleri ve çocukları kabul edebilecek kendi nesnemi yarattım.

Ancak sizin durumunuzda, bir Xml Sınıfı kullanmanın yardımcı olacağını düşünüyorum. Daha sonra her düğüm için, bir sınıfın beceri olup olmadığını söyleyebilecek özelliklere sahip olabilir ve birleşik giriş kutusunda veya başka bir şekilde kullanmak istediğiniz herhangi bir düğümün ebeveynlerini ve çocuklarını kolayca alabilirsiniz.

Ayrıca, çok sayıda metin / dizeye sahip olma düşüncesinden kaçmamanız gerektiğini eklemek istiyorum. Oyunlar genellikle AI içerir ve AI genellikle çok sayıda metin içerir.