Groovelet v.82004cf - For Everything (Turn, Turn, Turn)
(32 commits later) Okay, lots of stuff has happened!
———
So, the last time I had screenshots, we were still at the title screen - I hadn’t even got in to what happens when you get PAST the title screen, yet!
Now we have this - a really basic “windows” screen with some placeholder spaces where content might go.
In the bottom-right corner of the screen, I have a Turn Clock.
The rightmost number counts down, all the time, from ~45 seconds. When it hits 0, the server will start processing the player’s turn, taking their inputs, doing magic to them, and spitting out some outputs, starting a new turn at… well, somewhat less than 45 seconds, depending on how long that took to resolve.
It counts down 80 45-second Turns in an hour (representing an in-game day), and then 336 hours (days) in a two-week-period, representing a year. Once it finishes all of those, all three of the timers will read 0 and a TERRIBLE WINTER WILL COME.
I intend for the TERRIBLE WINTER to be when I update the servers with new code, but also it’s going to be the “end” of the game - we’re going to tally up all of the scores, tell players how they did THIS year, and then reset just about everything and force them to start mostly from scratch all over again, except with some legacy elements to attempt to keep people from abandoning the game every winter.
The rest of the UI is… still in development. (I have more ambitious ideas for the design of the turn clock, too, but the name of the game right now is getting something Together, not something Beautiful).
Simple as it is, the Turn Clock means that the Simulation Servers are up and running - it’s currently running Turns, every 45 seconds, for each Game that shows up. (Right now the “turn simulation” is “update the turn clock and do nothing else”, which is not terribly taxing on the servers.) Now the architecture is up to 7 servers - 2 endpoint nodes, 2 simulation nodes, a redis node, a completely unused mongo node, and an openresty node to act as traffic cop/proxy boxing. I haven’t even got to monitoring yet.
————
Okay, once we’ve got past the site’s front matter, it makes sense to do away with the janky CRT screen conceit, I think, for the sake of readability at the very least. Look at how much more screen real estate we have, now!
————
There’s some brief and fruitless experimentation with a flexible and configurable tiling grid-based layout, based on react-grid-layout, but it proves unsatisfying and I think I’m going to put that away and go with a more traditional z-height based windowing system.
For a brief and shining moment, though, I have a tiling window manager. Look upon its brief existence:
Anyways, down a different road: standard windows. They can be dragged around freely, and whenever you interact with one it pops to the top of the z-stack:
Here I spend a little bit of time making it so that the various windows’ metadata about their position and z-stack location are saved, so that the page can be refreshed without losing all of a player’s hard organizing work. Oh, and a feature so that only the window at the top of the stack is “highlighted”.
———
Now, with the windowing system a little more squared away, I start working on the “backpack” a little bit.
This isn’t final UI design so much as it is blocking in layouts and ideas to refine later - but - well, it’s often surprising how much things that we’re intending to throw away later can stick around for a while, so I try not to go TOO horrifying on the first pass.
But the idea is that I can drag these little cards around as gameplay tokens, while showing full card art on bigger panels.
———
I was absolutely terrified at how difficult I figured it was going to be to drag a card from one window to another - the windows themselves being draggable objects. But actually, it turned out to be really easy! I can drag cards from the “Backpack” window into the “Turn” window and it was painless! That was surprising!
I’m actually using two entirely different “drag” libraries here, each one excellent at a different thing. react-draggable is awesome for building a windowing system, free-dragging objects around and just leaving them wherever they land, whereas dragula is an excellent implementation of grabbing objects and moving them between containers - good for decks, cards, and stacks.
I’m always suspicious when things turn out to be painless. Surely things will become frustrating soon.