This past weekend I played around with Project Universe a bit, trying to get the station UI up to speed. A speed. Not THE speed, the speed that the UI will be at once I have an actual aesthetic to apply to it. Right now, I just want to get it working.
The overall design hasn’t changed a lot. When you (the player) are in range of a station, you’ll be able to”dock” and you’ll see the main station services menu. From there you can visit the different amenities that the station has to offer. One of those is the commodity market, which is a freelancer’s venue for buying items which have little to no purpose elsewhere in the game except to give you something to buy for cheap and sell for (hopefully) less cheap.
Unlike last iteration, I am trying a grid approach. The keys to the display, really, are the quantity, the price, and some indication whether the station buys or sells the item (no station will do both for a specific item). The good thing about this is that the view port is more compact than a list of horizontal data because the item is nothing but an icon, an image, the price, and the quantity. To get further details, you’d click on the item in the grid to have it bring up info on the right hand side. There’d be a name, a description, and a way for you to add quantity to your hold, or if you have that item in your hold, to move it to the station (note to self…need an indicator on the grid item to display if you have that item in your hold!). All of this was fairly simple to set up, considering this is the third iteration of this exact system I’ve done for this project now, although some parts (price calc, buy or sell, quantity in hold) aren’t in place.
What took some time was setting up a hierarchy of windows so that the player could close them all at once, or one at a time. Since the window displays in a hierarchical manner, it stands to reason that the player should close the windows in a LIFO manner: last in, first out. The Esc key is the traditional vehicle for a keyboard-based game when closing windows, so I had to wire that key to close just the most recently opened window. Press it again, and it closes the previous window. And if there’s any other windows open after that, close each in the reverse order in which they were opened. Technically, this will rarely (probably never) go more than two Esc presses deep before the player is “undocked”, but the manager does pretty well and should allow the system to handle closing windows one by one. Yes, there will be a manual button on each window to close just that window, but there’s a design decision that needs to be made as part of that, like where the button will be and what it’ll look like, and I’m not at that point quite yet.
One issue that I ran into was the locking of the mouse when flying. There’s three ways to go about movement when dealing with mouse and keyboard. The first is to go all keyboard. The second is to go all mouse. The third is a hybrid. I had originally used the all keyboard method, but that gets kind of awkward for slight maneuvers like when you need to line up with a target or other object and are using the movement script I have currently. Using the mouse works better in that regard, but it also requires me to lock the mouse in “mouselook” mode, where movement of the mouse controls pitch (nose up and down) and yaw (nose side to side). In this mode, there’s no mouse pointer to use in clicking on things like the “Dock” button that turns green when you’re within docking distance, or to use on the station menu when you’ve docked. You’ll need to exit mouselook mode in order to get the pointer back, and while that’s not exactly a foreign concept in games, I’m not sure I like it. The plan I have is to automatically turn off mouselook while the player is docked, and re-enable it when the player undocks. And in order to dock or interact with anything in the world, the player can use the now-becoming-ubiquitous “F” key to interact.
All of this has lead me to think about controller support, which I plan on doing, because this kind of game begs for controller support. I’m just not sure what kind of inputs I’m going to end up needing, so I can’t fully commit to creating controller support with that information.