ATOMIC SPACE NEWS #9: Glowing colors

Demands on my attention outside the project have ramped up this month and will continue to do so, but I’ve still gotten good things done.  I’m going to delve a little into implementation details for some of those things. If your eyes start to glaze over, skip to the bottom and I’ve got something more graphical to show there.

COLOR

One thing I’ve been putting off for a while is taking control of the line colors. When I was first getting a handle on making Unity do my bidding I needed my lines to be distinguished by color but didn’t want the extra work of setting or storing the colors, since I had more important things to worry about. As such, depending on what part of the program you were in, the color of the line was either randomized on load, within certain bounds, or basically a hash of the object’s name. 

Obviously control of the colors is something that’d be desirable to a level designer, so eventually this had to change. Once I got the new level editor working, with its basis in proper reflection-based automatic serialization, then storing/loading fixed colors became a snap. Setting them still was a bit of a task, though. I wanted to do that well the first time, which meant first defining what well is. A big part is being able to set the color by either red-green-blue values or by hue-saturation-value. HSV is a powerful tool for making controlled adjustments in particular directions to a color without knowing the exact RGB values of what you’re looking for. The random colors of old lines were done within a certain range of HSV values for just that reason. But at the same time, representing colors by their RGB values is so ubiquitous and useful that forcing one to use HSV instead would be a stumbling block much of the time.

The level editor has object types(‘editor line’ types) that handle displaying and storing different kinds of data, and now it has one specifically for colors. Generally editor lines only handle a single value, and in a sense this does, but it’s a color value rather than a simple number.

Doing all this made me revisit how numbers are entered into text boxes, and I ended up building a slightly better solution than my last one, which I’m switching other parts of the GUI over to a piece at a time.

NUMBERS

Handling numbers in the Unity GUI system I am using has always been a bit twitchy. Here’s the obvious way to do it, the way that’s suggested in the documentation I found originally.

  • Take the number’s value and convert it to a text string.
  • Feed that text into a function that draws the text box
  • Take the output of that function and try to convert it back into a number.
  • If that conversion works, store the number back in the original variable.

Now this is done for every frame. A positive of this is that it effectively prevents the user from entering invalid characters. If the existing value is “100” and I type in “z” the code is going to try to convert “100z” to a number, not be able to, and next frame just display “100” again.

This would work fine if we were working with just whole numbers with small handfuls of digits, but we’re not. For instance the mass of the sun is 1,989,000,000,000,000,000,000,000,000,000 kilograms (roughly, an accurate measure is going to be both constantly changing and be a lot messier). Scientists and engineers got tired of writing all the zeroes ages ago, and gave us many flavors of notation to compress that down into something reasonable. The one we’re using right now renders that number as 1.989e30. So, you try to type this in to a text box, get as far as “1.” and the . refuses to go in. “1.” either is failing to prase back to a number, or is being read as “1.0”, and then getting spat back out as “1” again before you can get the 9 entered. Annoying.

You decide to be clever, and figure out 1989e27 is the same as 1.989e30, and get to “1989”, but entering that E hits the same problem. Finally, you put in “19890” and keep hitting zeros until the game switches it over to scientific notation, and now you’ve got “1.989e06”. Well, you’re almost there! You put in “1.989e306”, meaning to go delete the six next, and the game gets mad at you for putting in a number that’s too big. Finally you give up and just write it out in notepad and then copy-paste it in.

Similar problems arise if you need to enter in numbers that are less than zero. In the past I’ve sidestepped this, in particular for editing orders in gameplay, by just storing the text lines individually and requiring a button to be pressed to try to parse into their values. That’s no good if you want instant feedback, unfortunately. 

Ultimately, for the colors, I made a new class to hold the data. How it works is it stores both the textual version of the value and the numerical value itself. Changes to the text string are stored, and attempted to be parsed back to the value, but this doesn’t trigger a recreation of the text string. If anything else makes a change to the numerical value directly, then and only then the string gets recreated. This gets instant feedback when editing things that are going to be graphically displayed, but never obliterates the user’s attempt to render text. 

Some similar principles are going to need to be rolled out to order editing in time, though there are some other things that have to happen there. A matter for another time.

VISUALS

The player’s course is drawn with icons representing their maneuvers. However, feedback I’ve gotten on pictures and videos has strongly suggested these icons are easily missed, so I’ve tried redesigning those icons.

Here are the icons used for objects. The right is the generic dot used for everything, and on the left is the sprite for the player’s ship and maneuvers. The bar is to point in the direction of the object. Made perfect sense to me when I made it, but in hindsight I can see how it is not as readable as it could be. So I went back to the drawing board.

Here you see my three attempts to make something recognizably shippy and indicative of direction, while being easily spotted. Ultimately I went with the middle option, the halo makes it easy to find against the glow of the trajectory plots while the wedge still clearly enough indicates a direction. Currently the planets are still using the same fuzzy dot as before, but feedback on that might lead to some arrows being added to it, with care to make it as distinct from the ship as possible. 

And speaking of glow, I’ve finally plugged in some bloom, which along with color setting has brought the game leaps closer to my mental image of it. I’ve made a before/after comparison, using a still from last month’s video.

Before
After

There’s always room for tuning, but I definitely feel like this is in the right ballpark. And if you look closely, you can see that I’ve also added an acceleration cap to the levels at last!

That’s the highlights from this month. Going forward I think I’m on the cusp of reorganizing the GUI entirely, as the current one breaks a lot of my rules for a well laid out interface. You have to cross the whole screen far too often. I’ve got a better handle now on what needs to be on screen than I had at the start, so I think it’s a good time to finally do it.

Leave a Reply