Editor tabbing

Last week I was done with the restructuring. And I added some new graphics to the layout. We discovered that the graphics we had caused a problem with the professional version of Unity and because of that we needed to fix the graphics. So I made the graphics for it, even if it isn’t the final graphics.

This week I decided to start with a task I have been putting on hold for the longest time. Tabbing between fields. I did the task earlier, but did not find a good way to go about this. The reason being that Unity if you are using [ExecuteInEditMode] or want input while in edit mode you cannot use the standard Unity input methods. So for instance Input.GetKeyDown() won’t work. Instead what you need to do is to use the Event.current.keyCode. The problem is that it doesn’t check if the key is down for the first time or not. Instead what you need to do is to check Event.current.type and check if the event is EventType.KeyDown. However when I tried this the first time I did not know about the Event.current.type.

So the first attempt of doing this a while back, I tried to implement my own KeyDown, but it reacted to all events so the previous event and current event would always update on mousemove etc. Basically what I did in the first attempt was to check if the previous event was tab or if it wasn’t. But the thing was that in Unity an event is even mouse move and OnGUI updates on focus and with the events, so when tabbing 2 events would be created and it always skipped a field.

The new version I found the keydown and that made it much simpler. I didn’t need to check for the previous event and thus I could just do:
if (Event.current.keyCode == KeyCode.Tab && Event.current.type == EventType.KeyDown)
This does basically the same as Input.GetKeyDown(KeyCode.Tab).

Another problem was getting the Shift modifier to go backwards, so I needed to add if (Event.current.shift) and put the previous element method in there and add else and put the next into that. And it was done.

Another philosophy I adopted was to make the class be as flexible as possible, so that I could reuse the class at some point without having to do too much modification. Ideally I should try to make it so that I can use it without modification at all, but I found out that I couldn’t do that unless I wanted to complicate the class even more.

I wanted to share the code here, but after having written all of this I don’t think that’s productive. If anyone requests it though I will put the code up here.

Next update will probably be sometime next year.

Achievement #2

Last week I started looking at the flow of the system how it was then and how I wanted it to be. Plans are one thing, implementing the plan is another.

The initial dataflow:

What I wanted to accomplish:

The problem with redesign is that there are always some parts of the system that is overlooked in the planning phase. For instance we are using a pattern called MVC, Model – View – Controller. Which means that the model is the data model. View is the user interface and the controller is the logic. What I wanted was to have the view, namely the editor, since that is the view, to be the part that updates the user. The controller would be in turn the one that has all the logic in it. The model would just be the data that the view and controller needs.

The editor as explained is the view, and that was very tightly knit with the controller, which is to be expected. What I had forgotten about when writing the data flow change was that the controller contains a lot of data that the back-end needs. I had 2 choices make everything in the achievement window an event, which means that some logic have to be implemented in the editor code or just fix the button clicks and rather have the editor fetch the data without events from the controller. Which is the solution I went for.

The other option is to create events for everything, but that would mean that every drop down menu, every selection and every choice would create an event and in my head that is not a good way to do it. The way I implemented the fix, the controller still does its magic and the button clicks just updates the background data and provides the information, so you keep the logic within the controller with the event calls.

The planned change was a success, in that the changes worked and seemingly seems to work a little bit faster. I got rid of 4 classes and implemented 1 new class. The one class handles events from the window and the other controllers in the system subscribes to the events based on the buttons they belong to. This makes it easier I believe to expand the system if we need to do that in the future. The data flow looked like this in the end:

Not exactly as I had thought from the start, but close enough. The controller for the editor still has a connection with the other controllers, but it only gets the data and doesn’t modify or change it. The controllers themselves are in charge of organizing their own data.

The little box to the left was the deleted classes. The event system is the big box in the middle which triggers logic in the editor controller, as well as the three classes that the achievement system consists of. There is still a connection between the editors logic and the logic of the rest of the achievement system.

If I had been part of the project from the start and knew then what I now know, I think it would be better to see if you could make the classes more self containable, but right now I think the solution I came up with was nice. The system seems to respond better and we seem to have gotten control over the data flow. Now we know that a button click invokes the subscribing classes. The classes are updated and it is much easier to follow the flow of the program.

In the process I also got rid of 2 singletons. Earlier I thought that if you only needed one copy of a class you make it into a singleton. I have lately discovered that it is not the case. Even if you need it only once you create it when you need it and let the garbage collector fetch the trash once it is used. Which is a better solution. You don’t have to reset the variables every time you use it and it doesn’t take up space in memory. Sure the memory it consumes might not be much, but there’s no point in locking memory you don’t need used, especially when the tool is a back end tool and you don’t need to use it during run-time.

Next blog will most likely be about how to tab between fields in the editor. I have tried to get that working before, without success, but that was before I discovered why it didn’t work. Now I know why and I have an idea how to get it to work as it should.

Achievement unlocked!

The last couple of months I’ve been working on an achievement system. The goal is to sell the asset on the Unity store. There are already a few of them out there, but what we offer, we consider unique. But no development goes without a hitch and right now I’m in the middle of the biggest one. Ok, that’s a lie, it’s a big structural change in the code, that’s all, but biggest hitch sounds better 😛 .

The system itself is fairly straight forward, you have a front-end, where the developer can enter data and you have a back-end, which stores the data. This part is fairly simple, but as we’re closing in on testing, I wanted to go through the code, look at re-usability and data flow. The re-usability part for this project I would say is okay. There’s a parser that can be modified and be re-used. There’s a couple of other classes that are used as  data models, that also can be re-used. Other than that there’s nothing we can truly re-use. But for this project, I consider that fine. Then I started looking at the data flow. From the image below, you can see the arrows are going pretty much all over the place:

Now I haven’t been working on this from the start, so a lot of the data and how it flows was not my design, but looking at that, I found out I needed to change the code. The question is how to do it. I don’t want to give away too much, like I said this is something that we want to sell on the Unity store, but what I can say is that to communicate with the back-end, we use event calls. The problem that I see with this way is that I don’t want to have events when the back-end updates or otherwise utilize data. I want to have events on buttons that I click in the UI, but when getting data.

In this case, events are not used when clicking the UI directly, but rather have events attached to one class that calls another class that triggers the events. I’ve already removed one class that was between there too. So at first it was: Button click -> Class method -> another class method -> a third class method that triggered the event.

What I want to accomplish now is: Button Click – trigger Event. The affected methods that subscribe would then do what they needed to do. The hitch is that I need to plan the system over. Removing a lot old code, but in the end, I think it will be much simpler. Going from the scheme above to:

At least on paper this looks better. I will probably go through and re-iterate this at some point, but there is a point where changes don’t contribute that much. Now all there is left is to put theory into practice. Just a quick note about the picture. To the left is a box with 3 classes that I will get rid of, that I don’t believe I need anymore. To the right in the box there are 3 classes that are only supposed to be used during run-time, where one of them is a singleton template object, so it’s just used for inheritance. Then the bigger box is the event class that I want to utilize. Basically in the form I have planned in my head it is only supposed to be the events. The buttons will effectively call those events and the subscribing classes should execute their methods, depending on the event call.

This will be a first time for me trying to plan code based on a system that has already been created and re-iterating to get it better. I have re-iterated stuff before, but those times I’ve never really planned, because most of the time the re-iteration has been small chunks at a time. Now all that remains is to get the event system to work as I want it to. Once it does, the system should, I hope, have 3 more classes that are re-usable for other projects as well.