📝 About Production 📝
Table of Contents
About
We completed this project as part of Worcester Polytechnic Institute’s One-Term Studio. All five core team members worked in a lab space 40 hours a week for 8 weeks. Pre-Production was conducted in the prior academic term, working 8-10 hours a week in preparation for Production.
For more information about our Pre-Production process check out the Pre-Production Page!
Lessons Learned
- Establish a time buffer for game polish and documentation.
- Build and play together.
- Organizational structures are tools for your team, so update them as needed.
- Address conflict as soon as possible.
Development Timeline
The Development Timeline is a document we outlined during Pre-Production to plan out our Production schedule. We referenced and updated the timeline throughout Production to monitor progress and keep ourselves on track.
Our general timeline was as follows
- Week 1: Project Set up and Documentation
- Week 2: Prototype / Tech Demo
- Week 3: First Playable
- Week 4: Minimum Viable Product (MVP)
- Week 5: Feature Complete
- Week 6: Content Complete
- Week 7: Documentation Complete
- Week 8: Polish, Post Mortem, Project Complete
We intended for our game to be fully finished by the end of Week 6. This was to give ourselves two weeks of buffer time in case anything doesn’t go as planned.
If you want more details on how each week breaks down, check out our Development Timeline!
Lesson 1: Establish a time buffer for game polish and documentation.
Despite our goal to try and have everything done early, we double booked ourselves. Because we set aside these two weeks for game polish and documentation, this buffer time didn’t actually function as true buffer time.
We recommend future projects plan to completely finish their game (including polish and documentation) by a certain deadline and have nothing planned afterwards. Deadlines are going to get pushed back, and pushing back a self-imposed deadline is preferable to running out of time with a deadline you can’t push back.
Design Timeline
Our design timeline outlined what specific design decisions must be finalized and when, complementing our Development Timeline. Decisions were distributed based on the design domains. For information about design domain ownership, see the Design Page.
For how we set up our design timeline, see the spreadsheet below.
Sprint Spreadsheet
The sprint spreadsheet is a document we created in Pre-Production for breaking down our timelines into actionable tasks for each team member. We used this spreadsheet for task management throughout the entirety of Production.
This document had multiple tabs for different purposes, including:
- Current Sprint
- Backlog
- Finished
- Personal Tabs
Personal Tabs was something we implemented partway into Production. After every sprint set up meeting, each team member copied their specific tasks into their own spreadsheet tab to keep themselves organized. To ensure the Current Sprint was up to date, part of our Sprint Showcase was reviewing all tasks in the Current Sprint and updating their status.
Check out the spreadsheet here:
Asset List
The Asset List is a spreadsheet that we used to track the progress of game assets, especially Art and Audio assets. This spreadsheet was complementary to our Sprint Spreadsheet as most of the team each asset had an associated task on the Sprint Spreadsheet.
Check out the Asset List here:
Sprint Structure
Our sprint system split up the eight weeks of Production into eight sprints. Each day began with our daily standup meeting. Each week we held contractor check-ins on Mondays and Thursdays, conducted playtesting on Thursdays, and held a Sprint Showcase on Fridays. Details on each meeting are below.
Daily Standup
Daily Standups were short meetings every morning to communicate progress with one another. We each took a turn describing what we accomplished the previous day, what we planned to work on that day, and anything we needed from other team members. We finished the meeting with a short team discussion for any important announcements or topics before breaking off for work the rest of the day.
Playtesting
Playtesting was a crucial part of the Production process. We established playtesting as part of the weekly sprint structure during Pre-Production.
For more info, see Playtesting Page.
Sprint Showcase / Set Up
We held sprint showcases at the end of every sprint to:
- Celebrate and review all of the team’s progress for the week
- Boost team morale by making jokes and having fun
- Review the playtesting report
- Set up the following sprint
- If applicable, play the current game build
- Update project advisors on our progress
This was critical for team communication and staying on track with our timelines.
Lesson 2: Build and play together.
We initially intended to play the current build of the game during sprint showcases to get everyone on the same page and celebrate our progress. However, we were relaxed about this rule and only actually did it twice. We should have done it more, it was really helpful when we did!
Here is a template and guide for how we conducted our Sprint Showcases
Lesson 3: Organizational structures are tools for your team, so update them as needed.
Nothing about production should be completely set in stone. If a system isn’t working, change it!
For example, our playtesting schedule included creating a build by 5pm the day before our playtesting sessions. This deadline was putting a lot of pressure on the team, so we had a discussion and moved the deadline to 10am the morning of playtesting. This helped with the pressure.
Financials
Due to none of our core team members being artists, we needed to find an alternative method for obtaining game art. We used most of our funds to contract artists for our game. For the project we had a budget of 500 dollars. At the beginning, we set aside money for setting up a Steam page, and the rest of our funds were distributed among our contracted artists.
Here is a sample of our fiancial spreadsheet:
Lesson 4: Address conflict as soon as possible.
If conflict were to fester, the project would suffer. If anyone had issues with another team member, they could go to the producer to talk about it. The producer was responsible for assessing the conflict and helping resolve the issue. Another team member was a secondary point of contact in case the producer was involved in said conflict. Putting these systems in place helped us keep production on track.
