Monday 8th:
So today I have a migraine, and of course it's my own fault. Spent the day doing some tidying and had a long, less rare these days chat with my Dad. The antalgin for the migraine has just kicked in and now I just have pure, lovely but completely debilitating dopemine running through my body (the effect of having a migraine and then not having one).
Essentially I just want to make the current build as clean as possible before I upload it. Going to do the optimization fixes (highlighting and 'UpdateAppearance') and then test the game again from start to the current finish. I'll also spend some time trying to actively find bugs and recording some gameplay.
Not planning on getting much done today, but I'm going to at least engage with the problem a bit. Writing helps:
So currently the 'Highlighting' is handled by the 'Building' script in the update method. It's if/else spaghetti. Definitely not good. Each is casting a ray, and is contextual to having the mouse over/having a relevant tool equipped and so on. Ideally, I want to move all of this out of the update method, with highlighters switching on or off when their state changes.
So, when I mouse onto a new object, we should Highlight it and unHighlight the previous object. Also highlight it when I select it using the Canvas Selector, and unhighlight it when deselected.
We start in 'Controller' where we cast our ray. Switching the Highlighter on would be easy 'hit.gameObject.GetComponent().Highlight;'. Switching it off is another story.
So I need to make a 'GameObject PreviousObject' which records the last GameObject the raycast hit. Then when we cast our ray we say 'if (hit.gameObject != PreviousObject) { 'Highlight the new one, unhighlight the old one and set 'PreviousObject' as the current hit.gameObject' }
Next would be for SelectedBuildings, which would simply be to 'Highlight' the object when selecting and 'unHighlight' when de-selecting and selecting a new one.
Ok I think this is going to work. I haven't written a single line of code today but I think this will do fine and I'll implement it tomorrow when I don't have a migraine.
The other thing is smoothing out the UpdateHumanAppearance, most likely by finding a better way of deleting/instantiating objects (or simply checking if new object is going to be the same as the old one before instantiating it).
Tuesday 8th:
Starting by implementing the plan from yesterday for Highlighting. First part was simple, now to continue translating the awful code from the Building/Item update into better functions. The basic mouse over highlighting is simple, but I will need to go through all the other instances and variations of highlighting/ghosting.
Next is to highlight for Selected Builings. Just Highlight and Unhighlight on selecting and deselecting.
Next one, just going in the order they appear in the Building Update, is Automation Wires when Automation is switched on. Of course, with 3 years of coding experience now, I know to put that in the code where the 'Category' is switched. So, that would go in the Btn that changes Category.
In each case it feels good to delete chunks of code from the Building Update function.
Next one is the Automation Lights. These are the little red/green lights where the Automation Wires attach. These appear at all times and change colour based on their signal. All of the Automation is handled in Update at the moment, so I think if I change that I should do it another time and tackle all of them at once. So, just leaving this here in the update.
Next is to show Automation Wires when highlighting a Building that has them. Same goes for Camera Zones and Teleportation connections. This is just a matter of pasting it into my new 'Highlight' function and reversing it in the 'Unhighlight' function.
Highlight for delete. Just copied it over from the normal Highlight. My 'Building.Highlight' and 'Building.Ghost' has '(Material m)' so I can set it red or green in one function.
Highlight for placing in Container. Again, pretty straight forward. However, the Place function contains all the code for checking if the Container is full or not. This would be helpful to determine whether to give a green or red highlight. Again, don't need to fix that now.
Highlight for placing Human on Station. I have a similar issue here. I would have to move the code that checks if the Station is Occupied in the Update. I think I'm just going to skip this for now. Made a note to see to both this and the Container highlighting (with the possibility that I save it for a much bigger UI update).
Need to see Pointers when using a Transport. So this would be activated whenever the player selects a Building from the menu to build, if it is a matching transport. So if I've just selected a Pipe, show me the Pointers foreach Pipe.
Next I have some code for sorting the colour of the ghost for selected objects in the case that I am trying to move them. So, here in Building Update if Input.GetMouseButton(0) it checks if I am intersecting with any objects and colours appropriately, with some extra code to deal with wall intersections in a different way. This was nice because it would highlight them individually so you could see exactly where it was intersecting, also it looked cool and impressive to me. This should stay in the Update, but as a foreach in the Controller rather than the Building to keep things tidy and I think that might be just a little faster. If it's tough on processing, I can make it only update on big mouse movements or something.
Lastly is the Copy Tool. Very similar deal, however in each case I have the code copied to check for collisions. So, I need to tidy that up and I think I'll give my full attention to tidying that whole section of script.
Then finally for Items, just deleted the highlighting code from the Update there and put it in the new Highlight and Unhightlight functions, and did the same in Controller as I did for Buildings using the same Previous Object.
So for Highlighting, all that's left is to test it. However, I don't feel like it, and I still have to optimize UpdateAppearance. Then I will probably start a new save file to test through the whole thing again and then it's ready to upload.
It's still early but I'm tired, drained and look at that big wall of text for my achievements today. Going to go and play some They Are Billions now. Shut up!
Wednesday 10th:
Today is about optimizing the Human UpdateAppearance script.
I have a feeling that the issue might be deleting and instantiating the mesh, and fixing that will bring the frame rate up drastically.
My first idea is to only delete/instantiate if the object changes. So, before doing the switch, I'll ask 'Is the object in there the same as the one I am instantiating?'. So if HeadStyleObj.name != HeadContainer.GetChild[0].name, delete the old one and instantiate the new one, otherwise move on.
So for each part of the Human, I have to check if there is currently an object there, if so, check its name against the object we're supposed to have, and if it's different then replace it. If there is no object there, I just run the same code to instantiate and colour but without deleting the old one. Pretty tedious and repetitive and not one I can simply copy and paste.
Dammit all I want to do is play They Are Billions... Going to finish this update by Sunday latest and then take a week off to hit that.
Ok got through that slog. Now, I expect a few bugs, but should be fine. The next step for me is to press play and see what happens.
Ok so good news is that I can run the game without errors. The bad news is that if we made any impact on the frame rate, it was negative. Also, I have quite a few things to clean up.
So, the UpdateHuman script needs a lot of improvement. I'll have to look at in detail.
For now, my goal tomorrow is to make it work functionally and fix all the little bugs I see, and get the build out regardless of optimization (because it's still under 60).
Thursday 11th:
Started with a small bug where Building Pointers would all be switched on at start. Update appearance seems to be working fine, even if the improvements are 0/negative.
Wrote out the update notes to be published along with the update.
For some reason the hair and skin colour on their face doesn't update in time with everything else. They have to first do something to trigger another 'UpdateAppearance'. Not sure why. Seems to be something weird about applying materials, as I saw problems earlier with skin materials not being applied properly. I don't think it's my code.
The ones having issue are the Head and Hair, which appear first in my code. I wonder what happens if I shuffle that around a bit? Nothing. It's still the head and the hair that decide not to update their material straight away.
Good news is, after some bug fixing to some terrible mistakes (I was right to not do too much yesterday) the performance HAS drastically improved! The garbage collector spikes are still there but much more sparsely placed. Most of the bugs were to do with objects being instantiated multiple times because of mistakes in the naming (mainly forgetting to update the name of newly instantiated objects to remove the word 'clone' at the end).
Bad news is, I don't know why the materials seem to update a bit late. I really don't think it's my code; I'm probably not supposed to try and change so many materials at once or something. Maybe I'm not supposed to instantiate a prefab and then immediately colour it. Like instantiating the object applies the material after. I can do that for a few things maybe but not everything.
Maybe I could simply have all the materials happen at the end of the script? That might work. Maybe if I put a half second delay or something. Actually, I think since Update Appearance is unavoidably processor heavy, I should make it more intelligent and versatile. So for example we don't need to change everything each time. Maybe subdivide it into 'Update Hair' 'Update Head' etc, each only being called when relevant. So update Hair would only happen when their hair changes, and update Head would only need to happen at start. Perhaps a Hair prefab should contain all the phases of its hair and set them inactive/active, since I think that's better optimization.
I don't understand why it worked before and not now.
Ah, the problem seems to only occur when I am trying to apply a material to a child of an object, rather than the referenced instantiated object. So if an object is newly instantiated, it doesn't seem to want to apply a material to it if I reference it by its parent, it wants to use. In fact, it doesn't seem to delete or do anything properly to items recently instantiated which are referenced in the heirarchy.
This means I can fix it with simple edits to code. But if I'm doing that, I might as well do it properly.
Either way, this is a cosmetic problem and barely effects gameplay. So this week I have a nice safe (non-build-breaking) task to achieve while I sit on the update. Then I'll do my new playthrough from start to finish again before releasing the build.
Friday 12th:
Having huge problems with the Update Appearance. All to do with it not being good at doing anything with the children of newly instantiated objects if I look for them by their place in the heirarchy. Everything else is working fine.
So in this case I'm just going to go back to the old code. No more checking to see if the item is already there and so on. This will be the first thing I address when I get back to it next week.
Ok, update is out!