What Went Wrong
To preface, this was something we got both wrong and right. When I was creating the game for the Mac and PC in Flash, I didn't consider the mobile development at a later date, which I really should have done. Consequently, I didn't consider things like RAM use or optimization. Since all of my testing was done on desktops that could handle the game easily, these issues weren't even on my radar.
When porting to low-spec devices, it's not great to dump a lot of video into RAM all at once, so we had to reassess at times how the game was built. Now that we're working on the sequel, we've got the chance to make amends for my mistakes there, and we're building with the future of the game in mind.
2. Puzzle Refinement
As I have mentioned, our process involved prototyping before we went ahead and built the final game; this applied to all the stand-alone puzzles also. But in one case, we weren't as rigorous as we should have been when we transferred the game from wireframe to real models.
There's a book in the bookshelf that offered clues to a locked puzzle, which seemed to work fine in the wireframe. When everything was simplified and the book was more noticeable, the answer jumped out at us more clearly.
When we were building the final set, we added all sorts of details and made the book fit with the rest of the bookshelf nicely. However, this process made it became less noticeable and the player was subsequently less likely to find it.
The extra details that were a natural part of making a real life model of the page (the details around the borders, for example), became something of a distraction and sent players down a different line of thinking. We thought we hadn't changed anything, so we didn't need to worry about it. But it became apparent afterwards that people were being misdirected. In the future, we'll be making sure something like this doesn't happen and conduct tests at all stages even if we think a change isn't a major one.
3. Getting the Most Out of Our Materials
We are really happy with how the overall model turned out, and the sense of depth that was created as you move around the house. But I would have liked to extend that same depth to the visuals of the stand-alone puzzles even more. Every puzzle you see was also built out of paper and card.
However, I think we could have gotten more for our money with this process. The models we built were reasonably flat, and so the main sense of depth came from the shadow underneath the raised planes of paper. For the next installment, we're going to make them "pop" a lot more and really make you feel like it's a physical object in front of you. The whole idea is that this should be as tactile as possible.
4. Underestimating the Technical Challenges
In developing this game, it was priority for us to be ambitious with our method. By its very nature, that meant that we couldn't plan for every outcome because we didn't know how it would pan out. A few examples of this happened when we filmed the model. For example, I wanted the player to move smoothly inside the house, with the front of the building fading away to reveal the interior. As such, I made the front of the house detachable. In my head, it all made sense.
While Tom was filming, we could swoop in and remove the front of the house and then he could zoom inside. We would then edit out the frames where we appear. But when filming by hand with a wobbly model made of card, it suddenly -- and somewhat unsurprisingly -- became a tricky prospect.
The front of the house had to fix tight enough to stay on. This meant it needed some jimmying to take it off, by which time Tom had subtly moved the camera while we'd subtly moved the entire house. Then we had to do the reverse when you exited the house, putting the front back on as accurately as possible to cut back to the outside shot. Needless to say, we couldn't perfectly match everything up, and it necessitated an unplanned day or so of After Effects work to merge the scenes together.