I'm not gonna post any more spoiler-ish stuff here, but there's still some dev things I can share.
TestingAs a one-person (and before that, two-person) developer, one issue that's always hard to deal with is testing. Having worked at big and small studios, I know how useful a skilled testing department can be. I also know how expensive they are and how hard it is to find good people.
Instead of all that people-related stuff, I usually try to figure out a way to test the game myself. Without actually sitting down and playing it forever. One common technique is to create an autoplay or 'soak' mode where the game can basically play itself. This lends itself well to procedural puzzle games and is what we did for Helsing's Fire. I wrote a simple bot that could play the game flawlessly and we set it running overnight during the last few weeks of the project. This was really useful in tracking down holes in the puzzle generation (finding unsolvable puzzles due to a logic bug somewhere), and plugging memory leaks (a common point of failure for iOS games).
Papers Please has hooks to do something similar. I could write a bot to move the mouse/click buttons, group these actions, combine groups, build scripts, etc. Some of this work was already done to automate the trailer capturing. But to take it all the way to autplaying would actually be a lot of work. And at this point I don't even want to test these things. What I really want to test is the high-level progression, story elements, and money balancing.
So instead, I split out the game's logic from the UI and built a separate fast-play UI that uses the same logic engine:
This screen lets me quickly play through each encounter. Either in order for a given day, or skipping around between entrants. It's useless for the tactile UI mechanics, checking animations, gameplay pressures from the small desk, etc. What it's great for though is testing the story and progression. And since I'm implementing the full game's story now, this fast-play mode is critical for experimentation.
When the story implementation is done I'll extend this mode to full autoplay for balance testing. I was never quite sure how useful this would be, but seeing
metasynthie's posts about play style gave me the needed kick. Using some basic rules about what to do for different encounters, I'll script "play style" bots and send them through the game. One bot may deny all Kolechians. One may make a mistake on the first new rule encounter and never after. One may deny everybody. If I build enough of these simple styles, I should be able to set them loose to get a feel how the game will balance out for different players. This should also be a good way to incorporate an "easy" difficulty for the less-skilled styles.
StoryMost of the story threads are done so now the task is to arrange them (in spoiler-avoiding low res):
Right after taking this picture I copied everything into a spreadsheet to make editing easier.
My typical process for designing high-level game progression goes something like this:
1. Create a bunch of little pieces.
2. Make a grid.
3. Fill the grid with pieces.
From the very beginning I've been creating little pieces. For Papers Please a "piece" is an encounter, a character, a story thread, a document idea, a puzzle idea, an attack method, etc. I've got a lot of these and now is the time to arrange them. I want to front-load some cool stuff to hook the player, expand on longer stories in the middle, add new elements to maintain interest, and ramp things up to a climax at the end.
Once the initial pieces are laid out, I can easily rearrange them or add new ones to fill the gaps. I really like this part of development because it's when the whole game comes together. It's also hopelessly formulaic. I've tried designing by feel before and unfortunately it just doesn't work for me. I find it much more natural to impose a hard structure and systematically break problems up into small pieces, then combine them afterwards.
Developer
