What could have gone better?
Stronger Preproduction Deliverables
We missed the mark with some of our preproduction deliverables. This landed us in an awkward position that we were moving forward with producing levels, assets, etc. but our sources of truth (e.g. Macro, Art Bible, Design Prior Art) were not easy to reference clearly. We didn’t deliver a fully complete Vertical Slice either, which made it hard for Design to scope individual levels, Art to continue building based on the Beautiful Corner, and Engineering didn’t have standardized testing practices.
Fortunately, the Leads team noticed milestones were not being met correctly, and began ensuring stronger adherence to meeting deliverables. We completed alpha right on the mark, and hit beta very strongly.
If we were to do it again, we would:
Have an Art Bible with more visual passes in 3D. Before generating assets, use stubbed assets to do visual development, and use more references from games.
Create a Design Prior Art Bible that includes games with level design and puzzle references.
Create an Audio Bible with SFX references and test these without music.
2. Asset Management and Inconsistencies between Drive, Unity and Discord.
We had weekly art syncs. Before these, artists would submit their work for review, upload it to Drive and link it in Discord. In the meeting we’d go through deliverables one by one giving feedback. If an asset needed iteration, it would be resubmitted to the Discord check-ins channel until it was greenlit. Sometimes, assets were not uploaded to Drive, and had to be downloaded from Discord, and this led Drive, Discord and Unity to get out of sync with each other.
This led to a lot of manually tracking down assets, needing to manually confirm assets, and pushing the wrong assets to version control, which compounded and led to design sometimes using the wrong assets or mixing temporary assets with finalized ones, and engineering building gameplay prefabs using the wrong assets.
If we were to do it again, we would enforce workflow precedents more strongly, and Leads and Producers would collaborate to ensure they are upheld. Google Drive would be the source of truth for all assets. Additionally, even if artists are not in engine, we would invest in building automations and workflows to make sure asset syncing is not done manually, so that if Unity ever does look incorrect, we can just re-sync the assets with Drive.
3. Team-Wide Clarity on State of the Project.
Multiple teams noted that they wished they saw the state of the project more often. We tried to abstract parts of the project that weren’t relevant to other teams (e.g. artists didn’t need to be involved in engineering work), but this led to another problem of lack of information. We began posting team-wide updates a lot more in the Spring of 2025 and noticed a huge increase in team morale and enthusiasm.
If we were to do it again, we’d adopt the Build Review format team wide. We’d have one session every week, and each team member will sign up for at least one a month. Then, they will break into pairs, have one person play, and the other person take some notes. We would also like to experiment with a monthly newsletter. We had weekly dev blogs, but these were not often utilized by the team, and we’d like to try a new format to make information more visible.
Unclear Workflows for Usability with the Rest of the Team.
Our Usability Lead always came back with extremely insightful feedback, but they were distanced from the project. The Usability relationship to the rest of the project was described as “sending mail, and then getting a package (the build) back the next week. Then test, write a report, and mail it back to the team”.
This would have also enabled and empowered project leads to be more clear with usability and what they need tested. For example, art can directly request testing on asset readability, design can test level design, engineering can test microphone more directly, etc.
If we were to do it again, we would have a weekly Usability review, and allow the Usability Lead to communicate directly to Project Leads instead of doing a “carrier pigeon” setup. This would’ve led to stronger integration of Usability, and the Leads could have taken feedback to their teams, allowing them to react more directly and quickly, prioritizing based on quantitative feedback.
