Skip to content

Resource Management

Jump to bottom
Suki Z edited this page Sep 12, 2022 · 85 revisions

Resource Management Overview and Gameplay

The resource management system currently consists of the stone currency and the stone quarry building. It is intended to be a way for the player to manage the construction of buildings in Atlantis Sinks. Stone is the currency used for the purchase of all buildings in the game. It is generated by the stone quarry building.

The player can press the 'B' key to enter building mode. The default building is a defensive wall. Press 'N' to cycle to the next building - the stone quarry. Buildings can be placed with a left click. Clicking and holding allows the player to drag the building into place. Press 'B' when finished to exit build mode. While in build mode, the player can generate 100 stone by clicking on any of their already placed stone quarries. In future, resource collection will be changed to an automatic time-based system instead of manual on-click generation.

Initially, we intended that the player would have three methods of obtaining stone: main character mining the map, enemy drops and a stone mine building. But because the first two methods relied heavily on two other teams, we decided for the MVP we would focus on a Stone Mine Building. Once placed, this stone mine would generate a certain amount of stone per level to aid the player in purchasing other buildings and is intended as an investment.

The Design Process

Inspiration:

In terms of inspiration the main ideas we wanted to explore were: mines built into the wall, mine cart / traintracks, atlantean themes and various lighting ideas.

Aesthetics:

Atlantean Themes:

Fake Height / Pixelation / Isometric Design:

Initial Brainstorm:

As we were initially told that the mines would be built into the cliff faces that would step down per level, the brainstorming had the mines designed into the cliff face.

Low Fidelity Sketches:

Low fidelity too was designed into the cliff and with as much greek influence as we could find just to help find the aesthetic middle ground.

High Fidelity Sketch / Final .jpeg:

Animation

To add an extra layer to the design and functionality of our feature, we thought it was important that small animations were added. We created several frames which depict the minecart entering and exiting the mine, with the minecart emptying upon exit. The torches on either side of the mine also flicker.

Animation basically works on the spritesheet and the TextureAtlas file. So, after loading these assets into the MainGameScreen.java file, an animator in the StructureFactory.java file was created

AnimationRenderComponent bul_animator = new AnimationRenderComponent( ServiceLocator.getResourceService().getAsset("images/anim_demo/res_bul_1.atlas", TextureAtlas.class));

And then animation was added to it,

bul_animator.addAnimation("bul_1", 0.5f, Animation.PlayMode.LOOP);

After which we can just start the animation and it appears as above.

The Programming Process

Classes

InventoryComponent: The InventoryComponent class tracks and manages the player’s inventory. Currently the class stores the amount of gold and stone. This class can be extended for more advanced functionalities in the future such as artefacts etc as well as more generic components for other entities.

ResourceBuilding: The ResourceBuilding class is used to generate and manage resources for the player.

ResourceType: An enumeration that contains different resource types.

UML Diagram

The UML diagram attached below allows us to visualise a clearer overall structure of the relationship between each class:

UML_Diagram_Team5_DECO2800

Resource Management User Testing and Validation

Design Testing:

Resource Management Design User Testing

Functionality Testing:

Functionality testing of the game was conducted in order to identify any errors, bugs or inconsistencies that may affect the user experience adversely. We planned to ask others to look out for any performance issues of the game in the future including:

  • Possible issues in the game interface such as issues with animation or any graphical corruptions.
  • Possible freezes, crashes or any glitches while testing interactive functionalities.
  • Test for areas for any event that may not trigger or gets triggered incorrectly.

JUnit Test

Junit tests were also written to provide an automated test to test the behaviour of the methods inside each class that we have written (Test Class path: source/core/src/test/com/deco2800/game/components/player/InventoryComponentTest.java).

For example, the assertTrue() and assertFalse() methods will check if whether the expected value is true of false, which can be seen in the attached Junit test shown below: when the amount of stone is out of scope, the test will assert a false condition; otherwise the test will assert a true condition.

@Test
void shouldCheckHasStone() {
  InventoryComponent inventory = new InventoryComponent(150, 150);
  assertTrue(inventory.hasStone(100));
  assertFalse(inventory.hasStone(200));
}

Reference List

** Operates Left to Right, Top to Bottom...

Table of Contents

Home

How to Play

Introduction

Game Features

Main Character

Enemies
The Final Boss

Landscape Objects

Shop
Inventory
Achievements
Camera

Crystal

Infrastructure

Audio

User Interfaces Across All Pages
Juicy UI
User Interfaces Buildings
Guidebook
[Resource Management](Resource-Management)
Map
Day and Night Cycle
Unified Grid System (UGS)
Polishing

Game Engine

Getting Started

Entities and Components

Service Locator

Loading Resources

Logging

Unit Testing

Debug Terminal

Input Handling

UI

Animations

Audio

AI

Physics

Game Screens and Areas

Terrain

Concurrency & Threading

Settings

Troubleshooting

MacOS Setup Guide

Clone this wiki locally