Okay so my thinking last time was comically faulty.
My thought process was to be able to recycle the second screen within the main screen in a single-screen option. The conclusion I came up with was “let’s do a whole different screen format”.
…at that point why not just rethink the UI itself, though? There’s less cumbersome options.
also need to reaffirm the priorities here: The important part is the two-screen setup, so any adaptation should come after THAT is set in stone.
“Why do two screens?” Why play videogames at all? I’m an indie developer, I can afford to make silly stuff, dare I say it’s expected of the field. The single-screen setup is meant to be an early futureproofing anyways. I’m also more than happy to make stuff PC-only, don’t test me.
The whole process did highlight a couple of things I need to keep in mind later, though.
So let’s take it from the top!
First the commands: Interactions in the game look like this:
So there’s three main commands: Move (change locations), Look (examine the environment), Talk (interact with character), and Options (enter the settings menu).
Logically, each command branches into a sub command.
Let’s start with Move.
Don’t worry about the arrows going off frame, but you get the idea. The point is that each command will become a different configuration by necessity.
As you can see, Move has to then deploy a locations list so when coming up with the design,, that has to be taken into consideration.
Likewise, pressing Look deploys the Look window I briefly teased last time.
“Talk” is where things get kinda tricky because there’s two nested menus instead of just one. You choose who you want to chat with on the scene and then from there you show them what you want them to chime in about. This double-nesting actually made me realize why Phoenix Wright only limited the talkable NPCs to one per scene at a time, since without that selection they can economize a menu for specifying who you’re addressing.
I actually briefly considered having a “Chat” command that would be for generic chatter, but I realized that “Look” can work for that less direct type of interaction.
Here’s one I sorta kinda forgot on the initial draft: A Journal which is just a means to check all the topics and whatnot available for use in the current chapter. The interaction flow is less complicated because it doesn’t really change any state like if you talk with someone and that triggers a flag, for example.
Same with the options.
It’s zoomed out more for illustrative purposes, but the point here is the color coding.
Red means a state, basically the point where the game is waiting for different kinds of input. For example “Command Wait” indicates a state where the game is waiting for the player to do anything with any of the commands.
All the orange tabs will be within the same singular menu, and then yellow indicates forms that that singular menu will take afterwards.
In short, the second screen must have five buttons (three primary, two secondary), and 6 different modes.
Off the top of my head, however… Locations List and Target Selector will probably have the same format. Meanwhile, Ask Menu will probably be Journal Screen but the buttons trigger an interaction instead of deploying a Details screen.
…actually, that’s worth adding.
Numbers shuffle a little, but the point remains.
While we’re at it, let’s graph how the menus would branch off from each other design-wise.
This gives us a clear idea of what to do. Setting aside the edge case of the Look Window, we need to first make a tabbed menu with interactable buttons inside, from there make a tab-less variant, and THEN shift what the buttons do in each context, from triggering an interaction to displaying extra details, to changing the location.
No draft today, just gotta ponder this one.
I’m copying the adjusted to-do list just to keep continuity.
- Draft the UI and player screen. Focus on the two-screen format first.
- Add the mockup into the game.
- Create an option where the “second screen” spawns as either a window or a regular UI element depending on the play mode selected.
The public log also ends here.