Push to SIX
I wanted to do a little something different for this blog post. Before I was posting every two weeks, at the end of a sprint, and giving a status update. I want to have one post for the final month-long push getting the game ready for SIX. The biggest reason why is because a lot of “Producer” stuff didn’t happen. For the most part, the tracks have already been laid. Now it was my job just to make sure the team worked as efficiently as they could while keeping them on course. Let’s take a look.
A closer look at a few things
Tutorial - One of the things we learned very quickly from early playtests and feedback forms was that the players don’t actually read the instructions on the main page. We kept getting comments about how the player didn’t know what buttons did, or what they were expected to do next. So, we always planned to have a tutorial added later in development. As we pushed into Beta, we started planning out what we wanted the tutorial to look like. We planned on reusing other assets and would just need to make a system for all of the pieces to work together. I had a few conversations with Ryan about what needed to be in the tutorial. At the end of each conversation, he would look at the screen for a few minutes and say he wasn’t sure what he wanted me to do. I would explain what I needed again, then he would say ok. But then he would have a look on his face that didn’t fill me with confidence. I know this now, but this was his way of telling me that he didn’t like my idea.
We had another conversation when he completed the first pass on the tutorial. This is when I asked him what he thought about the idea and what he would like to see added or changed. Ryan didn’t want a tutorial at all. He prefers games that tell the player very little. If the player needs to spend 10 hours trying to figure something out, that’s fine by Ryan. He likes games where the player learns from trial and error. I told him that wasn’t acceptable, and we need to have a more ‘traditional’ tutorial.
I didn’t like how that conversation ended. A few minutes later I sat back down next to him and explained my thought process. We are developing a game that is meant to be played at SIX for no longer than 5 minutes. Our target audience will not have the opportunity to play this game multiple times to learn from their mistakes. I cannot rely on the player reading the instructions before player, based off the feedback we’ve received. I need to communicate information to the player in a safe space so they can learn quickly. How that was done, I did not really care. I then asked him what he didn’t like about tutorials and his thoughts on how we can achieve our goals of communicating with the players.
In the end we reach a compromise. When I say compromise, I don’t mean someone wins and someone loses. I don’t mean neither of us are happy. What I mean is we sat down, and we talked about different ways we could achieve our goal while still making the game fun. We came to agreement that this was the best solution for us at the time. That is how the current tutorial system came to be.
Thinking about the downstream - At the start of this project, Abi really wanted to show off her environment and lighting skills. It was always planned that the design team would make the rooms then in Beta, Abi would come by and add all her artistic flare.
When we entered Beta, Abi started work on her environmental art. She completed work on one specific room where she added a tree to the middle of the street. This tree looked amazing, but we would need to go in add colliders to prevent the player from running through it. On top of that, it turned a large open space into two narrow little passages.
I asked her if she talked to Spencer about blocking off this section of room. She said “no” and didn’t think it was important to talk to him about that sort of thing. The room looked better than it did before. The impression that I got from her was that’s all that matters. “Who cares what else happens as long as it looks good?” I then had a conversation with her about the need to think about the downstream impact of our decisions. Yes, the room looks better now, but do your changes impact combat? Gameplay? AI pathing? Abi took the feedback well and we put a system in place where she would check with each department before making any non-cosmetic changed to a room. In this particular situation, the room was not impacted by her decision, but I think adding this confirmation process alleviated a lot of problems down the road.
