GridObject

Introduction

Given the game's pixelated aesthetic and the need to randomly generate the level, it is convenient to spawn tiles and entities per grid point of the map.

Grid objects are not expressed in their own JSON files. A grid object is only usable when part of a Floor or Interior JSON file in any of their ObjectMaps.

Technical Explanation

Conceptual design of the GridObject class

One of the challenges of random generation is that the class describing randomly generated objects has to be generic enough that it can be used for any purpose. The logical conclusion to this was to utilise the existing Factory design pattern and passing a String[] to account for any arguments that could be used, similar to how the main( ) method is called in most programming languages.

The purpose of this class is to condense the spawning of objects to a single character on a grid. This is the superior solution to the old ForestGameArea and TerrainFactory implementations that relied on static GridPoint2 declarations to spawn objects into the world.

Defining a GridObject using JSON deserialization

The GridObject class implements the Json.Serializable interface to allow for de/serialization of GridObject instances.

class

This should be the full name of a static class within the game package.

The name must be full because of the way Java handles Class reflection and unit testing. For example, the class TerrainFactory should be defined as "com.deco2800.game.maps.terrain.TerrainFactory" for a GridObject's class.

The class must be static because of the way Java handles invocation of methods. Using static classes means that no instantiation of classes are needed when invoking methods. There is no downside to this because we are utilizing the Factory design pattern that is typically static.

method

This is the name of a method belonging to the class above. This method should not be overloaded because of the way Java looks for methods by name, and the String[] should be enough to account for any custom configurations.

assets

This is a String[] responsible for any custom configurations that should be passed to the method. It is easiest to conceptualize this as a list of parameters passed to a command (the method).

If you want to edit any of the custom formats specified in the map wiki pages, you should think about whether what you want can be done with this array. Think about how versatile the main( ) function is, given how extensively the pattern is used in all programming languages. Adding to any of the JSON formats may unnecessarily bloat it more than it already is.

It is strongly recommended that if you want to integrate the random generation system with another feature, then you should implement this in the Factory method where you can use Inversion of Control to pass the object to the feature for later in the creation sequence.

Typical JSON file format

{
  class:  // Class that declares the method used for creation
  method: // Method inside the class. This method should not be overloaded
  assets: [
    // String array. Typical creation methods will use the first asset to 
    // create a Texture or Animation RenderComponent, but complex methods
    // can define their own argument parsing. Make sure to apply this here
    // Brackets can be in-lined
  ]
}

Post-deserialization

All assets of a Floor are defined in a GridObject instance. You may get specific assets by calling getAssets( ) with the desired file extension string. This class is required to spawn anything prefabricated into the world.