This week we spent the majority of our time continuing to brainstorm concepts for possible State Share prototypes, as well as trying to come up with questions regarding the inner workings of the State Share feature itself. By the end of the week, we were not only able to narrow down our exhaustive list of prototypes down to 5 concepts, but we are planning to start the development of paper prototypes on these ideas at the start of next week!

We also finally decided upon a name for the project: Ditto! We liked the name since Ditto seemed to convey a lot of different valences at once. The literal meaning of it means “the same thing again,” reflecting the replicating aspect of the State Share feature, as well as being a clear referent to games due to its explicit link to the Pokemon Ditto. We also liked it since the word is both fun to say and pleasant to look at, carrying with it connotations of being fun and light that we hope will also be reflected in our final product!

The Work This Week

Brainstorming, Continued

• 

• 

• 

Based upon both last week’s brainstorming session and a recommendation from our instructors to categorize these concepts into broader categories, we were able to subdivide our 30+ ideas into 10 distinct groups:

1. Geographic/location-based
   • References: Pokemon GO, Fitbit
2. 1 state → multiple states → 1 state
   • References: Minecraft, Animal Crossing
3. Asymmetric multiplayer
   • Streamer is the host, audience joins
   • Time sensitive and event based
   • References: LocoRoco
4. Single-player, puzzle/storydriven where state share acts as event trigger
5. Time travel as version control
   • References: Undertale, Github/Perforce
6. Level editor
   • References: Mariomaker, Google Docs
7. Transition between devices 
8. “Read Only”
   • You can view other people’s states, but cannot actually change them
9. Hard Core-esque games
   • Setup hard challenges that are shareable
10. Instant Access
    • References: Speed Runs?

Having isolated

Client Meeting

This week, the entire team took a trip down to the Google Stadia offices down in Mountain View to ask our client new questions regarding the inner workings of State Share (and for the free lunch too!).

For this meeting, we wanted to present not only the categories of concepts we came up with, but also to ask Erin an exhaustive list of questions regarding the inner workings of State Share:

1. How does crowd play combine with state share
2. Can you merge states?
   1. Can I bring a save back into the main branch of a game?
      • Ex. if I beat a boss for my brother, will it change his main save, or will it just be a different save?
        • Will it be possible to choose a save to merge back into the main branch?
   2. Can I use elements of a new save to override the same elements of an old save?
      • I.e. keep the world save, but update the character and inventory?
   3. Can we control what elements get merged?
3. How does Stadia know who is playing?
   • Are there internal IDs?
4. Will I be able to keep this game save after I am done playing?
5. Will Stadia streaming be open to everyone, or just subscribers (aka paid users)?
6. Can you embed multiple states in a video file or an image?
7. If you have a multiplayer game, and it gets saved, can only one person open the save, or do all the original players need to be present?
8. State Control
   1. When a host shares a state, do they still have control over the state, or can other people override it?
   2. Can you set who can access a state?
   1. Will other players be able to permanently overwrite your saves, if given the option?
9. How embedded is state share into games in Stadia?
   • Does using state share mean you have to leave the game world (go back into the Stadia application), or can you remain inside the game?
   • If we’re faking the link, can we just create a “link” inside of the experience, or do we have to generate a real link that you need to click outside of the game?
10. Does Stadia have particular kinds of interactions that they would like us to explore?
11. Could you explain further what you mean about Nintendo-esque experiences?
12. Preferred duration of game, and preferred genre (now that we’ve signed the NDA)?
13. How “fake” can our demo be?
    • For networking, does it have to be real networking, or a fake one
      • If it needs to be networked, does it have to be LAN or really online?

In response, Erin told us that the Stadia API will pass the parameters stored by State Share (inventory, position on the map, health, etc. etc.) directly to the developers, but it is up to the developers to decide what to do with it. In other words, the Stadia API will give us all the pertinent State Share information we as developers will need, but we have to construct the systems that use that data in a particular way. So if we wanted to merge states together, that would be perfectly possible under the Stadia API, but we would have to build the “merging states” feature ourselves.

Erin also challenged us to consider what kind of game would be able to reach and scale with a billion players. This meant not only thinking about gameplay that would be intuitive for a wide demographic, but also one that could be massively multiplayer in a way that was both unprecedented and supported by the Stadia infrastructure. Clearly, an incredibly hard problem to answer! But this concept of “what will it take to reach a billion players?” is something the team will definitely be thinking about going forward.

The Plan for Next Week

After our client meeting, we went back to our categories of brainstormed concepts and isolated the ones we as a team both liked the best and centralized State Share as a mechanic the most.