Hey everyone!

I’m Matt Higham, I’m in charge of technical art and visual feedback systems here at Hidden Pizza. This week I’ll be telling you a little about our design process. We utilize the Agile design process, which focuses on strong communication between all team member regardless of position or specialization in addition to a flexible, iterative design cycle. There’s a great article on sparcedge.com that goes into detail about the Agile process, but I’m going to focus on how we at Hidden Pizza apply the principles of the process to our own design and development cycles.

We operate in 2 week sprints, setting goals at the beginning of the first week and assigning tasks to individuals. We have daily standup meetings, whether it’s in person or over slack. It’s important to make sure each sprint has a specific goal in mind, such as the introduction and testing of new systems or creating a stable build for a demo. What’s great about the Agile process is how easy it is for team members to adjust their tasks and temporarily change roles to help facilitate tasks or goals that have higher priority for a particular sprint. It allows everyone to contribute to the design, which is fantastic when you have several people constantly bouncing ideas off each other.

To give an example, a new potential system undergoes an extensive vetting process before reaching implementation. Two or three team members will form a small group to brainstorm and fully flesh out the system. The bulk of this process takes place on day one but it is extremely common, if not the norm for us to go back and adjust elements of the system over the next several days. It’s great to get external opinions about the design of any system, which is why it’s so important to constantly consult with other designers and developers. Even if you are just talking online, getting the opinion of someone outside the team who has some distance from the project is a great way to gain fresh perspectives about the design.

After extensively mapping out the design of the system, it’s time to move on to the prototype phase. We always utilize paper prototyping wherever possible; this past week we finalized the prototype (below) for our new room placement system, which will give players the ability to build their own haunted houses.

It’s imperative to have specific questions in mind when designing any prototype. Design the prototype around the problem you are trying to solve or the question you are trying to answer. For example, to determine the best way for a player to expand their house, we wanted to test whether players preferred having free choice over the rooms they build or if they preferred the challenge of choosing randomly. Ultimately, we ended up somewhere in the middle by allowing the player to pick between two randomly chosen rooms.

The prototype also serves another important function, which is testing that the system actually works. If you can’t get it to work on paper, it’s not going to be any easier while programming. A paper prototype proves the validity of the system and allows you to move on to implementation. Just like the design and prototyping, the development of the system in-engine should be iterative. Build a digital prototype, test, repeat. Eventually, the digital prototype should become the finished product.

Thanks for reading and stay tuned for next week’s post!