scriptwelder: Developer Interview

Usually getting an interview with a developer is no big deal… an e-mail here, some compliments there, a basket of fine cheeses. But when you’re dealing with a developer like horror maestro extraordinaire scriptwelder, things get a little… different. You need to make sure it’s within three days of a full moon, and you’re alone in the house. Don’t tell anyone what you’re doing. Make sure you have a four foot length of red yarn, two mirrors, a candle and a way to relight it if it goes out, and a room with windows you can cover. The room must have a lock outside.

At fifteen minutes before midnight, turn off all the lights in the house, and set up your laptop or tablet on the floor of the room, with your screen displaying your questions. Place the mirrors facing one another, then light your candle. Leave the room, but do not turn your back on it. Once you’re out, shut and lock the door, then tie your red yarn to your wrist and the door by looping it around each three times firmly. Knock six times, then stand back, and wait. If at any time the doorknob tries to turn, quickly untie yourself, and leave the house. Don’t come back until after dawn. If the candle goes out, hold your breath until you relight it.

But if you hear typing, sit quietly on the floor and wait until dawn. Once the sun has come up, you may untie yourself, unlock the door, and go inside. And that’s how I got this interview! Sure the constant whispering that keeps me up at night and fills my subconscious with shuddering, twitching visions that won’t go away, but that’s just how games journalism works, tender reader!

A lot of your games tend to have horror elements, but good horror isn’t necessarily easy to make. How do you come up with scary situations that you feel are actually frightening, and implement them into your games?

scriptwelder: In visual media like games you can basically have two types of “scares”… so called “jumpscares”, and atmospheric, fear-based scares, which go much deeper. Making a good horror game requires a proper mixture of those elements. Many titles fail to achieve that mixture, usually because developers just tend to cram as much jumpscares in as possible, sometimes to the point where things stop being even slightly scary and start being plain annoying. Some people find jumpscares cheap, but I think they are cheap only as long as they have next to no effort being put in them. Everyone can make a screaming face that pops out of nowhere, but is it really scary? In that case, a train going in the opposite direction to our train that suddenly swooshes by our window is scary.

No, making a good jumpscare requires a lot of good background, a lot of setting up and building atmosphere. And with a good set-up, you don’t even need a jumpscare, because fear is what is in our heads, not what pops up on the screen. And no, switching off lights and forcing players to crawl in darkness is not proper atmosphere building. Fear is born in our minds and authors should just give some fuel to that process. Think not “what should I show to scare the player” but rather “what should I NOT show to scare the player”. Example? You first see a child that plays by an open oven and half an hour later there is a black cloud of smoke coming from that room and you smell something burning. That is fear.

What’s the most challenging part of making games? Alternately, if you had some sort of magic game making fairy that lived in your closet, what part of game development would you be glad to foist off on them so you didn’t have to do it yourself?

scriptwelder: Those are two completely different questions, because if something is challenging that doesn’t necessarily mean I don’t want to do it. Making games is hard work, sure, but it’s also fun. Facing challenges and overcoming them is what makes every developer better; they’re real-life experience points.

But as for magic fairies… definitely debugging. The more complex the game gets, the more bugs are going to be in it. Hunting for those bugs gets longer and a lot of time is wasted on fixing things. What’s worse, at some point fixing one thing usually breaks several others… which might not be obvious until another debugging…

You’ve experimented with other types of games before, with titles like Excavate! and 400 Years. Do you think you’ll branch out into other genres again? Is there one you’d particularly like to try or revisit with a new game?

scriptwelder: Yeah, why not? 400 Years always was one of my favorite projects, and I think at some point I might return to that concept. Additionally, I’ve always wanted to make an adventure game that plays a bit like platformer, so that might a future project.

Obviously I’m currently the “point-and-click games guy” but I never intended to limit myself to this genre. I’ve got a lot of stories to tell, and some of them will require different approaches and mechanics.

