Xin lưu ý: Tôi không muốn trợ giúp về mã hóa ở đây, Programmersvì một lý do. Tôi muốn cải thiện kỹ năng lập kế hoạch / viết chương trình chứ không phải (chỉ) sự hiểu biết của tôi về Java .

Tôi đang cố gắng tìm ra cách tạo một cây có hệ thống thể loại tùy ý, dựa trên các kỹ năng được liệt kê cho trò chơi LARP này tại đây . Nỗ lực trước đây của tôi đã có một bool cho dù một kỹ năng cũng là một thể loại. Cố gắng để mã xung quanh đó là lộn xộn. Rút ra cây của tôi, tôi nhận thấy rằng chỉ có 'lá' của tôi là các kỹ năng và tôi đã gắn nhãn cho các loại khác là các danh mục.

Những gì tôi đang theo là một cách để tạo một cây cố tách Mô hình và Chế độ xem và cho phép thêm một loại nút con tùy ý (với một cách riêng biệt được chỉnh sửa / kết xuất) cho cha mẹ tùy ý.

NB Tất cả mọi thứ ở đây được mua như một kỹ năng, ngay cả khi nó có vẻ như là một tài sản. Người dùng cuối sẽ xem đây là kỹ năng mua hàng (mà họ làm trên giấy atm) vì vậy nên được trình bày như vậy, tất cả trên cùng một trang.

Giải thích về cây: Cây được 'sinh ra' với một tập hợp các loại cấp cao nhất được mã hóa cứng ( Vũ khí, Vật lý và Tâm thần, Y tế và hơn thế nữa, v.v.). Từ đó người dùng cần có khả năng thêm một kỹ năng. Cuối cùng, họ muốn thêm kỹ năng 'Chuyên môn kiếm một tay' ( không phải vật phẩm). Để làm như vậy bạn sẽ lý tưởng nhấp vào 'add' với Weaponslựa chọn và sau đó chọn One-handedtừ một nút combobox xuất hiện trên con đó, rồi bấm thêm một lần nữa và nhập tên trong một lĩnh vực văn bản trên mà nút con xuất hiện. Sau đó bấm thêm lần nữa để thêm / chỉ định 'cấp' hoặc 'cấp' cho lá đó; thành thạo đầu tiên, sau đó chuyên môn hóa (ví dụ).

Tất nhiên, nếu bạn muốn mua một kỹ năng khác, đó là một con đường hoàn toàn khác với chiếc lá. Bạn có thể không cần một hộp tổ hợp ở cùng cấp với cây như bạn đã làm với ví dụ về vũ khí, và cũng cần một số logic khác đằng sau nó. Đây là những gì tôi gặp khó khăn khi phải suy nghĩ về việc lập trình; làm thế nào để tạo một tập hợp các lớp và không chỉ định thứ tự để gắn chúng lại với nhau, nhưng vẫn có tất cả chúng phù hợp.

Một hệ thống tốt để mô tả loại cây này trong mã là gì? Tất cả các ví dụ JTree khác mà tôi đã thấy có một số mẫu có thể dự đoán được và tôi thì không . Tôi không muốn phải viết mã tất cả bằng 'chữ', với các danh sách dài về loại (hộp tổ hợp, trường văn bản, v.v.) của nút con nên được cho phép trên cha mẹ. Tôi có nên sử dụng các lớp trừu tượng? Giao diện?

Làm thế nào tôi có thể làm cho loại cụm đối tượng này có thể mở rộng khi tôi thêm vào các kỹ năng khác không được liệt kê ở trên mà hành xử khác nhau?

Nếu có không một hệ thống tốt để sử dụng, là có một quá trình tốt để làm việc ra làm thế nào để làm việc này?

Các bánh răng trong đầu tôi đang quay:

Tôi luôn cần phải:

• Kiểm tra phụ huynh
• Cung cấp tùy chọn dựa trên cha mẹ

