Clean design ...

I would love to say you a story how awesome my code designing skills are but with time I learned that I still have long way to go. Now we know what this story won't be about and focus on what we will be talking about: My recent issue and how I solved it.


The story taking place in one of many days when I was doing something for project. I was working on content an once again stumble upon problem with editing multiple terrain groups. I knew about it and delayed it already few times but this time it finally blocked me from further progress. This meant only one thing: fixing day arrived. 

"Cool" I thought and started checking what going wrong. Destiny wanted that in meantime of testing some irritating issue surfaced: I was not able to display in inspector properties of World Terrain System. I was trying to select it in hierarchy but only level properties were displayed. 

And this will be topic of my story: How I approached fixing this "trivial" thing.   

Stage 1: Investigation

There are two use cases to display properties inside the inspector: 

Color of nodes are important here because green nodes mean that selected object have EntityID and orange that it uses something different. Following this thought process I quickly checked which objects I could select and turned out that only levels and entities worked. This was some good lead.

In code this two system are supported differently: 

As you see the selecting of Level/Entity in hierarchy windows works different than selecting of systems. When you select the Level/Entity item, UI send SelectObjectEvent to back-end which update the selection. This operations triggers the  SelectionChangedEvent which then processed by UI update hierarchy windows and Inspector. Uff... this was intense but let's continue.

In case of selecting in the hierarchy, the information what properties should be displayed going directly to the inspector. This would be whole story ... except that when you select System/Level you inform back-end that you deselected all entities. As you probably figured out : I using SelectObjectEvent to do that :]

Stage 2: Explanation

We know what happening: 

Turned out that this whole problem was really simple.

Stage 3: Solution 

Finally we got to point where the title of post will be relevant. Figuring out of this particular issue wasn't supper complicated. Fixing it was a little bit different.

Everybody have their own way of handling bugs. I believe that you should always find real source of the issue. This will take more time, will be more challenging if you don't know/remember code you working and may result in bigger changes to fix it. But I still believe that it is worth it. 

In this specific example it is not only important how to fix the issue but also how to prevent more issues with inspector. My conclusion was that whole issue was created by me trying to be smart. I create system that reacted to any changes inside selection. This was done so I didn't miss any of them.

In the reality this turned out fatal. There was so much happening with selection that I missed few cases and lost control over overall system. If you look on graph of interactions between system from second stage it may look easy but it have a lot of this small cases that made whole system tricky to follow.

With this fix I switched to simpler version: 

  1. All interaction with hierarchy inform inspector directly what properties it should display. 
  2. Mouse picking of object from view port also can affect inspector as separate code path.
  3. Updating of selection is done by each operation separately.
I also left SelectionChangedEvent in case that other systems wanted to react on this event. All of this changes resulted in cleaner flow of data that is unified for each of its parts and this is what I can call clean design.


Popular posts from this blog

Hierarchy - UI improvement

Resource Center - High CPU usage

Nvidia - unsigned integer issues