Basic Windowing (+ February Update)

First,

Why No Bird Poll?!

Because we've been getting tons and tons of requests for owls from y'all ;) Owls always come up in the comments on polls, they're a top choice whenever we casually mention them on Twitter, etc. Well here you go: OWLS!

In the process of making him, we realized that if you give him black eyes, he actually looks more like a tiny hawk or falcon, so the mesh does double duty. We'll need to change the feet a bit for hawk-birb, but that's easy, and then boom! We've got a birb-type, an owl-type, and a falcon-type mesh. That plus texturing gets us a huge range of potential birbs.

February Update

So let's see. I experimented with spherical particles, as a way of getting tumbling poofy-looking feathers. Then I took the UI at the end of last month, and made it WAY better. Then I dug into making a general-purpose options menu (trust me this will pay off in spades over the next year). I started pretty basic, but then someone showed me The Sweeney's intro, and I got super inspired. In the process, I learned that shape tool is god. Anyways, by the end of the month, pause menu is looking swish, and after a brief interlude with some questionable toggles, the options menu looks great too. Then I moved into figuring out mission UI, and by the end, I was pretty happy with this (fake animated in Photoshop to give you an idea) example of how it'll look and work. So looking at that, wow, lots of UI. That's where I am now! The systems are pretty much all in place for a vertical slice, so, next is lots of building out the bits where the player interfaces with those systems. Also lots of figuring out level design, missions, etc!

I also worked a lot on a GDC talk, then GDC was cancelled cus (very reasonable) virus concerns. Woops! But it's cool, GDC is going to put this the talks in the Vault AND put them all up on YouTube, theoretically. So everyone gets to see it, yay!

Oh and I finished The Good Place. God that was good.

Basic Windowing

This is one of those things I always start bullish on, then quickly regret the choice. With Spartan Fist, I set out to make this wildly over-complicated windowing system, that supported multiple windows on top of eachother, logic to let them process or not based on which was on top AND active and... like... here, it looked like this.

And you think, hey, maybe that's not so bad. But it spiraled into this massive management cluster and just...

and then...

It wasn't good, and it never worked right anyways. All of this, just so I could make a stack of windows. Which games shouldn't ever do anyways!

Setting out with SkateBIRD, I began down this same road, until I was like: wait a second. Why not just make it simple, you know? Just assume that if one full-screen window (pause window, options window, the big ones) is up, it closes the others. Boom, done. Now the systems are just more like,

Now the states are all discrete, and very clear. Windows aren't overlapped, they don't have priorities, and there's no weird shown-but-not-shown-because-overlapped states.

You might think that base class looks overly dense, but most windows don't care about almost all of that.

Like here, this is the entire Options menu. That's it. Because there aren't crazy overlapping windows, all the individual windows can be pretty simple, since there's not much state they have to worry about. They're either open, or closed. That's kinda it.

The UIManager is longer, but it's really just a lot of "OpenOptions" functions that are smart enough to close anything else that's up. There's a windows registry system so that it knows what all exists to close. It's smart enough to treat player windows like the combo meter as slightly different, for when we want to not actually hide those during certain full-screen windows - but even those special cases are rare.

The point I'm making here is twofold:

1.) It's worth building out your windowing system early, because if you don't, it'll be a shattered mess. I've already got stubs in there for the tweeing on and off-screen, and it already looks good, and it already functions great, and we're in early times. If you put in the time early, it pays off in much more usable, consistent menus - that actually localize well! Yay!

2.) This DOES NOT MEAN you should over-complicate it. Just because you're starting with your windows, spending a week on the design, etc, doesn't mean you need an overlapping windowing system that supports resizing windows in parallel and etc. Unless your game very specifically needs that, don't do it. It isn't worth the effort. Design a consistent, clean windowing system that meets the needs of your game, and absolutely nothing beyond that. Anything extra will just give you rope to hang yourself with in late development, when the bugs pile up.

To that end, the code-tier this month gets my current windowing system. It won't compile out of the box, you'll need to throw a lot of it out, but hopefully it gives you a handy skeleton for doing this kind of work later. I'm pretty happy with it so far!