Tôi đang bắt đầu nghĩ rằng vì sự phổ biến này, tôi cần một số loại skilllớp trừu tượng / giao diện xác định / phác thảo các phương thức phổ biến cho kỹ năng và thể loại. Tôi có thể (hy vọng) đặt các quy tắc và tùy chọn trong cơ sở dữ liệu và đọc từ đó. Câu hỏi là tôi nghĩ bây giờ, giữa một phương pháp trừu tượng hoặc giao diện và làm thế nào để thực hiện điều đó.

Ví dụ JTree đơn giản có thể thay đổi

Mã (đã tuân thủ và được thử nghiệm với Java 7 để tạo hình ảnh trên):

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

Đặc biệt cảm ơn hướng dẫn JTree này

Cập nhật: Thảo luận về các giải pháp có thể

Có một hướng dẫn về cách tạo cây động , sử dụng các nút ở dưới cùng của khung để thêm / Xóa / Xóa nút.

Đối với các hộp tổ hợp và như vậy, bạn muốn lấy các đối tượng của lớp swing thích hợp và để chúng giống như một JComboBox thực hiện java.swing.tree.MutableTreeNode. Hướng dẫn xoay Java có một danh sách các điều khiển .

Bạn vẫn cần tạo một thành phần giao diện người dùng để cho phép mọi người chọn loại nút nào họ muốn thêm và chỉnh sửa nút. Nếu họ thêm hộp tổ hợp, họ sẽ cần có khả năng xác định lựa chọn nào mà hộp sẽ có sẵn.

Bạn cần một mô hình dữ liệu cơ bản để lưu dữ liệu của bạn. Bạn có thể sử dụng lược đồ tuần tự hóa mặc định được tích hợp trong tất cả các đối tượng Java, nhưng nó chỉ dành cho tạo mẫu - nó sẽ bị hỏng nếu bạn thay đổi mã chương trình. Bạn sẽ cần sử dụng cơ sở dữ liệu với JDBC hoặc JPA hoặc bạn sẽ cần viết các thói quen tuần tự hóa của riêng bạn (hoặc sử dụng một thư viện xử lý tuần tự hóa cho bạn) bằng cách sử dụng một cái gì đó như JSON hoặc XML làm định dạng lưu trữ.

Cập nhật: Giải pháp đề xuất với Tổng quan dự án

Giải pháp đơn giản nhất có thể là quên cơ sở dữ liệu và đưa ra biểu thức XML của dữ liệu trước, sau đó chỉnh sửa tệp XML và chỉ hiển thị kết quả dưới dạng JTree mà không cần hộp tổ hợp đặc biệt hoặc bất cứ điều gì. Tôi nghĩ rằng đây là những gì Chibueze Opata đã gợi ý với câu trả lời của anh ấy. Một biểu diễn XML một phần của cây này có thể trông như sau:

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

Dưới đây là một số cột mốc tiềm năng cho bạn:

• Tạo định dạng dữ liệu XML hoặc JSON, sau đó viết chương trình đọc tệp có định dạng đó và hiển thị dưới dạng JTree mà không có bất kỳ hộp tổ hợp nào, chỉ các thư mục và tệp.
• Thêm điều khiển xoay vào màn hình JTree
• Mở rộng chương trình của bạn để viết cùng một tệp
• Tạo giao diện người dùng để người dùng có thể thêm và chỉnh sửa các nút bằng GUI

Đảm bảo lưu bản sao lưu chương trình của bạn mỗi khi chương trình hoạt động vào cuối mỗi cột mốc. Một hệ thống kiểm soát nguồn được cài đặt trên một máy khác là lý tưởng cho việc này. Bạn có thể sử dụng github hoặc sourceforge hoặc một số điều khiển nguồn công khai khác nếu bạn không muốn chia sẻ mã của mình và không muốn thiết lập máy chủ có kiểm soát nguồn trên đó.

Bất kỳ giải pháp nào trong số này là rất nhiều công việc, và chắc chắn lớn hơn một dự án mới bắt đầu. Điều đó có nghĩa là bạn sẽ dành nhiều thời gian hơn để học Java Swing và XML hoặc JSON hơn là chơi LARP của bạn, đó là lý do tại sao lần đầu tiên tôi khám phá các tùy chọn thực hiện với các công cụ hiện có. Nhưng cách tốt nhất để học bất cứ điều gì là cách bạn có động lực nhất để học. Vì vậy, đây có thể là một dự án hoàn hảo cho bạn.

