What went wrong
There were a lot of problems that felt like they appeared out of nowhere and impeded the team heavily. For example, when we were making a build of the game for beta and realized we had actually never made a build of the game since alpha (a 5 week span). While we can attribute this issue to a few small things and the team genuinely forgetting to do builds, what I see as the cause of this is a lack of action. Lack of action? What does this mean? Well, for many of the problems that occurred on the team, they came out of nowhere and we reacted and solved issues. However, whenever one issue was resolved, we went onward almost like nothing had happened. I think that a general attitude of being reactive instead of proactive made these issues more frequent than they should have been. Particularly, I think that the leads of the team actually did a sort of week job at taking action to facilitate these issues. While each lead was doing a relatively good job at managing their discipline's tasks, there was a large failure to promote communication cross-discipline. After an issue we would say "we'll communicate more next time," and "everyone can do better about this next time," we avoided tackling the specifics of issues and what we could do to improve afterwards, so we held back really improving communication until around the time we created strike teams. This goes without saying that the leads are not primarily at fault. I did my best to communicate these issues that I saw every so often, but even I held back on bringing issues to the team because I thought "someone else will take care of it," or, "it's not important enough to mention." Also, a lot of our on boarded members were either passive or quiet for the most part, making it difficult to spark conversation about these issues. That being said, a few more quick, definitely more subjective, things to say are:
We had two leads meetings a week, no sprint retrospective, and a very strange sprint planning where are tasks were handed to us (this ended quickly after week 5 or 6). All of this rendered the communication of how the game was doing plus reflection on how we could improve, impossible
Our presentation was very weirdly permission based on what could be edited in it, but in actuality, that changed completely? It felt like there was invisible rules to it and it felt wrong. It should have been brought up to the team sooner
The game also needed WAY more planning to fulfill the narrative's goals and to help the designers iterate on the gameplay experience
A lot of the issues on the team affected me emotionally. This is is the only personal reflection I'll have, but I need to find a way to take a step back when I'm working. I felt my feelings got in the way of my communication with the team too often
What went well For the most part, work that got done on this project was of good quality. The art looked great, the programmed systems were a strong foundation to the design, and yes the design had some bumps, but even the gameplay experience and narrative shined well in the end. Additionally, the team had very few impediments based on personal conflicts. This isn't to say they didn't happen, but they weren't LARGE impediments. For that, I'm grateful. Lastly, near the end of the project, when we nearly missed beta, our team decided to form strike teams that would have multiple disciplines tackle important parts of the game (narrative team, UI team, puzzle team, etc.). This decision was one of the best the team made because we were able to tackle the various bugs in the game with specific people to bring it to. It also fostered communication on parts of the game that weren't previously talked about much.
What could be improved
I've learned that if you have a narrative game, it's really important to know and understand well the paths the player takes to get to the end. Without that information, you have a lot of pieces like conversations, explorable spaces, items, etc., with no actual idea how they fit together. But there is one holy thing that all people tasked with implementation can rely on when working late in the night: DOCUMENTATION!!
I found that so many of the incomplete docs we had for narrative were actually really helpful! ...If they were consistent and not incomplete. I had not cared a single bit about documentation in my project last semester, but if there is something Blood to Ink taught me, it would be the importance of documentation on a project with a lot of specifics involved.
Something else I found important for this project was the strike teams. The secret is that strike teams coming about on our team during beta was not the first time there was a strike team on our project. Since very early on in the project I worked closely with Amila, our team's UI artist, to implement whatever she whipped together in a wireframe into the game. Our dynamic was good and it made focusing on getting all the UI done very easy.
Ultimately... Blood to Ink ended well. It's playable from beginning to end with no major bugs, but I wish that we didn't have to have so many bad moments to achieve this. There were times on the project where I could feel everyone's motivation completely dwindle. Other times it just hurt for me to go to class. Amidst all this, I learned many practices in communication, workflow, and what I can do on a team to help out. And it would definitely be right to say that as a whole, this project was a combination of my best work, best teammates, and worst moments I have ever had on the project. I wish the best for my Disco*Vision teammates moving on to their own futures.
Коментарі