Meet ‘SANATORIUM’, a mental asylum simulator where you are a new doctor, but you have no medical license. Your job is to treat patients and try to keep them safe until the end of the day. To do this, you’ll use patient files to assess symptoms and order them into a chart to form a diagnosis and recommend treatment. At the end of the day, your work will be reviewed by your supervisor—and if it looks like you helped patients or made things worse, they’ll let you know!
The game was created by Zeitglas, an emerging game design studio based in Zurich, Switzerland. We interviewed Fabian, one of the founders of the company and here are his awesome insights:
When asked about himself and what made him start a career in games:
After education and a short career in the swiss car industry, I decided to go in a more creative direction. I met my partner Sebastian at the University, where we studied Game Design. Sebastian’s Bachelor project “Sanatorium” received very good reviews and after a year of an internship as a 3D-Artist, I decided to join him to go professional with the game.
Which games studio do you admire the most and why?
We admire in general small indie studios and lone developers who manage to produce great games. Their success is our motivation. Right now I’m thinking of “Dead Idle Studios”, a two-person team that released a breathtaking narrative game called “If On A Winter’s Night, Four Travelers” last year, which gained awesome reviews and which I recently just played.
What are you currently working on (game/feature)?
We are currently working on our first project “SANATORIUM – A Mental Asylum Simulator.”
Can you share with us what the creative process of coming up with a new game is for your team?
We always have some strange game mechanics and unusual settings in our minds. Then we talk about how we can combine them and we make a prototype made with pen and paper to test the gameplay. At the beginning of the Sanatorium game, Sebastian’s idea was to create a game mechanic that allows the player to “work” with patients who have different symptoms. This led to the idea that the player deals with patient files and he has to put different kinds of cards into the files to interact with them.
Once you have a “playable” version, who are the first people you use as beta testers?
We have a public Discord where people can join the playtester channel. Besides that, we have a few very good friends who are always available for a quick test.
After that, do you post a beta of your game on a bigger community/forum? If so, where?
Right now we are not sure about the beta testing. It depends on different cases. If we work with a publisher soon, they could manage this. If we publish by ourselves, we would probably try to build a bigger community in our Discord.
How do you get and document the feedback?
We work with the organization tool ClickUp. In our Discord, we have a Link that leads the playtesters to a feedback form. If they report something it automatically generates a task in our ClickUp. The playtesters can describe the problem and also add screenshots and videos.
How do you decide which feedback pieces to employ in your development?
After the report is in our ClickUp we can assign it to one of our categories. We have “Critical” for game-breaking bugs, “Uncool” for annoying and frustrating stuff, or “Beatle” (let it be) for things that have no priority at the moment, to name a few. This is a good way to set priorities.
Does feedback from fellow gamers or fellow developers count more to you than comments from others?
Definitely not. It’s very important to recruit as many different playtesters as possible. Especially people we don’t know personally are highly welcome to test our game because they are probably more honest than friends.
How do you approach conflicting feedback from different people you trust?
That’s of course a little hard sometimes when it comes to reports about controls, gameplay experience, instructions, and so on because different people have different opinions. We always try to put ourselves in each player’s shoes and try to understand why something is reported. An example in our game: The main part of the game takes place on a desk. But there is too much stuff on the desk to show it in one single field of view, so the player has to look around somehow. We are still not sure about how the player should navigate on that desk. No matter what controls we implement, the feedback is always different. Some players would like to
move automatically when hitting the border of the screen with the mouse. Others like to click and hold the mouse wheel to navigate. And some even like to use the WASD keys. We are right now testing all the different controls and we will probably choose the majority of feedback to decide.
If you could improve the way you gather feedback, what would you do?
I think at the moment we’re on a very good track. The ClickUp method works pretty well with the amount of playtesters we’ve got. If we had way more playtesters we would probably have to find a way to combine or delete multiple reports that affect the same problem.
Subscribe to our blog to read more stories about amazing creators from passionate professionals.