I’ve been making slow progress over the last couple of weeks on the ritual UI. To be honest, it’s not the most thrilling of jobs to me! But sometimes you just have to get things done, and it is often useful to work through the design of something when it is difficult to get motivated, as it gives a more clear idea of what we need to do and when it will be done.
Tasks required
Given that the underlying ritual structure is already in place, there are two tasks that are my minimum requirement.
- Display the available rituals
- Provide a method for the player to start a ritual
Inputs and Outputs
I’m a firm believer that there’s always two pieces of information that you need from which you can design a solution to a problem: the inputs and the outputs. Once you know what comes in and what should come out, you can design something that will do that – it might be broken down into smaller pipeline parts and put together – but without a clear understanding of what you want and what you already have, the solution is often not solving the real problem.
The two jobs have different inputs and outputs, however.
- Display
- Input: The game state and the rules about rituals.
- Output: A react component that displays a list of available rituals.
- Start Ritual
- Input: A user interaction with a react component.
- Output: The player action is changed to start the ritual.
These look vague, but they are the accurate enough; part of this design job is to clarify these requirements and turn them into links with the existing system, or
For the rest of this post I’m going to ignore the start ritual part for simplicity.
Dividing Up the Task
For the display task, the input was particularly nebulous – the game state and the game rules, so it might be better to work back from the output in this case.
We know that we can derive a list of available rituals from the game state and rules, and if we had this, displaying it is a much more tangible problem – we just take each thing in the list and display all the relevant parts. So lets add a new task to make that list of rituals, and we have two steps, the second of which is tangible and achievable. In fact we could start that even before we get on with the other parts, if we’re in a multi-developer situation.
However, we don’t have that available. In fact we don’t have any of the rules available; we’ll need to get them. The rules and state are stored in the worker, so we’re in a slightly more complex set of jobs; we need to get the list of available rituals from the worker. In the case as some of the data such as cost or time this data is unlikely to change, so we might want to get that separately.
Now we have a tangible solution! There some work in each of the boxes, including extending the messaging system to send game data, and questions such as when do we transmit the data – ritual data is transmitted as soon as we can, for example, as we only need to send that once at the moment and the client can cache it all, and list of available rituals is sent whenever it changes.
Next Steps
Now I’ve written all this down, I’ve realised that I’ve actually implemented all this already. The next step is to do the same thing for the other direction; this is actually much simpler as the ritual action is already implemented, so it’s just a matter of threading the message through the react interface.
Other than that I think I need to find something I find a bit more inspiring for the next thing to do! I have a reasonably long TODO list so I can find something on that I’m sure.
A micro-review: the flowcharts I made with draw.io: https://www.draw.io/ – which was nice to use for a quick flowchart like this.