Tôi hy vọng điều đó sẽ giúp.

Tôi không nghĩ JTree là đại diện phù hợp cho vấn đề bạn đang cố gắng giải quyết. Tôi nhìn vào trang web của bạn, và tôi thấy danh sách các thứ. Đây là một khởi đầu tuyệt vời, nhưng tôi nghĩ có một thiết kế dữ liệu cơ bản mà bạn có thể có, nhưng tôi không thấy.

Cuộc sống và sức mạnh trông giống như thuộc tính của tôi. Double, Triple và Quadruple trông giống như các giá trị cho thuộc tính Sức mạnh. Sau đó, tôi thấy các kỹ năng được chia thành Vũ khí và Y tế. Tôi nghĩ về vũ khí là tài sản (mà bạn có thể mua, tìm hoặc thả) và tôi cho rằng kỹ năng là thứ cho phép bạn hiệu quả với một vũ khí nhất định. Nhưng cách tôi nhìn nó, vũ khí và y học không có kỹ năng, nhân vật cũng vậy. Trên thực tế, tôi hoàn toàn nghi ngờ rằng Nhân vật là nhân vật trung tâm trong thiết kế dữ liệu của bạn.

Đây là ba đối tượng dữ liệu nổi bật với tôi từ thiết kế của bạn cho đến nay:

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)

Bây giờ một nhân vật có thể có vũ khí và kỹ năng, nhưng để tấn công thực sự tốt, họ cần một kỹ năng cụ thể cho vũ khí họ đang sử dụng. Trong mọi trường hợp, có nhiều mối quan hệ một-nhiều ở đây (một nhân vật có thể có nhiều kỹ năng). Nhưng tôi chưa thấy cây.

Lấy một tờ giấy và trên trang đầu tiên đặt nhân vật vào giữa trang và liệt kê 5-10 đối tượng trong thế giới trò chơi quan trọng nhất xung quanh nó. Chỉ ra dữ liệu nào chỉ là thuộc tính của một đối tượng khác (chẳng hạn như Cuộc sống và Sức mạnh là những phần không thể tách rời của nhân vật) và mối quan hệ quan trọng nhất giữa các đối tượng, mà không cần suy nghĩ về cây hoặc trường văn bản hoặc hộp tổ hợp. Vẽ các đường giữa các đối tượng để biểu thị các mối quan hệ Sau đó tìm ra mối quan hệ nào là 1: 1, đó là 1: nhiều và nhiều: nhiều và gắn nhãn cho chúng. Có thể có "has-a" và "is-a" và các loại mối quan hệ khác.

Bạn có thể quyết định rằng bạn cần các đại diện riêng cho WeaponSkill so với HealingSkill so với producSkill. Hoặc bạn có thể quyết định chúng giống nhau đến mức chúng thuộc một bảng Skill (trong ví dụ của tôi ở trên) với trường xác định loại kỹ năng đó là gì.

Đó là một dấu hiệu tốt cho thấy bạn không hài lòng với những nỗ lực của mình cho đến nay - điều đó có nghĩa là bạn sẵn sàng xem xét nhiều khả năng trước khi chọn một khả năng. Càng nhiều bản phác thảo bạn xem xét, thiết kế cuối cùng của bạn sẽ tốt hơn. Cuối cùng, cái tốt nhất sẽ trở thành sơ đồ dữ liệu của bạn. Khi điều đó được giải quyết khá tốt, bạn có thể quay lại suy nghĩ về "hộp tổ hợp" hoặc "trường văn bản", nhưng tôi sẽ để các quyết định UI đến cuối cùng.

