So I finally tried, the other day, to revamp the code. I reverted to a previous version of the code, then was having compile problems. So I updated to the latest version of Unity which still caused problems. In fact, now my error messages were blank!
So I tried to figure out what was going on. No luck for like a week. Then I fired it up again for shits and giggles to see if I could figure it out and my AV popped up – it was blocking Mono. AHA! I whitelisted and BAM! It worked.
Kind of annoying, since I don’t recall receiving any message previously when it was happening.
My original goal was to revert to the previous version and then rewrite the core.
Alas, apparently my last pushed code (before branching code with powerups) was in May (WTF?). It seems that some features are missing in that code, which sucks. So the question then is how far back am I going with this? Do I want to go back so far to reimplement a core or do I just use the latest and greatest and scrap a bunch of work and then rebuild it? Either way I’m at a point where I wasn’t expecting to start the refactor, and it’s like the bears in goldilocks – too early or too late compared to where I was expecting the code to be statuswise.
So – I decided to scrap the code I started (well not scrap, but branch). Revert to the mainline of the code (my first time doing a git branch – super easy in sourcetree :)). When I looked at the code I was trying to get working I just got flustered/annoyed at the mess it had become, and after looking at my code in the main branch of the repo which was much cleaner, I decided to revert (after some prodding from a friend). I branched it so I have some record of the old code (the undo stuff worked, so I know I can integrate that). My goal now is to refactor a bunch of it before adding features. It’s clean enough that refactoring should be a little easier at this point than if I were to add more.
My main concern is editing the levels via changing the text properties in the level editor and having that reflected in the code. Previously I had a text element in the GUI and that would pull up the value of the hexagon object when the game was run. To help me understand, I would also set the text element in the editor so I could see what the game looked like before playing it. However, that’s wasteful. Typing a value 2x is dumb. I wanted to have it pull it in automatically in the editor without having to run the scene, but that’s a whole other level of programming that I don’t care to learn. What I think I’m going to do is the reverse of my original. Set the gui Text value, and then when loading the game, load the hexagons value from there. Or… Just scrap the “hexagon value” and use only the text value of the gui. I don’t like that as much, because it means I’d have to get the child component (gui text) that’s attached to the hexagon and then get the value from that instead of from the hex itself, it’s one more level of indirection.
Frankly all of it is dumb and I should be able to just point the value of the guitext to the value of the hexagon in the editor and have it reflect any changes. But I think it’s how Unity loads resources.
The next thing is figuring out how scan the hexagons for movement. I think I’ll have to refactor how I implement the hexagon locations and where the bee location is in z-space. I’ll have to look at that some more. It’s ridiculous that I should have to do that. The main issue is how I scan to see if something is available as a spot to move. That’s what I really need to deal with – rethink my approach on that, make it more generic.