Hey Everyone! Tom and Tony are at a family reunion, so Albert and I are holding down the fort with terrain generation and crafting, respectively. In the spirit of Desktop Tuesday, here’s a screen-cap of the in-flight carpenter UI, as it looks right now, in my test world:
For those of you who follow our livestream, this may look familiar! Tom showed off his design in Photoshop some time ago, but now both UI and features are coded up and (mostly) working. You’ve got general info at the top, recipes on the left, details in the middle, and the current working orders in a drag/drop sortable list on the right. The crafter (carpenter in this case, but the functions are re-usable for all crafters) evaluates the orders you put in his queue from top to bottom, working on the first order he has materials for until he’s either blocked or finished. You can pause his crafting to free him up to do other things (he’s paused in the screenshots) or delete items from his list by dragging them into the general vicinity of the trashcan:
One thing I’ve learned after 10 years in software development is that because the UI is often the public face of a feature, it’s often not until you design a screen that you realize the full scope of your work: how many things are necessary not just to make the feature functional, but also easy to use. For example, when I started on the crafter, I knew we’d have two types of orders: “make now” and “maintain N”. I knew the player should be able to change the order of the queue and delete orders that were in flight. But it wasn’t until we drew out the screens that I realized we’d also need to budget time for pausing work and reporting status. Both of these features improve usability, but they have implications not just on the UI but the whole functional stack underneath.
The good news, at least, is that though the UI you see is specific to carpenter, it’s coded to be generic to all crafters. With a different set of recipes (passed in via metadata, of course) our other professions should be good to go.