Thay vì nhìn vào JTrees, tôi sẽ đề nghị bạn xem xét các chủ đề về Cấu trúc dữ liệu, Thiết kế cơ sở dữ liệu và có thể là Mô hình hóa dữ liệu. EDIT-> Hoặc sơ đồ ánh xạ mối quan hệ thực thể tốt hơn như David Kaczynski đề xuất! <-EDIT Nếu bạn thiết kế dữ liệu đúng, thì Java và UI sẽ chuyển từ nó rõ ràng và tự nhiên. Nhưng nếu bạn hiểu sai, thì sẽ không có số lượng Java-kung-fu hay UI-beauty nào khắc phục được.

Chúc may mắn!

Tôi sẽ tập trung vào mô hình đối tượng.

Tôi nghĩ về tính linh hoạt mà bạn muốn, có lẽ bạn muốn tách các lớp của mình thành một kiến ​​thức (có lẽ "định nghĩa" là một từ tốt hơn trong trường hợp này) và một lớp giao dịch. Bằng "lớp" tôi thực sự chỉ có nghĩa là tách chúng ra một cách hợp lý trong đầu bạn. Lớp kiến ​​thức chứa định nghĩa của bạn về cách bố trí cây và dữ liệu trong đó đến từ một nhà thiết kế trò chơi và lớp dữ liệu lưu trữ các lựa chọn cụ thể cho một nhân vật cụ thể.

Trình độ kiến ​​thức của bạn sẽ ít nhất là hơi lộn xộn, bởi vì bạn đang cố gắng tạo ra một trò chơi thú vị hơn là một mô hình toán học sạch sẽ.

Cố gắng tổ chức những gì bạn có cho đến nay, tôi nghĩ rằng bạn có lớp SkillDefDef có thuộc tính Parent thuộc loại SkillDefDef. Bạn cũng có các lớp con SkillDefDef (có thể trở thành các mục trong bảng DEF_SkillType trong cơ sở dữ liệu) để bao quát một vài trường hợp.

"Vũ khí", "Thể chất và tinh thần" và "Y tế" dường như không có gì ngoài một tiêu đề (và kỹ năng trẻ em).

"Một tay", "Sức mạnh" và "Vết thương ràng buộc" dường như có một hộp tổ hợp liên quan (có nghĩa là một cái gì đó giống như bảng DEF_SkillChoice trên cơ sở dữ liệu có khóa ngoại với DEF_Skill). Sword and Bow dường như là một chuỗi do người dùng xác định (vì vậy không có bảng liên quan nào ở cấp độ kiến ​​thức, nhưng dữ liệu sẽ được lưu trữ ở lớp giao dịch).

"Cuộc sống" dường như có một số nguyên liên quan đến nó. Nó có thể không thể chia sẻ lớp này với bất kỳ đặc điểm nào trong tương lai sử dụng số nguyên, bởi vì có hành vi ngụ ý về cách tăng số nguyên. Trong mọi trường hợp, hiện tại nó cần lớp riêng của nó.

