UpgradeTreeUsage

Code specifics

Related Classes

UpgradeNode : Contains the data which is specific to a single node. This includes its image path, weapon type, children nodes, position on screen, etc.

UpgradeTree : Contains information relating to the overall tree such as unlocking or getting unlocked weapons and material subtraction from the extractors placed on the map.

UpgradeDisplay : Handles everything relating to drawing the upgrade tree window like drawing sprites, spacing nodes, connecting lines, etc.

How to add or remove nodes

Within the UpgradeDisplay class is the buildTrees function which can be easily modified to change the upgrade tree:

1. Define a desired weapon or tool config and root node(s):

(weapon configs can be found in config/weapons.json)

WeaponConfig katanaConfig = weaponConfigs.GetWeaponConfig(WeaponType.KATANA);
UpgradeNode root = new UpgradeNode(katanaConfig);

2. Add any amount of children to the newly defined root node with the addChild function:

root.addChild(new UpgradeNode(katanaConfig));
root.addChild(new UpgradeNode(katanaConfig));

3. Add the root node to the list of trees:

trees.add(root);

4. Observe the newly created tree in-game:

Note: you must click on the Upgrade Tree UI button to access it

Future Directions

For Sprint 3:

• Line colour changes between locked and unlocked nodes (e.g. green-green for unlocked, red-red for locked).
• Dynamic materials display - currently it only updates when an item is purchased, or the window is reopened.
• Update the window background to be more in line with the Game Design UI goals.
• Upgrade confirmation (e.g. "Would you like to upgrade... Yes/No confirmation"
• Add Ship/Extractor placement or upgrades to the building tree.

For Sprint 4:

• Add or modify new weapons/buildables
• Polish positioning of nodes (towards the end of Sprint 3 new items were added without editing width between nodes).
• General UI polishing.
• Upgrade Tree access button polishing (currently just uses a standard button and Game Design skin).
• Make distinction between trees clearer, potentially by just adding labels "Melee", "Ranged", and "Buildables" above the root nodes.

Changes to plan

Drawing the Upgrade Tree

• During the early stages of design, the upgrade tree was created by manually positioning images within a Group on the screen, with a fixed window background containing the outline of each node. As it became very tedious to position nodes while creating, modifying, and removing nodes, a new data structure was implemented to automatically draw and space nodes on the upgrade tree window.
• A tree data structure was chosen as it can be drawn in an aesthetic manner, and progression for upgrades drawn in a tree is popular in existing game solutions.
• As detailed in code specifics, three root nodes are defined by default (melee, ranged and buildables) but this can be easily extended by simply adding nodes to the root tree. Each root/node can have any amount of children added to it (within reason to the confines of the game window). Additionally, each node is spaced horizontally and vertically in a recursive function - so no more tedious editing of each and every node position in the tree.

TLDR:

• Dynamic spacing: Nodes are drawn and spaced automatically.
• Flexibility: Easy to add, remove and modify nodes without affecting other nodes.
• Scalability: The tree can be easily expanded to add more weapons/buildables if implemented.
• Progression Visualisation: The user is provided with a clear visual of how progression works for weapon/buildables.
• Code readability: Less clutter (all you need to modify is the buildTrees function).

Tree Access

• Initially, the Upgrade Tree was accessed through an Upgrade Bench on the map by interacting with the F key. However, to cater to UX design principles such as ease of use, this access was changed to a UI button which allows the player to upgrade weapons/buildables at any time.

Tree Size

• Initially, there were only a few weapons and a building hammer added to the tree, however, it was discussed with another team that it may be a good addition if buildables were purchased directly from the tree, rather than by upgrading a hammer to indirectly unlock more buildables. Although this makes the tree more visually appealing and increases gameplay depth, it causes an increase in tree nodes. This would not have been an issue if the total amount of nodes on the upgrade tree were static, however many new weapons and buildables were implemented in Sprint 3. Consequently, it became increasingly harder to space nodes without overlap.

Therefore, for Sprint 4 as detailed in future directions, spacing nodes without overlap will be a primary goal in polishing the upgrade tree.

UML Diagram

Note: Interactive, pan and zoom with the buttons located in the bottom right:

classDiagram
    
    UpgradeDisplay --|> Window

    class UpgradeDisplay {
        -WINDOW_WIDTH_SCALE: float
        -WINDOW_HEIGHT_SCALE: float
        -SIZE: float
        -MATERIALS_FORMAT: String
        -inputOverrideComponent: InputOverrideComponent
        -upgradeBench: Entity
        -materialsLabel: Label
        -weaponConfigs: WeaponConfigs
        -player: Entity
        -skin: Skin
        -structureTools: ToolsConfig
        -structurePicker: StructureToolPicker
        -trees: List<UpgradeNode>
        -shapeRenderer: ShapeRenderer
        -nodeYSpacing: float
        -nodeXSpacing: float
        +createUpgradeDisplay(): UpgradeDisplay
        -buildTrees(): void
        -createTitleTable(): Table
        -createUpgradeButtons(): Group
        -createAndPositionNodes(UpgradeNode, float, float, Group, int): void
        -drawBoxBackground(UpgradeNode): void
        -drawLines(UpgradeNode): void
        -setupWindowDimensions(): void
        -createTextureRegionDrawable(String, float): TextureRegionDrawable
        -createExitButton(): Table
        -createMaterialsLabel(): Table
        -createTooltipLabel(Table, String, String): void
        -createTooltip(UpgradeNode): Tooltip<Table>
        -createWeaponTooltip(Table, UpgradeNode): void
        -createToolTooltip(Table, UpgradeNode): void
        -createWeaponButtons(UpgradeNode, float, float): ImageButton
        -createCostButtons(UpgradeNode, ImageButton): TextButton
        -lockItem(UpgradeNode, UpgradeTree, ImageButton): Image
        -equipItem(UpgradeNode): ChangeListener
        -unlockWeapon(UpgradeNode, UpgradeTree, ImageButton, Image, TextButton): ChangeListener
        -handleWeaponUnlocking(UpgradeNode, UpgradeTree, ImageButton, Image, TextButton): void
        -exitUpgradeTree(): void
        +remove(): boolean
        +drawBackground(Batch, float, float, float): void
    }

    class UpgradeNode {
        +getChildren(): List<UpgradeNode>
        +getX(): float
        +getY(): float
        +getDepth(): int
        +getWeaponType(): WeaponType
        +getConfig(): Object
        +getName(): String
        +getNodeCost(): int
        +getParent(): UpgradeNode
    }

    class UpgradeTree {
        +subtractMaterials(int): void
        +isWeaponUnlocked(String): boolean
        +getMaterials(): int
        +unlockWeapon(String): void
    }
    
    class WeaponConfigs {

    }
    class ToolConfigs {

    }
    
    class InventoryComponent {
        +getEquippedWeapons(): ArrayList<WeaponType>
        +replaceSlotWithWeapon(SlotType, WeaponType): void
    }
    
    class Entity {

    }

    class FileLoader {

    }

    UpgradeDisplay "1" o-- "1..*" UpgradeNode: uses
    UpgradeDisplay "*" o-- "1" FileLoader: loads weapon/tool configs
    UpgradeNode "*" o-- "1" UpgradeTree: interacts
    FileLoader "1" o-- "*" WeaponConfigs
    FileLoader "1" o-- "*" ToolConfigs
    UpgradeDisplay "1" *-- "1" Entity: uses
    Entity "*" *-- "1" InventoryComponent: has
    Entity "*" *-- "1" UpgradeTree: has
    Component <|-- InventoryComponent
    Component <|-- UpgradeTree

Loading