Before I start on the building highlight stuff there was one final GUI bug I had to fix. That was the stats panel. This panel showed all the required information to the player. This was stuff like population, money, happiness etc. It's also going to grow to show other game features once I get them done.
This panel was updated once per frame. Which mean, that if I hid it, the object that was updating the panel would throw out nullpointers because the panel was now suddenly missing. I fixed this by only updating the panel when it was visible. Once line of code fixed this, which was a nice change given all my other bug fixing shenanigans.
Once I had that code in place, I could use my previous toggle fix to get this feature working. This is a minor but important bug fix as the stats panel takes up quite a bit of screen real-estate. Having the player able to toggle this off, allows them to see more of the game. This is helpful even in these early stages as the player can see what refugee ships are incoming and gives them a few seconds to decide on a building plan.
Many awesome people who have played my game, told me that the building mechanic was really unclear. Often buildings would be build in seemingly random areas. This is not true of course but it does look that way! To fix this I had to add some highlighting functionality to each building block. At this moment in time I made a simple Unity Halo component and added it to the emptyRoom prefab. This shows a sexy pink halo around empty building blocks. I then had to get this working so that when a player clicked a building block, this sexy pink halo would pop up, indicating this is the block they have selected.
I thought about the best way to do this, and since I intend on having more than one level, eventually, hardcoding this was out of the question. I had to have any emptyRoom game object have this functionality. So I came up with a solution to add all emptyRooms to a list. This list would populate once a level was loaded. Once this was populated, I could check to see if any of the blocks were selected. If they were and the player clicked another block, the previous selected one would deactivate its halo and the new one would be activated.
In more detail, all blocks deactivate their halos when a player clicks on a block. After all rooms hide their halo, the current selected block activates his one. If the user clicks on another, the list is iterated over again, to hide any active halos, then the new clicked on is highlighted. You get the point.
A bug cropped up with this functionality. I was getting a nullpointer every time I tried to add a building block to the list. I couldn't figure this out and I knew that the cause was a simple one. I just couldn't place my finger on it. I read through my code and everything made sense. So I did something I never do, I asked for help! I posted on the Unity forums and the kind people there gave me a helping hand. It was just as I thought a simple issue, I just didn't see it as I was staring at code for christ knows how many hours. One of the draw backs to being a solo code monkey, the most valuable thing you can have is another set of eyes. Which, apart from my glasses I don't have!
Anyhow the bug was being caused because the building blocks were being initialized before the list was. Even though I initialized both in their relevant classes in the Start() method, the blocks were still first. To fix this I added the list initialization into an Awake() method and it worked like a charm.
I need to read up more on Monobehaviour as when I started using Unity the tutorials said I always had to place my scripts in some kind of game object, even and empty one, for them to fire off. But after what the guys on the forum said yesterday there might be a way to execute things without messing around with the inspector. This would be a great help as I have a few classes that just need to be running constantly (the manager classes). I think this would also give me more control over what is being run and when. I need more control! D:
After fixing that annoying bugs all seems to be working neat but there's a new problem. If you are awesome and read my previous Ludum Dare posts you know that I destroy Building Blocks and instantiate a new building in the same spot. Because of this, the current halo code breaks. This is because the list, which contains a bunch of emptyRoom objects, is tampered with when a player builds a building.
The previous list entry for a building block will become Null when a player builds a building in that blocks space as it gets destroyed. The list then tries to access a halo component on an object that no longer exists and presto, nullpointer. I'll fix this today as I just have to ensure that null values are ignored. If the player has a building there, I know they won't be able to build a new building in that spot. So there's no need to show a select halo.
That being said, I learnt from my previous mistake and need to think long term. I am toying with the idea of adding building upgrades. If I do this, then I will need to be able to highlight all buildings and not just the emptyRoom building blocks. If I do go ahead with this idea, I need to be careful about how I fix this bug. I'll look into things more today after I get home from work.
So a quick recap of bugs fixed over the week end:
- Fixed the toggle panel bug (properly this time)
- Fixed the stats panel update bug
- Added building block highlights (fixed a bug but still buggy at the moment)
Once I get done with the highlight bug fixes, I'll be able to fix my stat numbers bug. Thank christ this is a numbers bug. Numbers never hide, follow strange Start() logic or lie! Numbers never lie!
Thanks for reading people :D
Rob
No comments:
Post a Comment