This retrospective was written from my own perspective, with fact checking through staff interview. To my knowledge, the events here are accurate, but I was not privy to context outside of my communications with the team.
Part 1: How it started
PWCCG’s development started as a hobby project with a few commissioned art pieces and lore guiding the theme. After 6 months of private development, the project was shown to a fan community to get feedback and “H” gave some feedback on the existing design. After following the project for about 3 months, H suggested recruiting additional talent.
Part 2: How I got involved
In Summer of 2020, as the pandemic entered full swing, I was contacted by “H” about the possibility of giving guidance on their friend’s CCG. As I had no other major projects running at the time I agreed and joined the Discord server to meet the team. The project was shown to me, a grimdark-lite pony-themed card battler that had a prototype that had been tested by a few dedicated fans. What started as a consultation turned into a permanent position as it was determined that the game needed serious work to meet the goals laid out for it.
Part 3: Setting up a Development Environment
As my first task, work began on streamlining the prototyping process. A spreadsheet already existed containing basic information about each card, so setting up a collaborative editing environment was trivial. I wrote some software to generate JSON files that Tabletop Simulator could read as decks and set up a workflow that allowed for quick prototyping and balance testing. As part of that process, the cards got some basic formatting that made the cards visually palatable enough to not put off early testers.
Part 4: Organization Trouble
Up until this point I worked under the assumption that the project already had an organizational system in place, and that I had slotted into it without needing to be informed of anyone else’s activities. Work in the dev cave, come out for meetings, repeat. When work started getting bottlenecked, a meeting was held and things were clarified. The project lead was holding everything together himself. No kanban board, no individual task deadlines, and some project members having not given any concrete progress updates in weeks. It was around this point that my priority went from “create the rules and mechanics of a card game” to “help with the setup of a basic team environment so that the required assets could be accounted for and I could get back to my dev cave.”
Part 5: Out of Scope
Once a trello board and some deadlines were set and more regular status updates were scheduled, I shifted gears to firefighting. I’m not a graphic designer, nor am I an editor, typesetter, talent manager, or tester wrangler. Nevertheless, those tasks went unclaimed on the board long enough that my original job was stalled, so I took up those positions alongside H, who had been doing “assorted tasks” in the background up until this point. Since I already worked well with them and we were both doing “assorted tasks” at this point, we set up a nightly collaborative work session where tasks were claimed and resolved as quickly as possible, with the assumption that a professional in the relevant fields would pick up those tasks later.
Part 6: Out of Budget
Unfortunately, the budget didn’t allow for those dedicated roles. A volunteer showed up to contribute some graphic design work, but coordinating between them and our hacked together temporary solutions proved to be time and labor intensive. Instead of a graphic designer, some assets were commercially licensed and edited by the 3 of us (H, the volunteer, and myself) working together. We realized at this point that a lot of what was supposed to be left for someone else was going to end up in the finished product if we didn’t find solutions soon.
Part 7: Crunch
Since firefighting had eclipsed my original role, H and I doubled down on the nightly session hours and started aggressively cutting down the scope. Unassigned art was replaced with “Guest” art by members of the team or outside talent. Cards became increasingly modal to compress the vital tools of the game into the smaller set size. I started coordinating regular blind testing to get feedback and alleviate the tunnel vision that inevitably comes from working on something too long.
Part 8: Drawing the line
With the deadline coming up, I had to drop (almost) everything and focus on my core tasks: Designing and balancing the game itself, and going through the final iterations of the ruleset. The only other task I retained was coordinating the blind tests, as I was the one who had set up the workflow for managing the incoming data and was going to be the one using that data. There wasn’t time to wait for weekly meetings and discuss the state of each balance patch at this point, so the project lead signed off on the work with the most liberating yet stressful statement: “You are the professional in this area, I trust you to do what needs to be done.”
Part 9: Final Assembly
For the last 2 months of development, I narrowed my focus and put my head down, with the mantra “Not my task, not my problem.” I submitted the final version of the rules to be turned into a rulebook, pushed a final print of the prototype cards, and after 39 major revisions and ~5300 minor revisions, sent out the spreadsheet to be used in the final assembly. A pizza party was held over discord as the cards were being assembled, but things got somber very suddenly. Nobody had been hired to edit and typeset, and H was the only one on the team with any significant experience in those fields. The deadline was pushed back 3 days, and the text on the cards was typeset by hand by H. The cards were sent off to the printer and H took a short break before picking up their next mantle, filling in for the missing web developer.
Part 10: Lessons Learned
Twilight Conflict was the first team-oriented commercial project I’d worked on in years, and I took a lot of things for granted. Here’s what I took away from it:
- Stick to your role. You were hired to do a job, and the success or failure of the project depends on each person doing their job well. However…
- Be active in communicating bottlenecks. If an asset critical to your job is being held up, management needs to fix the pipeline, not just push that one asset through. Otherwise, you will stall out repeatedly.
- Maintain Accountability. Everyone needs to be able to know the status of the project and all aspects of it that could impact their work. This means teams need to consistently report to a transparent system that can be referenced at-will, rather than responding to individual queries themselves. Failure to report should be treated as that team stalling out and should be a priority task for management to address.
- Don’t let individual team members “firefight”. If the task is critical, someone needs to be assigned to it that isn’t already doing a critical task. If you can’t afford a dedicated team member, hire temporary outside help. It’s better than sabotaging your core members. Not every job needs a dedicated person for the duration of the project, but every task needs to be assigned in a way that doesn’t compromise core teams. There’s a reason studios have interns.
- New Scope? AUDIT TWICE. If it’s important enough to consider changing the scope it’s important enough for management to spend time ensuring that it’s not just an efficiency issue, and if it’s an issue that truly requires a scope change, it’s worth management spending a time ensuring that the new requirements can still be met with the same tasks and roles.
