blaxun / random-dungeon-generator-gms-2.3 Goto Github PK

Right now auto-walls will only be added to the direct sides of Hallways, ChamberGround and open Connectors. However corners (top-left, top-right, bottom-left, bottom-right) are never closed.

The idea is to add another flag to control if corners should be closed.

Right now the complete chamber will be output when used in a dungeon. However, some chambers have a layout where part of it only make sense if the connector on that part is actually used. Maybe there is a way to use color-coding to detect those areas.

These areas would then only be drawn if a connector inside it has established a connection.

Right now the same ChamberPreset could be used repeatedly to create dungeons. I think it would be a good idea to prevent this. Maybe add this as an option

For the system to work a padding is required!
Each side of a chamber preset needs a individual padding that is based on the maximum dimension of all connectors available on that side.

Example:

Right side has 3 connectors.
Connector #1 - 2 Pixel height
Connector #2 - 4 Pixel height
Connector #3 - 5 Pixel height

Conclusion -> Right side needs Padding of 5.
With a padding of 5 the hallway can be created.

For this to work we'll have to get rid of the padding that can be set in the GeneratorOptions.
This change will also affect how the maximum grid size on the RandomDungeonGenerator is calculated

It would be extremely helpful if a ColorMeaning for "Wall" would exist. I'd like to set a switch such as "addWalls" on the Options and would then expect the final dungeon do have walls around its hallways and chambers.

This should be pretty easy to implement by looping all cells once everything was placed

When the dungeonPreset is being populated we already decide on conenctors to use. Store that information somewhere and once the populating is done the hallways should be created.

For this to work the required padding has to be added first

Right now the system can only create dungeons that use chambers that are chained together. Meaning a chamber must have at least two sides with connectors. For some use cases we actually want to have room such as rooms with a treasure chest which would only have a single entry.

The current system should be enhanced to allow for such rooms (branching!?)

Find a way to get rid of memory allocation problems.
Maybe perform chunking on grids or only use parts of a grid at a time.

Maybe get rid of the pixel grid and only use the ColorMeaning-Grid.

Where could I replaced the pixel grid?

ChamberPreset
DungeonPreset

In the end all that should matter is the ds_grid with coordinates anyway.

It would be nice if there could be chambers that only get used a set amount of times.
This could enable stuff like rare chambers. Maybe a way to apply limits on chambers?

Implement a system where users can add custom colors with metadata. This would allow for stuff such as teleporters, chests or whatever the person wants. Maybe even add this as a new layer on top of the metadata map?

Right now the system uses its own variables... but these get lost when moving the ds map to another project. By allowing for the user to defined the values to be placed in the final grid it would make the system more robust to use as end-user

I loved to unified identifiers on ColorAssignments. This might not be needed anymore.

Right now the created dungeon in the demo-showcase is only drawn on a pixel-level. It would be nice if there was a way to show users what a dungeon would look like whne you can actually walk trhough it.

Maybe it’s possible to allow for users to assign a callback function that would be called when dungeon generating is done.

Only exporting the ds_grid with ColorMeanings would be quite limited.
There should also be a ds_list with PlacedChambers, their index and position on the grid that should be exported in some way.