This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
3. A Good Working Relationship
JM: Spike was absolutely great to work with. From design ideas to schedule changes, they were always open to listen and give their feedback. Not to say that there weren't requests that made the team groan and shake their heads, but if there was a reason we couldn't do something, or a direction that we wanted to lean towards, Spike was extremely reasonable and ready to make accommodations if need be. Open and honest communication was the key to this.
For instance, after the production team's meeting where we defined what type of game we were going to make, I hopped onto a phone call with Prithvi. I laid out our plan of attack and what we wanted to accomplish with the game.
He replied that he had been thinking about the game's direction as well and what we were proposing was in line with what he envisioned would make a standout title. Having both the developer and publisher in sync was awesome and it made the whole development process go a lot smoother.
PV: A funny anecdote related to this is when we were initially seeking developers to work with, it came down to Pipeworks and one other studio. That studio came into the pitch with a fully working demo, and Pipeworks had a rendered game trailer. Being a producer, I was immediately impressed with the demo and felt that it created a good base for iterative development.
However, the rest of our management team felt the game trailer better captured the spirit of what we wanted the game to be. Plus the head of Pipeworks, Robert Daly, is an ex-Army Special Forces member, so he brought a lot of combat awareness to the team.
Even after we chose Pipeworks, initially I was not sure we made the right call. It was a risk to choose a promise of a game versus a game in early working order, but now I have no doubt that we made the right call.
Through the life of this project, our working methodology has felt like a partnership more than a traditional developer/publisher relationship. We are very open with our goals for other projects such as downloadable content (DLC) and sequels, and Pipeworks is great about working with us and the multiple avenues we are currently exploring. That openness on both ends makes having a singular goal possible.
4. Double Compliance
PV: I am putting this in bold, as I think this is the second best decision we made as the publisher (choosing Pipeworks as our development partner being the first). We used two QA teams. Pipeworks is a part of Foundation 9 Entertainment, which has its QA group, F9QA. It made sense to partner with them as they already had an internal pipeline established to hand over builds and communicate on-the-fly about bugs.
We also partnered with VMC to QA the already QA'd builds. Using a staggered build delivery schedule, we were able to get F9QA to go through all the functional and compliance issues, have Pipeworks make the fixes, and then send the game to VMC for a final compliance check.
This sanity check was great, as the project passed QA in its first attempt and it forced both QA teams to be thorough and honest with the issues that they were finding. Many issues were logged into the database that would not constitute a certification failure, but having that extra set of eyes on everything made the final product that much more stable.
5. Team Build Reviews
JM: As a team, build reviews helped us to see what was going on in the game at that particular moment. It was a snapshot, if you will, especially for those on the project who had their heads down grinding away at their tasks.
I can't even begin to count the number of times I've heard the phrase "I thought that was fixed" while sitting in a build review. Just because a fix or a change was submitted didn't always mean that it was working correctly, or made it into the game.
Speaking of working correctly, without our build reviews, we would have had to rely solely on the QA teams to verify whether or not the game's shell, assets, and gameplay in general were all working as intended. If it was a subtle or obscure change/fix that we made, there would have been no way that they would have been able to verify it one way or the other.
Our reviews also helped us to recognize areas of the project that needed more attention, either by the dev team, or by the QA team if what we were seeing wasn't being reported in the database. The only thing that we would have changed about our team build reviews is that we would have had more of them. They always helped the project.