Fighting My Own Algorithms

In my long (two day) journey to get a procedurally generated map working, I was bombarded with issues. Things like framerates so low that inputs were taking actual minutes to register, missing two walls in every single structure, repeated index out of bounds errors in different areas of my code, and general extra slowdowns because nothing I tried for debugging actually worked as expected. This was a rough mechanic to work on, and it felt like the engine and my own code were teaming up to try to defeat me.

There were many oversights and other things that I struggled to find or fix. In many places, I was confused on whether or not I should subtract 1 from values used in for loops, and/or change number comparisons to be inclusive or not. Finding this out helped me get one wall back in every structure. I then realized that I wasn't properly handling failures in my generation, so there were structures that were overwriting each other. Fixing that led me to another problem, which was structures that were too small to count as structures were being placed, resulting in massive clusters of solid wall (with maybe one or two holes in them). After fixing that I realized there were some structures that had no openings to go through, resulting in open space that was inaccessible. Fixing that led me to the solution to getting every structure to be covered by all four walls (and this drastically reduced the amount of openings that were spawning). 

What started out as a weird, almost spaceship-like design generation turned into an actual way to generate connected rooms. Next problems to think about are lighting and traversing between different floors, which would require me to go over the grid with another algorithm to "clean up" and add things to make it more normal. Throughout this entire debugging process, I realized that setting breakpoints in code was absolutely useless because memory addresses were being recycled and "optimized out" whenever I tried to step through them, meaning that every variable I tried to watch was unreliable at best and unavailable at worst. I had to wait for an actual error to happen to even have a clue what values were going where.

Now that I'm done talking about the past, I have to discuss my plans for that second algorithm. This time instead of generating numbers and setting up a grid, I will just have to loop over an already generated map and find suitable places for things like light sources, staircases, and whatever other environmental objects we can find that may or may not be considered during map generation (like the shop station). This should be a lot easier than what I just spent two whole days doing, since it's just a matter of looking for specific patterns and formations in the already generated area. The only problem is I have to decide how I want to represent staircases and light sources with my already created systems.

Currently every unit on the grid has an actor called a GridNode spawned on it (excpet for empty spaces, in which case the actor is swiftly destroyed). This GridNode class only supports one unit objects, so light sources could work really well with it. The problem would be staircases, which would require two adjacent spaces minimum to work. I would have to either find a way to make two GridNodes aware of each other and combine into one structure or I would have to create an entirely new structure to represent a staircase. One option I can think of is simply setting two different markers on the grid and have the GridNodes be perfectly aligned to match these markers, but the feasability of that option would depend on both how little the engine would fight me on that and if I would be willing to sit down and seriously consider how to handle the direction of each staircase. Something else (like UI) might be higher priority than this at the moment.