"Kiếm", "Cung", "Sức mạnh" và "Vết thương ràng buộc" dường như đều có các cấp độ kỹ năng tiến bộ bên dưới chúng trong cây. Trong trường hợp "Kiếm" và "Cung", những cấp độ đó thực sự gắn liền với kỹ năng làm cha mẹ của chúng. Tôi nghĩ rằng bạn cần một lớp ProgressiveSkillDefDef với bộ sưu tập các giá trị pháp lý được sắp xếp theo thứ tự (bảng DEF_SkillLevel có khóa ngoại đối với DEF_Skill. Ở cấp độ kiến ​​thức, bạn không hoàn toàn rõ ràng về quy tắc nào mà bạn đang lập mô hình. đối với tất cả các loại vũ khí, bạn có thể có bảng DEF_SkillLevel với các bản ghi "thành thạo" và "chuyên môn hóa" có khóa ngoại đối với bản ghi "Vũ khí".

Điều này bao gồm những gì bạn đã biết ở cấp độ kiến ​​thức. Cấp độ giao dịch (có lẽ "cấp độ nhân vật" sẽ là một tên tốt hơn?) Chỉ trỏ đến cấp độ kiến ​​thức phù hợp. Vì vậy, trong ví dụ của bạn, bạn sẽ có một đối tượng Nhân vật với đối tượng Kỹ năng có một bộ kỹ năng - chỉ những đối tượng anh ta thực sự có.

Vì vậy, nhân vật sẽ có một kỹ năng "Thành thạo" có cha mẹ là kỹ năng "kiếm" và có loại là Skill_Level. Trong cơ sở dữ liệu, bản ghi TRANS_SkillDefDef có khóa ngoại đối với bản ghi kỹ năng "kiếm" giao dịch và bản ghi kiến ​​thức DEF_SkillLevel với tên "Thông thạo".

Kỹ năng thành thạo sẽ có một đối tượng chính là kỹ năng "kiếm", thuộc loại Skill_User Named. Trong cơ sở dữ liệu, điều này sẽ không có khóa ngoại đối với cấp độ kiến ​​thức, bởi vì không có gì đặc biệt được định nghĩa cho "thanh kiếm" (đó là tên người dùng). Tuy nhiên, nó cũng có một khóa ngoại đối với hồ sơ giao dịch mẹ, vì vậy có nhiều thông tin hơn có sẵn thông qua nó.

Đối tượng kỹ năng "kiếm" có một đối tượng mẹ là "một tay", bởi vì người dùng đã chọn đưa "kiếm" vào danh mục "một tay". Đây là một đối tượng của loại SkillC Category. Trong cơ sở dữ liệu, nó có khóa ngoại đối với bảng DEF_SkillChoice cho bản ghi "một tay" và không có cha mẹ giao dịch vì tất cả dữ liệu bổ sung cho kỹ năng này được lưu trữ ở cấp độ kiến ​​thức.

Trong việc xây dựng cây ban đầu cho một nhân vật mới, chỉ có mức độ kiến ​​thức cần được truy vấn. Để đưa ra các lựa chọn cho một nhân vật đòi hỏi mức độ giao dịch.

Bạn sẽ cần mã để dịch mô hình đối tượng thành cây và quay lại. Tôi nên rõ ràng, tôi hy vọng, những gì bạn cần làm - mỗi loại ở lớp kiến ​​thức sẽ có một bộ điều khiển liên quan trên cây, để có được dữ liệu phù hợp với loại đó.

Sau này bạn có thể muốn các lớp cho mỗi lựa chọn trong các bản ghi SkillC Category, (nếu "Chuyên môn hóa" có hành vi liên quan đến nó, mã phải đi đâu đó), nhưng bạn chưa cần đến cây này và thiết kế này sẽ tương thích với. Bạn sẽ chỉ cần có một nhà máy sử dụng thông tin mức độ kiến ​​thức để xây dựng đúng đối tượng.

Xét cho cùng, chúng tôi luôn kết thúc việc quản lý các cấu trúc phân cấp - có thể là phân cấp lớp của chương trình hoặc chính chương trình được xây dựng từ các mô-đun khác nhau kết nối bạn với một "thế giới nội bộ" (GUI, kết nối DB, logic nghiệp vụ ràng buộc dữ liệu, v.v.) . Nhưng đây là triết lý, nó nên hoạt động như thế nào trong trường hợp của bạn?

Bạn có các nút trong cây này, mỗi mục là một "thể hiện đối tượng"; trong khi hành vi của chúng (nơi bạn có thể đặt chúng, danh sách các nút con được phép, v.v.) là phổ biến cho một số bộ, như "các lớp". Vâng, đây giống như một mã chương trình. Nếu bạn biết đủ sự phản chiếu của Java, bạn thậm chí có thể sử dụng các lớp POJO và phân cấp kế thừa để xây dựng thành phần này, với một bộ chứa IoC hoặc một cơ chế nhà máy để xây dựng các cá thể thực tế. Nhưng tôi nghĩ bạn không muốn điều đó, vì đó là một vụ hack ngôn ngữ nặng, nên ...

Đầu tiên, tạo một đối tượng "lớp" sẽ mô tả hành vi của các mục. Nó chứa định danh lớp, tên "trường" và các loại và số lượng vật phẩm được phép, v.v. Ví dụ: lớp "gốc" là "Thuộc tính người chơi", có trường "Vật lý / Tâm thần", "Y tế", "Vũ khí". Loại này là "cuối cùng": ngay bây giờ bạn không muốn có các loại người chơi khác nhau. Gợi ý: sau này bạn có thể làm điều đó, sử dụng cùng các công cụ để xử lý "quái vật không phải người" ... :-)

