MapGenerator should have some sort of mapfile to define GridSpace+Entity combos

[apodgo2]

We already have text files specifying the creation of MicroBlock arrangements in Blocks. (blocks.txt) We also have hardcoded the types of Block arrangements available in GridSpaces. (in MapGenerator) We then have text files specifying the GridSpaces as they're laid out in the world. (map.txt, unused currently)

Considering ticket #17 : I would like the map.txt file to be changed to a blockgridspaces.txt file, which will reflect it's existence as a list of types of GridSpaces made from Blocks. The file would then be loaded in and indexed, and instead of serially loading the GridSpaces into the world as we do now, the MapGenerator could then use said indices to build the map in parts (rooms, corridors, etc). We call it blockgridspaces instead of just GridSpaces since we will also have a tilegridspaces.txt which will have a list of indices for the arrangement of tile prefabs. Creation of GridSpaces would be easier with some sort of external tool, perhaps we should open a ticket for that. For now you can just write them with the text file and keys provided.

These rooms would then be specified in a rooms.txt file, which will have GridSpace indices defined similarly to the current map.txt setup, but there can be multiple rooms loaded in by the map generator. And the map generator would then reference this file to generate the map and would have to foot the work of connecting them all with corridors and etc.

The rooms.txt file should also have the ability to specify the prefab ID's of StationaryEntities per GridSpace. The MapGenerator would ask the MapLoader for an instance of these ID's and assign them to the GridSpaces it'll be generating and registering with the MapGrid. This will allow us to add objects to the world in an easier fashion rather than having to do two mapgen passes with the MapGenerator.

Everything else (for example, starter rooms and objects that show up in ALL maps) can just be hardcoded into the MapGenerator, using a function similar to the current https://github.com/Anedumgottil/VR-Mazmorra/blob/4e57b3e7a823be8a17a6f20c38d1fda3fa115e43/Technodungeon/Assets/Scripts/MapGenerator.cs#L278 function.

---

To-Do list:

• [ ] map.txt changed to blockgridspaces.txt and instead of a linear list of blocks, it defines types of Block layouts in GridSpaces independent of their possible world location

• [x] tilegridspaces.txt created

• [x] MapGenerator updated to load in these GridObject configurations into GridSpace and pools em. This is ticket #17. Would be good to have #16, #15, #23 and #24 done before this.

• [x] Parser in MapLoader created for rooms.txt which loads in GridSpaces using a map view similar to what was described in the #17 ticket at first which said:

  This means we can store the new maps as a matrix that directly corresponds to the GridSpace grid, as ID's that reference individual GridSpaces. And just let the MapGenerator figure out the rest. Which greatly simplifies the map storage/generation from flatfile.

What might be a good idea is that instead of storing ID (indices) of GridSpace types, we could store actual generic GridSpace.GridSpaceType numbers and let the MapGenerator choose whatever type it wants to allow for more interesting map generation as well as easier map file specification by hand. This would require more logic though, and perhaps a file specifying what GridSpaceType each GridSpace is inside the blockgridspaces.txt and tilegridspaces.txt files accordingly.

• [x] rooms.txt flatfile created with some basic rooms defined, with a few StationaryEntities associated with them. Entity pooling and indexing according to ticket #24 needs to be complete by now.

• [x] Modify MapGenerator to get rooms from the MapLoader and then spawn them in according to some sort of algorithm, and then connect them with Corridors as needed.

[apodgo2]

As of ee8dfb8:

Parser in MapLoader created for rooms.txt which loads in GridSpaces using a map view similar to what was described in the #17 ticket at first

Completed. Room Parser untested but implemented to load in an XML file not a flatfile, I'd like to eventually move all of our flatfiles over to XML using a similar parser setup, it simplifies parsing immensely and makes the files more readable if not slightly harder to edit due to verbosity.

The current layout is that the XML file contains Rooms that each contain a possible subelement specifying entity local offset positions in Vector3 floats, their entity names, and a grid position to assign the entity to. They also definitely should contain a self-closing ("empty") element that defines using attributes the grid position of a GridSpace in the Room along with a GridSpaceConfiguration index.

We also store the "actual generic GridSpace.GridSpaceType numbers" a la the ticket inside the Room class, so the MapGenerator knows what type of room tiles to use for this room. Currently we only have one type, so... it's kinda useless, but we're future-proof!

Still need to implement the XML file and test it. Progress...

[apodgo2]

As of e8c18d897752605d524bd3a61cd2f819c9773ea9:

We have everything that has to do with Room definitions and their XML file complete and relatively well tested (still some minor bugs surrounding placement of rooms with un-normalized GS matrices). We even have entirely different tile types being spawned by multiple types of rooms.

The big change was the addition of GridSpace Configuration ID arrays specifiable by XML flatfile which eliminates the need to code them directly into the MapGenerator. This solves a number of issues as well as the second and third steps of this todo.

All we need to do is cleanup the old Block prefabs, convert the Block map.txt into a blockgridspaces.xml and modify the MapGenerator to no longer use the obsoleted Block generation functions.