Wow.

I have been thinking of starting a dev journal here for a few years. Obviously never got around to it. Now I wonder why I waited so long! Wow. I really appreciate all the resources and tools we have to do this now that I'm doing it.

It makes the most sense for my little journal to be about what I actually do, so for now it will focus mostly on tool development. This is my job (though it is not for games) as well as the stage I am at in working on the usual hobby-side-project-dream-game, so it will fit the bill perfectly. With that said, let us address something right quick:

Tools development is hard.

Yes, game development is hard. It requires one to have a handle on many disciplines, even if they primarily focus in one area. But how often do we think about the tool developer? It is no secret that the quality of your tools can make or break the development cycle. It is an engineering challenge in its own rite. The better the tool is designed, the less its user notices it, and the more they can focus on producing content or whatever it is intended to do. Even if one is overly happy with their tool of choice at first and is all gaga about it (is that phrase still legal?), eventually their mind will be on using it - not working around it.

Not only that, but as programmers we tend to be lazy and unfair. We want our tools to read our mind so that a single click and maybe a drag always does what we are thinking. We then want our tools to read our mind again so that a single click and maybe a drag does the completely different thing we are now thinking. If we have to, we'll tell it "no, not that, read my mind again" by attempting a keyboard modifier such as alt or ctrl. If this fails, naturally the tool is "stupid" or "broken" (in other words we probably didn't read the manual).

And then, when we programmers decide we want to tweak some oddball parameter all of a sudden because we are just so clever, the tool that automatically reads our mind must stop and let us very specifically tell it what to do. But it should be very easy to do that.

And don't get me started on how we all are so certain of "how it should look". The feel of a tool actually does make a big difference. From the color scheme to the organization of the UI, the last thing you want is for it to interfere with someone's thought process and creativity. And speaking of UI - the workflow of a tool usually takes many iterations to get right. Even when you get it working "bug-free" after many days or weeks or months (or years!), you may discover there is a far better way. Often, this can't be seen until you've finished the previous iteration and spent a great deal of time with it.

Sounds a lot like game development doesn't it?

Don't forget the tools devs.

One must practically have a degree in both engineering and psychology! Often unnoticed until something is broken, a good tools developer is a very important asset to your team. Be their friend

This journal

So, that wraps up my first attempt at this, for better or worse. Following entries will probably be a bit random, but they will simply cover details of tools programming. For now, I have in mind to write about various aspects of tools that are tricky to design and tricky to implement, and present one or more possible solutions.

These types of things don't really get talked about often, and perhaps sharing them can help someone else. I hope it will also be beneficial to myself to write these things out, as I usually have much trouble organizing my thoughts.

A screenshot

It just wouldn't be right to start a journal without posting a screenshot of ... you know ... something.
Often I will use the development of this software as a source of journal material.