We talked with Jonathan Chouinard, founder of Oddbreeze, on the release of his first commercial puzzle game, Crew 167: The Grand Block Odyssey. Jonathan shared with us his experience from initial conception to the final production of the game.
Please tell us a little about yourself and oddbreeze.
JC: My name is Jonathan Chouinard and I live in Montreal, Canada. I started making games as a hobby I picked up to keep myself entertained in my free time. In September 2016, I decided to start doing the development of Crew 167 part-time. I started game development under a generic studio handle but rebranded to oddbreeze in 2018 with the vision of creating engaging and amazing narrative video games.
How did you come up with the idea for Crew 167: The Grand Block Odyssey? What inspired you?
JC: When I was looking at what game I wanted to create, I looked at old school games on SNES that I enjoyed when I was young. I replayed Goof Troop which was a game where you had to throw boxes at enemies and find items to let you proceed. But there were also a few block-pushing puzzles sprinkled across the game. Being the main aspect that I liked from this game, I figured I could expand on that idea.
Crew 167: The Grand Block Odyssey seems to blend a unique style of narrative/Sokoban puzzle style of progression. Can you tell us a few things about it and how you came up with this design?
JC: At first, Crew 167 was to be a full copy of Goof Troop, including all the combat aspect and possibly its Co-op feature. However, in the first month of development, I did a playtest of the game with a few local people. Their initial impression was that the puzzle mechanic was great, but the combat didn't feel as polished.
My reflection in the following week was whether to put more effort in the combat to bring up to par. However, I ended up deciding to kill the feature and focus on the puzzle aspect. Focusing on a single mechanic allowed me to think of new ways to expand the mechanic by adding different flavors to the blocks as the game progresses.
As for the storytelling, I love a good story and focus on games that bring that experience. Early on, I knew I didn't want to have a puzzle game where your only reward was a harder puzzle. I wanted to reward the player with bits and pieces of a story. Over the 3 years, the story got more complex and there were cutscenes to close off every chapter. The last addition was the voice over that we recorded for the main characters.
What game development tools are you using and why have you picked this stack?
JC: The stack was simple at the beginning: I used Unreal Engine 4 for the first two years. The year after, I added Wwise because I had a friend that helped me out with the audio design. In that same year, I added Arcweave to the toolbox, back when it was still in preview.
How has Arcweave helped as a narrative/design tool? Which features did you find most useful and which ones you would like to see implemented?
JC: My story had evolved to a point where it was starting to be complex. The premise being kept a mystery, some elements of the story that had to be kept a secret and unveiled at the right time. However, everything was done in Engine at that point. It was becoming hard to understand what was happening and keep track of what the player knew at each step. It was also very hard to have someone else "test" the story and share their thought process as it unfolded.
The board-view of my project in Arcweave allowed me to visualize the connections between elements. I created different Element nodes with story elements. In my case, it was all the different cutscenes, put together in a linear fashion in my Arcweave Board. Then I used the Note nodes to add comments to the story as I was revising it. Each note had a color that I used:
- Red: Thoughts I need to implement or problems I need fix.
- Green: An idea that was implemented/added to the story.
- Purple: Notes to myself about writing. Guidelines and directives to follow to make the game better.
- Blue: More complex thoughts and ideas that are saved for further analysis. To be broken down into smaller pieces.
- Light Blue: Codex idea.
- Gray: Alternate scenario or idea, kept for archiving because the idea was good, but was ranked 2nd or 3rd.
Finally, I used the Components for each Character and every core Area of my game. For example, there is a Medical Bay that is a room you return to at a few occasions. To make the story tighter, I wanted to have the player come to the same environment. By tagging each node with their components, it helped me see how frequent they were and where story holes were located.
During development what was the most complex and difficult challenge you faced regarding game content, mechanics, gameplay or production?
JC: The hardest, and unexpected, challenge of this project was just… finishing. There's always a fine line that you need to balance, between "this section is done" and "this section can be polished further". There's always ideas that you can implement and mechanics you can add to make a better product.
For a long time, it was hard for me to see the end of the project. I had to ask someone with more experience how they manage to just get their game "out". She told me that it was when you were feeling proud of what you've produced. And that feeling only came at the end. It was basically a fight in the dark the whole time until the end. But it finally happened!
What advice would you give to developers that are just now starting to work on narrative/puzzle games?
JC: My philosophy in development, both for the puzzles and the narrative, was to playtest early and gather feedback as soon as possible. Your game will not be amazing after 1 month of development, it will not look pretty. There might even be nasty bugs. It's still crucial to get people onboard early to give it a playtest and gather feedback. That will help you steer the direction of the game.
What did they like? What was confusing? Does the story hold up, or how is the pacing? For example, the narrative of the game went through 5 iterations before going to its final form. And Arcweave helped at putting those feedback into perspective, and to be able to filter all of them. Some ideas were kept and implemented, and some ideas were put away, but it's all documented.
Lastly, anything else you would like to share with us?
JC: Game development is a long process, so it's okay to sometimes feel like you don't have the grasp of it. As a solo developer, it was easy to get stuck in my own head, trying to figure out the solution to my problems. Keep doing small increments and get outside opinion as much as possible. When you look at the final product, you'll be proud that you put the effort in.