WEEKLY NARRATIVE
I don't have anything special to report for this week. The Thursday night meeting was more of a recap than any new task assignment, as was to be expected this close to the end. All my hours this week went into playing the game and getting screencapture in order to improve the quality of gifs in our sell presentation. There were a lot of other cosmetic changes to it as well, which I worked with Mike on. Lastly, I went back over the playtest survey one last time, now armed with the grading feedback from the versions we submitted earlier in the quarter.
CONTENT WITH HOURS
- Meetings (2 hours)
- Sell presentation rework (8 hours)
- Scrum, including analyzing playtest data (3 hours)
WORKFLOW EXAMPLES
POSITIVE OUTCOMES
NEGATIVE OUTCOMES
- The combination of Photoshop, Unity, OBS, and Google slides is enough to crash even the mightiest of computers
POSTMORTEM
I've always been a natural leader, and it bothered me immensely when I wasn't selected for that position last quarter. But what I learned from the experience was that sometimes it's better to let someone else be the face and make the decisions while you worry about the logistics. I was happy to slip into a similar position as scrum-master this term, allowing me to still keep tabs on our deadlines and progress along the way, with the bonus of getting to compile all the presentations, which is something I really enjoy doing. I took on way too much with SPARK, and to some extent I needed to for it to be successful, but with Remembrance the rest of the team was large and skilled enough that delegation was not only possible but highly successful.
Now, did the fact that I came into this project halfway through and found a messy codebase and an even worse Unity project hierarchy have any impact on my decision to gravitate further and further from actual programming as the quarter went on? Well, that's kind of a leading question, isn't it? But did I give anything less than 100% on my scrums, my work on the playtest survey and data analysis, the sell presentation, and the creation, editing and proofreading of the GDD and all of our other major workflow documents? I should hope that the quality of those things answers that question for me as well. And I feel like that's the best summary of the quarter as I can give: I maybe could and should have been more involved with things like the actual game build, but I feel I was highly successful with the parts I took on directly.
What went right:
1) I became a team player with this project. I knew what to expect from a few people from last quarter, and that helped me feel more comfortable delegating more to the strong members while I felt out the rest of the team. Corwin was a phenomenal Programming Lead and programming was always able to meet their goals and deadlines each week without anyone having to kill themselves.
2) From reading all the PPJs every week, it sounds like everyone got to work on pretty much what they wanted to this time around. Again, the big team allowed that, as well as covering for a lot of weaknesses.
3) Believe it or not, I feel like I learned a lot about game design from this course, both in the classroom and just working with the team. Now, this was not my first GMAP class at Drexel, not by a long shot, but before it had always been about pleasing the professor and catering to the very specific whatever they were looking for. This time, we got the hands-off freedom to be creative, balanced with suggestions for improvement and general tips for making games better, even when they didn't apply directly to this game.
What went wrong:
1) The design -> programming workflow. I've already written a lot about this, probably more harsh than I should have been...but it really bothered me when the design team kept throwing in new things A) without asking programming if they were even possible, and B) when they contradicted features and other things already in the game.
2) Making builds at 6am the day they're due, after pulling all-nighters to even get to that point, just doesn't work. Half of the team liked to leave their work until the last possible minute, even with multiple reminders, encouragement, and "public shaming" over the chat. We developed a better solution for this by mandating a frozen build (bugfixes only allowed afterwards) on Saturday night instead, but A) that meant that this build was always very art-sparse, and B) the fact that it took the hit to our grades for this to happen, late in the quarter, is discouraging in-and-of itself.
3) Towards the end, it seemed like programming was going in circles. Every new thing seemed to break something else, something that had already been fixed, and it seemed from my [albeit outside] perspective that the hotfixes were getting close in number to the amount of "real" code. I'm truly worried about the integrity of the game trying to move forward past this.
4) I just have to add: I think moving from Git to Perforce was a huge mistake. We lost about two weeks to it at the beginning, just trying to get everyone connected and able to use it, and it's caused nothing but problems ever since. Inadvertently locked files, or ones that were forgotten to be included in a revision, or it just not playing well with things like Unity's prefab system have caused us more problems than...wait, why did we even want this in the first place?
Lessons learned:
1) Put a programmer on the design team.
2) Set deadlines much earlier than necessary, expect for them to not be met anyway, and never undervalue QA and testing.
3) Do what you like and are good at, and let other people do what they like and are good at, and everyone will be happier.
NEXT TASKS
The list of final deliverables is kind-of heavy for me, considering how I just described my position on this team. I've had my hand in the sell, the GDD, the Gantt, the playtest data, the other workflow and archive documents...and they all need to be cleaned up before final submission.
TOTAL HOURS LOGGED THIS WEEK: 13 hours
No comments:
Post a Comment