After looking at the overall project and then at the plan for the game design, it is time to tackle the app design.
This means, first and foremost, coming up with all sorts of questions about the app itself. Imagining it being used. And then finding answers to all the questions and problems arisen in this way. If all goes to plan, the end result should look like something that makes sense and can then be used to organize the actual coding. As made apparent by previous articles, the game design itself is not yet 100% finalized, but this is ok. The core gameplay is there, which is all I need in order to plan a Minimum Viable Product (MVP).
I imagine the Players sitting around the table. They have some paper and pencils, maybe some dice. And a device running the app. Wait...
Should the game be played running just one app for the whole table? Wouldn’t it be better if each Player had their own app-client/device, to manage their own personal stuff?
On one hand, the less devices are needed to play, the more accessible the game is. Also, if all app activity happens on a single device there is no need for internet connectivity or remote servers and databases; not for active gameplay, at least. On the other hand, fitting all the app functions in just one tiny screen could turn out to be a challenge. And if each Player has its own game-client, then the various game activities can be more efficiently split between the users.
Nowadays pretty much everyone has a smartphone with an internet connection. Plus, people usually play this kind of games at home, where a WiFi is an ever present given. But what if you have no/slow web access, for any of a thousand possible reasons? What if some doesn’t have a smartphone at hand, for any of another thousand possible reasons?
Thus the app will have to deliver the game experience with just an offline smartphone at hand. Let's keep on imagining. The players have a smartphone. Wait...
Is it in the center of the table? Or maybe they pass it along depending on the current necessities? What are they doing with it? What kind of input is needed?
I can imagine the Players tapping on the app, selecting options or pushing buttons. This can be fast and unobtrusive, if well handled. Conversely, I don’t want them to write anything in the app, especially not during active gameplay! I find typing text in an app a too cumbersome activity that would break the flow of the game. It can be ok during game setup, maybe for character creation purposes, but I’ll avoid it in all other cases. In general I want the Players to produce physical game artefacts: maps, written notes, character sheets, lists of people met and stuff found. You don’t play by doing stuff within the app, you play at the table with pen and paper; the app is there to offer info and instructions.
To recap: mobile-first offline app with almost no text input and as little ongoing interaction as possible. I imagine the Players merrily tapping the device and using the app. Wait... what are they using the app for? What does the app do for them? To answer this we need to start looking a bit back to the game design.
Let’s assume everyone familiar with the game. The app taught them how to play, but we won’t think about this right now; the game tutorial is a feature that should not be part of the MVP. So we know how to play and we gather around the table and start a new delve from zero. What is needed for this?
It would be cool if the app could also track the details relevant to calculate each Adventurer’s final Achievements, and the changes in each Player Account. But these too are features that transcend the scope of an MVP. This is more or less all I can think of at this time. The next step will be to start going through the activities we just listed and imagine which screens are needed, and then produce a wireframe for each one.
On one hand, the less devices are needed to play, the more accessible the game is. Also, if all app activity happens on a single device there is no need for internet connectivity or remote servers and databases; not for active gameplay, at least. On the other hand, fitting all the app functions in just one tiny screen could turn out to be a challenge. And if each Player has its own game-client, then the various game activities can be more efficiently split between the users.
Nowadays pretty much everyone has a smartphone with an internet connection. Plus, people usually play this kind of games at home, where a WiFi is an ever present given. But what if you have no/slow web access, for any of a thousand possible reasons? What if some doesn’t have a smartphone at hand, for any of another thousand possible reasons?
In the end I think that the best approach would be to hope for the best, but plan for the worst. If you are offline and only have the one device, you can play with no problems, then if you have internet connectivity and multiple devices with big screens the game will play in an even smoother and more comfortable way.
It is a bit like programming with a mobile-first approach: design with a small screen in mind because if it works well there, it will work well on any other screen, and it takes relatively little effort to expand and rearrange things if later you have more space and resources at hand. Note to myself: don’t forget that low-res graphics look like shit on high-res screens; plan accordingly.Thus the app will have to deliver the game experience with just an offline smartphone at hand. Let's keep on imagining. The players have a smartphone. Wait...
Is it in the center of the table? Or maybe they pass it along depending on the current necessities? What are they doing with it? What kind of input is needed?
I can imagine the Players tapping on the app, selecting options or pushing buttons. This can be fast and unobtrusive, if well handled. Conversely, I don’t want them to write anything in the app, especially not during active gameplay! I find typing text in an app a too cumbersome activity that would break the flow of the game. It can be ok during game setup, maybe for character creation purposes, but I’ll avoid it in all other cases. In general I want the Players to produce physical game artefacts: maps, written notes, character sheets, lists of people met and stuff found. You don’t play by doing stuff within the app, you play at the table with pen and paper; the app is there to offer info and instructions.
To recap: mobile-first offline app with almost no text input and as little ongoing interaction as possible. I imagine the Players merrily tapping the device and using the app. Wait... what are they using the app for? What does the app do for them? To answer this we need to start looking a bit back to the game design.
Let’s assume everyone familiar with the game. The app taught them how to play, but we won’t think about this right now; the game tutorial is a feature that should not be part of the MVP. So we know how to play and we gather around the table and start a new delve from zero. What is needed for this?
- create a Player Account for each user (it’s our first game!)
- of all the Accounts available, select which ones are active in today's delve
- assign them to a new Quest (this might be part of the previous step)
- create the Quest
- create the Adventurer characters
- during the game:
- track who has made a Move in the current Round
- show/hint which Moves are available
- show if it's the Adventurer or Enemy part of the Round
- constantly save progress, in case the app is closed
It would be cool if the app could also track the details relevant to calculate each Adventurer’s final Achievements, and the changes in each Player Account. But these too are features that transcend the scope of an MVP. This is more or less all I can think of at this time. The next step will be to start going through the activities we just listed and imagine which screens are needed, and then produce a wireframe for each one.