One of the most annoying things a player can encounter in any sort of point-and-click or adventure game is bad puzzle logic. How do you come up with the puzzles for your games, and avoid having those that are too vague, simple, or obnoxious?

scriptwelder: There is no simple answer for that. Or maybe there is, and I don’t know it. I make mistakes and I learn from them. People say there is a lot of annoying pixel-hunting in the first Deep Sleep, and believe me there was a lot more of those before it got its first patches and updates.

There are also things that make perfect sense to me but turn out to be totally strange to people in other parts of the world. For example, in Don’t Escape 2, there is a coin that nobody in the USA seemed to find a use for. For me the answer was simple… the shopping cart is held in place with a chain, unless you put a coin into it. It’s something normal in all malls in Poland, and probably in most of central Europe, but it turns out to be a completely foreign custom in the West.

Coming up with logical puzzles isn’t easy, and asking yourself if it’s intuitive to you is not enough. If you’re making a point-and-click game, double-check your puzzles with friends or playtesters and see how they try to solve them. Sometimes people come up with solutions that you haven’t thought about that are even more logical than yours.

Each of the Don’t Escape games have been different in various ways, like the more elaborate plot and sci-fi setting of Don’t Escape 3, or the time-centric puzzle mechanics of Don’t Escape 2. Are you playing around with any significant gameplay changes or concepts for the next game in the series?

scriptwelder: I like my titles to be different from one another, to keep them fresh and interesting, and that applies to the upcoming Don’t Escape game. In terms of gameplay it will be similar to Don’t Escape 2, which seems to be the most successful title in the series. People liked the time management, and having multiple solutions to problems. Of course, there will also be some new mechanics and concepts. The one I’m currently experimenting with is limited inventory capacity that seems to be a normal thing in roleplaying games, but so much not in the point-and-click genre. I hope it’s going to force players to plan their actions and choose what items they really need rather than simply relying on the “use-everything-on-everything-else” approach. As for the setting… if you’ve been following production screenshots you can probably tell it’s going to be somewhat post-apocalyptic… and that’s all I can say right now!

Making games already takes a lot of time, money, and effort. The next Don’t Escape game won’t be for the web, and according to your blog, it’s going to be much longer than the others in the series, to say nothing of being developed for Unity instead of Flash. What sorts of challenges are involved in planning and developing something like that, for a broader scope and different platform?

scriptwelder: It’s a huge challenge for me, because I haven’t tried making a game this big before. It needs a completely different approach, both technically and in the matter of design. As for technical problems, switching to Unity wasn’t easy since I haven’t done anything in Unity before. Flash, which I previously used, is completely different, and a lot of programming concepts are totally “turned upside down” in Unity compared to Flash. Luckily, it’s not impossible to learn, with a little effort and thanks to all the great tutorials and detailed documentation out there. Moreover, I think it’s a good change that will definitely help me develop more games in the future.

As for designing and planning, it’s also a challenge, because I’ve only created shorter titles so far. Longer games require a different approach, and more long-term planning. You have to be able to break the work apart into small chunks that are comprehensible, but at the same time, you have to be able to see the bigger picture of the whole game. Those are obvious things when it comes to designing large games, and I know I might sound trivial here, but they’re new and unfamiliar to me!

Finally, is there anything you can tell us or tease us with about this upcoming Don’t Escape game? Don’t leave your fans hanging!

scriptwelder: I don’t want to spoil too much since I’ve already told you a lot of things. It will be based on a “classic” point-and-click foundation with a sort of post-apocalyptic setting, time management mechanics, and various solutions to problems. Also, it’s not going to be linear… some things will happen in one playthrough that won’t happen in another, for example. I’m not saying it’s a roguelike of point-and-clicks… but it might be very close to this idea.

~~~~~~~~~~~~
Writer: Dora Breckinridge / Dora has been writing about games for the better part of a decade, and playing them for even longer, using the glow of the monitor to keep her warm in the frozen wilds of her native Canada. Her website is here!