itch.io

Compilation of all our dev logs so far

Week 1: Intro

Hello!

I'm Blake Rebeck, one of the lovely souls at Hidden Pizza working on Spook House, and I am here to kick off what will end up being a slew of content in the coming weeks.

1. First off we're going to be posting on this blog weekly with all sorts of design, art, production, and other miscellaneous musings that we can come up with from each team member in the project.
2. We're hoping to give you all a glimpse into our development process through filmed Spook House developer interviews. In these we will more specifically go over exciting aspects of the game, content we've been testing, or honestly whatever thing excites us in particular on that day.
3. All of our production pipelines are in full swing so we will have a ton of sneak-peaks, such as concept art and sprites, that we will show you all through our Twitter account.
4. Lastly, you should certainly expect our store-page at Itch.io and this website to get updated as well.

Additionally, a ton of new people have joined on with us to work on Spook House from marketing, programing, to production. Our new project manager and programmer in particular you will be hearing from so get hyped and stay tuned!

As for kicking off this weekly blog post series, I figured I'd talk a bit about post-IGF. For any of you that don't know, IGF stands for the Independent Game Festival, occurs concurrently with the Game Developer Conference, and is a competition for every game from AAA to independent student project. In the months leading up to it we began entering an extended phase of "crunch" working on the Spook House.

Crunch in and of itself isn't inherently a bad process to occasionally go through (and trust me when, with improper management, is it almost entirely unavoidable) but combine this with external factors such as college classes and you end up with a recipe of killing all productivity and motivation after that period of crunch is over. This is exactly what happened to our development in the month immediately after submitting to IGF. What we found is that, after a 2 month long crunch, we were entirely unproductive for 2 weeks and mostly unproductive for 2 weeks after that. While we were extremely productive during crunch, without the proper methodologies and processes being abided by during it, what you gain from doing so can be entirely not worth the cost.

And that's all I have for this week. Be sure to check back here and follow us on Twitter to keep up-to-date with us. We're excited to show you what's in store and to share with you some indie-dev experiences!

Week 2: Snapshot

Hello Friends!

My name is Kerry Norris, I'm the fearless leader of Hidden Pizza and I'm here to give you a snapshot of how are development is going, what we've started and the kind of problems we've run into over the past week!

We've been prototyping a few new mechanics and retroactively fixing up some of the game's weak points this past week. One thing we're definitely adding is a new mechanic to track boredom! This should counteract one of the game's big weaknesses, a lack of opposition force. In our most recent demo it's fantastically easy to do absolutely nothing and still be pretty well off in the grand scheme of things. But with your house's guests now susceptible to the concept of boredom the stakes will be a little higher!

We're also in the process of creating a system for players to be able to build their own house! That's right I said it, no one needs to rely on us to build a crappy house for them (hooray)! Of course this is going to have it's own limitations right now the rooms are kind of a one size fits all sort of deal and we're still ironing out all the kinks involved in letting players build whatever they want but it's on the near horizon.

While there's a lot of progress to be made we've had our fair share of setbacks this week too. I had to dedicate more time to figuring why our git repository was literally dying this week than just about any other task. We've also had to transition two new members onto our team and we're still working out all of the business end tasks with adding them in and making room for our wonderful new marketing team. But don't let my pessimism fool you we love our new additions and the work that they do.

That's all I can really spoil for you all this week! Watch our feeds though, we're going to have some big announcements in a couple weeks and hopefully some demos ready for playtesting by you all. Thanks for reading and keep things spooky out there friends!

Week 3: Design Process

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!

Week 4: Design Documentation

Design documentation is a strange beast; like many facets of design, there is no single approach that perfectly suits all projects. Even when aspects such as team size, composition, available money and time, technological access, or other contributing factors remain constant, the project itself will naturally tend towards needing more of certain types of information. In the case of a current project I am consulting on, Spookhouse, that information is system diagrams (more on that soon). As such, designers must not only evaluate what information to document and share, but also consider which methods of sharing are most effective.

All documentation at its core is about communication and reification (i.e. to concretely express an abstract idea). As such, design documents always seems to hit the same barriers:

· Scope: there is too much information or not enough

· Organization: the complexity of the material makes it difficult to present clearly

· Understanding: the document is tedious to comprehend for anyone other than the author

· Permanence: by the time the idea is documented, it is already outdated and must be revised (my least favorite).

These issues are common and certainly did not escape the early documentation of Spookhouse. For example, here is the preliminary draft of Spookhouse's main system diagram:

