Leaning on the Hashtable

#PanicRoom Day 101

#100DaysOfGameDev R2D66
#100DaysOfCode R2D66

I was having an issue with using room assignment variables in all my room analyzer for loops. In order for the compiler to recognize certain variables in one eventuality, because not every loop would be invoked on every build, it was requiring me to initialize these variables ahead of time. My problem with this was that I had it set up so that if a room Ac, for example, was not needed on a build then the loop that created it would never get hit and thus I wasn’t going to declare the variables that compose it. The code begged to differ and insisted I set it up anyway just in case it came into being. Arguing with a computer is pointless so I was forced to rethink my strategy here.

This lead me headlong into full loving embrace of my hashtable. Why did I have this wonderfully useful system of data tracking and storage and yet I was still using all these other scattered plebian variables? Gross. I went through all my room analyzers that were built to this point and fully converted all the decrepit standalone variables into their sleek and sexy hashtable counterparts. Sure, it took a little longer to make the inputs but when I was finished I felt I had better code that would easily adapt to the various builds that would be coming its way.

The other thing I was able to accomplish today that made life a little better was a fix on my SplitRoom() method call. The way it stood it was experiencing issues determining proper room heights and Y position stopping points while making a room split. This was all due to the way the algorithm was written and how it was assigning room dimension data. The fix was the same as above, lean on my hashtable for better and more accurate data. This cleared things up and made my references more solid so that manipulating data for individual rooms worked out more accurately. It was kind of a small thing, but then again it wasn’t.