Lĩnh vực "Y tế" là

• "singleton": người chơi không thể có nhiều thông tin "Y tế"
• loại trẻ em là cố định, chỉ có thể sử dụng đối tượng của loại "Y tế" ở đây
• bắt buộc: khi bạn tạo một người chơi, nó phải có trường "Y tế"

Ngược lại: Thành viên vũ khí là không bắt buộc, nó nên được tạo khi vũ khí đầu tiên được thêm vào người chơi của bạn. Điều này có nghĩa là: khi bạn "chỉnh sửa" "đối tượng" của mình (bây giờ là người chơi) và muốn cho phép thêm một mục mới vào nó, bạn không nên giới hạn lựa chọn bởi các thuộc tính thực tế của cá thể (hiện không chứa "Vũ khí" "), Nhưng hiển thị tất cả các trường của định nghĩa lớp và lười biếng tạo trường mới (nút con) khi lần đầu tiên được sử dụng. Điều này sẽ tạo ra một môi trường mở rộng. Sau đó, bạn có thể thêm trường "Bạn bè" với nhiều người chơi ... er ... tham khảo (xem sau).

Thực hiện theo quy trình với các "lớp" thực tế. Nó sẽ giúp bạn tinh chỉnh ý tưởng của mình, như: tốt hơn là tách các loại vũ khí (kiếm, dao găm, cung tên, ...), xử lý đạn bằng cách nào đó (biết rằng có lẽ người chơi KHÔNG có cung nhưng có thể thu thập mũi tên, nhưng sử dụng một số vũ khí yêu cầu và giảm đạn, một số trong số chúng có thể được tìm thấy, một số khác bị mất ...) trong lớp "Vũ khí": dễ khảo sát hơn và cũng hiển thị nếu người chơi của bạn chỉ mang vật phẩm đó hoặc cũng có thể sử dụng nó ( có kỹ năng). Mặt khác: bạn chắc chắn sẽ thay đổi cấu trúc này sau này, khi bạn phát triển trò chơi của mình.

Tạo một "cửa hàng lớp" có sẵn trên toàn cầu mà bạn khởi tạo khi trò chơi của bạn bắt đầu và phục vụ các định nghĩa lớp khi bất kỳ ai nhắc đến tên của họ. Các đối tượng def lớp phải là bất biến trong trường hợp này.

"Đối tượng" dễ dàng hơn: chúng có thể được bắt nguồn từ cùng một lớp gốc có chứa một tham chiếu đến định nghĩa lớp và cũng truy cập chung vào các trường. Có lẽ sử dụng HashMap để chứa những đứa trẻ đó, được xác định bởi tên trường. Hãy nhớ rằng: một số trường chứa một đối tượng, một số khác là một tập hợp các đối tượng. Những trường hợp này là đột biến tất nhiên.

Bây giờ cho giao diện. Trước tiên, bạn nên kiểm tra hướng dẫn của JTree ... , và bây giờ nó sẽ rõ ràng. Mỗi "đối tượng" có thể được biểu thị bằng DefaultMutableTreeNode, "userObject" của nút phải là đối tượng của bạn (tôi nghĩ rằng toString () của nút đó được hiển thị dưới dạng nhãn của nút, nhưng bạn có thể tạo định dạng ô tùy chỉnh). Bất cứ khi nào bạn mở một nút, bạn duyệt các trường của đối tượng và tạo các nút con bên dưới cha mẹ (nếu bạn muốn thực hiện nó một cách linh hoạt) - hoặc duyệt toàn bộ cây và xây dựng cấu trúc TreeNode khi bạn hiển thị JTree (gợi ý: có là một bộ tạo JTree với tham số TreeNode).

Khi bạn chọn một nút trong cây, bạn có đối tượng Object. Theo lớp của nó, bạn có thể hiển thị bảng soạn thảo phù hợp hoặc bảng chung được tạo bởi định nghĩa lớp (như: bảng tab với các trường, trình chỉnh sửa cho trường thực tế bằng khai báo trường: một nút tạo ra một kiểu con đúng of cho phép bạn chọn một trong các lớp khả dụng và các trường soạn thảo cho trường hợp đó, như thuộc tính vũ khí). Sau khi sửa đổi cấu trúc, bạn phải tự làm mới cây - TreeModel và chức năng thay đổi ... là bạn của bạn.

Có vẻ tốt đẹp? Hay quá phức tạp? Vâng, đây là một phần nhỏ của câu chuyện. Tôi chưa nói về

• phân cấp định nghĩa lớp / hoặc phân loại. Bạn nên sử dụng một trong số chúng khi bạn sẽ hỗ trợ thêm các lớp khác nhau vào cùng một trường (như các loại kiếm khác nhau). Một chuyên gia để phân loại: một lớp có thể có nhiều loại, không phải là cây thừa kế cố định, một thứ tốt khi bạn muốn thu thập "tất cả các kỹ năng" của người chơi khi dành XP để cải thiện kỹ năng ... :-)
• hỗ trợ kiên trì: bạn phải tạo một giải pháp chung để lưu trữ phân cấp đối tượng ra bên ngoài, như trong một thuộc tính hoặc tệp JSON. Sử dụng một định dạng có thể đọc được của con người, KHÔNG tuần tự nhị phân, nếu bạn muốn giữ cho bộ não của bạn ở trạng thái tốt.
• lưu trữ thể hiện: bạn sẽ sớm nhận ra rằng "thế giới" của trò chơi của bạn tốt hơn nên được giữ ở một nơi. Một thanh kiếm nhất định KHÔNG phải là tài sản của người chơi của bạn, nhưng là một thực thể trong thế giới trong trò chơi của bạn (người chơi có thể mất nó, ai đó có thể tìm thấy nó, v.v.), vì vậy rất nhiều "đối tượng" trong cây của bạn thực sự là TÀI LIỆU THAM KHẢO (trong khi những người khác, như sức khỏe của người chơi thực sự chỉ là thuộc tính). Bạn sẽ phải tách hai loại, có một bộ lưu trữ toàn cầu cho các trường hợp có thể giải quyết các tham chiếu. Điều này cũng sẽ giúp bạn tiết kiệm khi tuần tự hóa trạng thái trò chơi và nhiều thực thể đề cập đến cùng một thực thể khác (như "Vị trí" của nhiều người chơi đến cùng một ngôi đền).
• (và đề cập đến máy xay não thực sự: sự giống nhau của lưu trữ lớp và lưu trữ cá thể; thực tế là khai báo kiểu có thể là các thể hiện đối tượng giống như các thành phần chương trình, cửa sổ hoạt động, phiên người dùng, v.v ... Đây là vùng đất của những kẻ điên như tôi.)

Dù sao, tôi hy vọng bạn có thể sử dụng một cái gì đó của phiên khởi động này.

Tôi sẽ không cung cấp cho bạn một câu trả lời dài, nhưng tôi đã phải đối mặt với loại tình huống này trước đây và thẳng thắn, tôi đã từ bỏ việc cố gắng sử dụng bất kỳ cấu trúc dữ liệu hiện có. Tôi chỉ đơn giản tạo ra đối tượng của riêng mình có thể chấp nhận cha mẹ và con cái mới tương tự như Nút XML.

Tuy nhiên, trong trường hợp của bạn, tôi nghĩ sử dụng Lớp Xml sẽ giúp ích. Sau đó, bạn có thể có các thuộc tính cho mỗi nút có thể cho bạn biết nếu một lớp là một kỹ năng và bạn có thể dễ dàng có được cha mẹ và con cái của bất kỳ nút nào bạn muốn sử dụng trong hộp tổ hợp hoặc nếu không.

Ngoài ra, tôi muốn thêm bạn không nên chạy theo ý nghĩ có nhiều văn bản / chuỗi. Các trò chơi thường liên quan đến AI và AI thường liên quan đến rất nhiều văn bản.