Whew that's a lot of arrows, and a clear demonstration of the third issue mentioned, understanding – to anyone other than the author detangling and parsing the information here is quite the mental task. In our conversations on how best to move forward with the system diagram, it was clear the next step was to translate it into digital format: helping both the diagram's legibility as well as its organization.

However, that still left us with the question of scope and permanence: is what is presented here too complex? Does it need to be broken down? Secondly, how will the diagram change overtime – what is the best way to communicate these changes?

Both system designer Blake Rebeck and I saw this diagram as the crux to understanding the underlying systems within Spookhouse. We wanted something that properly covered the complexity of the game's interactions, while still being flexible (to update) and easy enough to navigate. Furthermore, this main diagram only shows a high level representation of how the features in Spookhouse interact, leaving most of the nuts and bolts to be delineated in other documents. As such it was important to us that the system's diagram and documentation speak to each other directly. With this in mind we looked into various digital tools that would provide the best blend of representing the game's systemic relationships while still being easy to navigate and update on the fly. Here is our solution, created and refined by Blake using the free online application draw.io:

While the above diagram is certainly more visually pleasing and understandable, the true benefit lies in the fact that draw.io is not just a tool for creating diagrams, but also seamlessly integrates with Google Drive as well as Atlassian products such as JIRA or Confluence. This means that each node on the above diagram links to an external document that details a sub-system or feature of the game. This allows for an abstracted overview of the game's systemic interactions, without having to navigate back and forth between a static diagram and a design document overview page – the diagram IS the overview page. Let us look at how the integration of draw.io helps to alleviate the aforementioned issues of organization, understanding, scope, and permanence.

Organization/Understanding
Like many diagram software packages, draw.io comes with a range of organizational tools such as grid-based alignments, pre-made charts or connection trees, or various features to organize by size, color, shape, etc. In addition to this, and less commonly included, draw.io provides collaborative features that integrate directly with Google Drive and JIRA. Here is an example:

The above image illustrates the author's ability to easily link to external documents, as well as provide small snippets of meta-data to help other team-members understand the contents and purpose of the node. Likewise, draw.io allows components to be sorted or hidden based of this meta-data. For example, if three nodes are declared as "Core-Loop", sorting by the term will temporarily hide any nodes not declared Core-Loop (similar sorting methods are provided for color and shape). This is a useful tool for allowing the diagram to keep its richness in complexity, while giving viewers a method to sort extraneous information for the time-being – assuming a proper filter legend is provided.

Permanence
The use of meta-data within Draw.io provides additional benefits for updating information quickly and easily. For example:

By declaring a textbox as "I'm with %group%", dragging to or changing the text-box's container means the text is updated based on the meta-data within the container. This can be useful for updating large sections of a diagram by changing the group's meta-data.

One of the greatest benefits though, of having the diagram live in a collaborative program is that it can be a living-document. This phrase is often used to describe documents that are frequently updated and changed – comments or queries are left, resolved, and incorporated into the diagram/document as the project grows and changes. This practice is well supported by draw.io, which includes an extensive time-stamped revision history, allowing members to see the diagram's progression over time and promote revisions and refinements (without fear of losing previous versions).

Scope
Finally, while the use of sorting via meta-data helps alleviate some of the concerns of an overly complex diagram, having the live diagram act as a hub for external documents further helps manage the concerns of scope. In essence, the question of whether an aspect of the system needs to be presented in the diagram is a matter of whether an external document is required. If there is no external document, what purpose does the element within the diagram serve and how might it be combined with other elements? This question has helped refine our scope of the diagram above and can even give insight into the nature of the component in question. A component without a supporting document may need to be rethought, which in turn can help change and improve the structure of the diagram.

Conclusion
While the above diagram and documentation method is by no-means perfect, it has shown itself to be a useful step in the right direction. As the game continues to grow, the methods for communication will as well – it is our hope that the aforementioned benefits of draw.io and integrating system diagrams with external documentation will prove a strong foundation for the changes that are yet to come.

If you're interested in hearing more about our process, the benefits of diagram integration, or have your own suggestions – be sure to tweet us @SpookhouseGame or send us an email: hiddenpizzadev [at] gmail [dot] com.

Until the next post, stay spooky.

- Kees Luyendijk
Design Consultant

P.S. Neither I nor anyone else on the Spookhouse team has any relationship with draw.io other than being happy and relieved diagram-making users.