Hexbgon: Branching Out

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.

Leave a Reply

Your email address will not be published. Required fields are marked *