Map Generation

Sprint Two Changes

Sprint two work for map generation focused on the extension of the existing system to handle entity spawning, and a shift from constructing a map via designing rooms to generating a map via random room permutations.

The first step in implementing this change was an extension of the drm syntax to handle entities. This would involve applying similar logic to the TEXTURE section, with DEFINE and PLACE, however instead referring to ENTITIES. To allow for implementation agnostic spawning, entities would be paired with a string representing an "event" that the corresponding GameArea could listen for, at which point the appropriate method could be called. The event could also be provided a selection of values, in the case that the spawning function required additional details.

This implementation slowly resulted in a confusing syntax, as the drm became more complicated to fit the new requirements. As such, the syntax for entity placement was changed to a grid method, allowing for more intuitive placement of entities, while also easing file parsing as the grid could be read and processed more easily. However, as the texture placement still consisted of the use of a list, this new syntax was both confusing to read, and convoluted to parse (the default textures had to be placed in a grid, and the entities were stored in a list). Additionally, the connection between event definitions and a corresponding spawning method was difficult to work with, as it required the connection of a unique event term to a creating method call.

To fix the issues of the modified syntax, an entirely new syntax was created to simplify logic. This new syntax included additional keywords for easy definitions and parsing, and constructed rooms using two grids to define textures and entities separately. Finally, the implementation for the new syntax utilised the Java Reflection API to reconstruct spawning methods exactly from in-file text.

Implementation

Overview

The map generation takes advantage of three classes for the construction process, based on the input from drm files (see DRM Format). The first class is a file reader for the drm files, RoomReader. This class then generates collections of the other two classes, DrmObject and Room, which inform a desired GameArea class of how the map should be created. A conceptual breakdown of these classes is shown below:

Generation Process

The current intended process of room generation follows a three-part process:

1. Extraction of Room objects from specified drm files,

2. Loading of assets required for all rooms,

3. Per-room creation of room terrain tiles and spawning of entities.

Step One

This process involves reading a series of drm files using the RoomReader class. The information extracted from parsing these files is then used to construct corresponding Room objects.

Step Two

As each room contains a series of textures for its tiles and entities, these assets need to be loaded. This may be extended to handle atlases as well. The Room objects are iterated over, adding all necessary assets to the area's asset manager.

Step Three

The Room objects are iterated over once more, handing tile information over to a TerrainFactory for tilemap creation, and then spawning the room's entities at their required positions. Given that the room's tiles and entities can be offset using defined anchor points (see DRM Format), rooms can then be chained together to form the complete area.

For further clarification, this process is abstractly modelled by the following activity diagram:

Usage

The map generation system should be used to create a single GameArea class that can be created with a random layout, provided a set of random room files. The process for map generation will be as follows:

• Create desired number of room fabrications for use in random selection. These rooms may need care taken to ensure compatibility with other designed rooms.
• Selection of acceptable rooms for a specific GameArea class. This will dictate which rooms can be chosen from to generate a level.
• Creation/migration of required entity constructors in the desired GameArea class. This is necessary to ensure that all entities specified in each of an area's rooms can be created and spawned.
• Loading of any assets that are required for the area, barring those defined in the drm files.

After these steps are completed, the desired GameArea can be used.