Week 9: Adjusting to Remote Work and an Amazing Opportunity for Project Ditto

Due to the current crisis, teams both here at ETC-SV and back at Pittsburgh have had to transition fully into remote work this week, which has necessitated a lot of internal adjustment on our part here at Team Ditto. As such, we spent most of the week trying to figure out and setup our remote work pipeline,

The Work This Week

Adjusting for Remote Work

Fortunately enough, we already had some infrastructure in place for remote work, as Tracy and Wenyu had already been utilizing Sourcetree for our version control since the first half of the semester. In addition to this, we adopted Jira for productivity and our Scrum sprints, as we felt that its structure was more in line with how we were handling our sprints in person vs. Trello. Finally, we instituted a schedule of two team meetings a day, a short one at the top of core hours meant for Scrum Stand-ups and a long one in the afternoon to discuss more complicated tasks like design or mechanical issues.

In order to test the efficacy of these new tools and schedule for our remote work, we decided to do an internal Goldspike from which we could evaluate our remote pipeline. The Goldspike in and of itself was pretty simple and very reminiscent of the one we had all done in BVW (i.e. create a simple cube, a simple sound, and a simple interaction) with the only difference of us uploading it to a team itch.io page, which you can find here.

Overall, our Goldspike went without a hitch, but in the process of discussing how we were going to handle remote work, we realized we did have a pretty large problem we needed to address in the light of the COVID situation.

New Circumstances, New Problems

Previously, we were able to create a way to simulate networking through a casting function found in Unity. Assuming that multiple monitors were connected to one device, when we instantiated a new player object, we could simply create a new camera and cast that camera’s view onto a new monitor. Through this method, we could effectively hook up at most 8 monitors to a single computer tower, allowing us the ability to have multiplayer gameplay without resorting to any actual networking; everything could run off of a single Unity file.

At the time, this workaround for networking seemed ideal to us, as having only one dedicated programmer on the team meant that trying to implement both gameplay and networking at the same time within the scope of the semester would be practically impossible without major crunch. However, the current COVID situation had added quite a wrinkle in our simulated multiplayer plans.

This meant that we had a couple of different options for development going forward:

1. We could simply bite the bullet and figure out networking, which while it would allow us to go forward on our existing prototype, it would necessitate a LOT of development overhead, especially now that we are halfway through the semester
2. We could try to find some other way to simulate networking outside of our original method, which while easier than figuring out networking, would mean that we would still need to spend some time researching how something like this could be done.
3. We could just go forward on our current prototype, but only scale it for smaller, local multiplayer. This would allow us to simply go forward on the prototype we have built without changing anything else about how our “networking” is handled, but it would mean that we wouldn’t be able to fully test the scaling of players.
4. We could transition our game concept to a single-player experience.

Of the 4 options provided above, Option #3 was the most popular among the team. However, we ultimately wanted to vet Erin’s opinion on it before we moved forward on development the following week. So, with this networking conundrum in mind, we went into our client meeting armed with questions and uncertainty as to how we would move forward.

Client Meeting

So imagine our surprise when Erin suggested that we try to pitch our Virus vs. Cells concept to Stadia as an actual title to be released on the platform! While this was certainly a jaw-dropping proposition for all involved, let’s back up a minute before delving a little bit into this amazing opportunity.

As mentioned in the previous section, we came into our client meeting with several questions regarding how we would handle the networking aspect of our game. After all, in our prototypes that we had developed in the first half of the semester, what we had realized that State Share was really effective at was in multiplayer scenarios where you needed to rapidly scale up or down players inside of the game.

In response, Erin felt that we could simply move forward using the current “networking” method we had developed, but she also felt strongly about helping us to strategize how we could leverage this project for our own portfolios. To that end, she asked us if we would be willing to turn our existing game prototype of Virus vs. Cells into an actual game pitch to Stadia.

This would mean that we would have to create a really good pitch deck in a short amount of time, as our window of opportunity for actually be able to pitch our game to Stadia was by her own admission relatively small, and of course, any game pitch in and of itself (especially for people like us who are relatively new to the industry) is a long-shot. However, the entire team felt that this was an opportunity that was too good to pass up, and so we decided to accept this proposal and formally pivot our project to creating a dedicated game pitch based off of our Virus vs. Cells prototype!

The Plan for Next Week

Now that we have been put on an unexpected path for the last half of the semester, there is quite a bit of work to be done in a short amount of time. In broad strokes, we want to accomplish the following tasks, if not next week, then in the next few weeks:

• Determine a name for the game
• Design and/or create the following for a good 15-second snapshot of our game
  • A single level which can help us showcase our gameplay
  • At least two different kinds of player types
    • Virus
    • Cell
  • Implement the following gameplay
    • Replicating via State Share
    • Merging
    • Interactions between Virus and Cells
  • Polished concept art and in-game assets
    • Character designs
    • Environmental assets
    • Logo

As you can imagine, we have a lot of ground we need to cover, especially since our focus in the first half of the semester was primarily on mechanics and not aesthetics, but we’re super excited to get to work!