13 lines
1.6 KiB
Plaintext
13 lines
1.6 KiB
Plaintext
Implementation Clarification Q&A:
|
|
---------------------------------
|
|
1. Should the app keep full room geometry internally and show a cleaner simplified map visually, or do you want the visible map to be as literal as the paper layout?
|
|
2. Do you want to support player-entered/manual dice at all, or should MVP stay fully automated with only a roll log?
|
|
3. For in-app presentation, should we favor short flavor snippets plus structured effects, rather than reproducing long room text from the books?
|
|
4. Do you want lightweight debug/recovery tools planned from the start for blocked generation states, or should we keep the production flow completely clean and handle edge-case recovery only in code/tests?
|
|
|
|
1. Let's opt for configurable, but default to clean map visually with the geometry tracked internally. This allows us to have a more user-friendly interface while still maintaining the necessary data for game mechanics.
|
|
2. For MVP, let's keep it fully automated with only a roll log. This will simplify the initial development and allow us to focus on core features. We can consider adding manual dice input in future updates based on user feedback.
|
|
3. Let's favor short flavor snippets plus structured effects for in-app presentation. This will make the content more digestible and engaging for players, while still conveying the necessary information effectively.
|
|
4. Let's plan for lightweight debug/recovery tools from the start. This will help us quickly identify and resolve any issues that arise during development and testing, ensuring a smoother user experience and faster iteration cycles.
|
|
|