Recently, I posted about a Kickstarter campaign for Read-Only Memories, a new cyberpunk adventure game recently successfully funded on Kickstarter. In the game, players will become a young journalist trying to make it in Neo-San Francisco. One day, a package arrives in the mail from a close friend, who has since had to leave the country. This package contains a beta version of the latest ROM, which is a device that has replaced personal communication devices. The game is set in a futuristic dystopia not unlike that found in Snatcher, to which the game pays homage. The creators say that the game will focus on current social issues, with a particular focus on queer characters. I wanted more information about the game, so I shot the Kickstarter account a quick message asking if I could interview someone, and got a friendly response from Ted DiNola, their Lead Engineer.
As Lead Engineer, Ted DiNola is in charge of building up the technology they are using to create the game. This means he spends a lot of time programming, as well as talking with other team members to make sure the team can do all of the things they want to and keep them up to speed on the scripting system they are building to let them craft interactions and dialogue. Ted says that later on, he will be moving into more of a design role, helping to use the scripting to make the puzzles and scenarios players will encounter.
DHGF: What got you interested in working on ROM?
TD: I had already been interested in starting to build adventure games using Unity, and through a good friend at GaymerX, became aware of the project and the idea behind it. As an intersectional and socially aware game, featuring LGBTQ characters without being directly about the issues facing LGBTQ communities, Read Only Memories struck me as a very important game.
There’s definitely a lot of challenges here, particularly in making sure we work hard to make sure we represent the groups our characters fall into properly. Games often deal with gender and sexuality pretty badly. You can customize your model, and the game may use the right pronouns, but most of the time the game feels like it’s written for a single perspective–usually for heterosexual males. We’re working to build something where the player can feel like the game is actually talking to them, not just filling in the blanks in a mad lib.
DHGF: Why did you decide to go with Unity as a game engine? How do you see that affecting the game?
TD: I’ve been working with Unity as one of my main development environments for nearly four years, which means that I can get around its weaknesses, and its strengths fit our needs very well.
We had a strong desire to be able to put Read Only Memories on as many different platforms as possible, without the overhead of porting to each platform individually. Unity’s a pretty fabulous solution for this, and outside of a few platform specific bits related to input, performance, and accessing native device functionality, we get away with a single code base. This means that whether you’re playing ROM on your computer, your phone, or a console like the Ouya, you’re getting the same experience.
In addition, Unity is extremely powerful as a content creation tool, and allows us to build out the scenes of Neo-SF directly in the editor. Artists and musicians are able to drop their work directly into the game without needing an engineer to hook anything in, or add it to a manifest. Being able to actually grab something and move it around, tell it which animation to play, and hook it into a menu button without code or a scripting format is really satisfying, and making changes is fast.
DHGF: Tell us more about the new scripting system you all have created.
TD: We’re building a system that was heavily inspired by Twine. Twine’s node layout is a perfect way to represent complex dialogue and trees of interaction, and we definitely wanted to have a system where writers could easily lay out and modify those parts of the game.
Into the mix we’ve added a lot of generic, extensible systems in Unity that can parse it on several levels. Ultimately, we have a tagging system that can recognize commands while text is being displayed, and do things like play animations and sound, change the speed and pacing of our dialogue, or trigger events when the game runs.
While a lot of what we have right now powers systems specific to ROM, the core of it is very compact, and is designed to allow other developers to eventually plug in their own game systems and add their own custom functionality. While we’re still not quite focusing on that part just yet, we definitely want to take the system and make it available so other people can use it to make great games.
DHGF: How do you see the scripting system affecting the creation process?*
TD: Many times I have seen smaller teams get bogged down because a single person becomes a bottleneck for getting new content into the game. By powering most of our gameplay logic, interactions, and events through scripting, we enable anyone on the team to contribute to building out the scenes and dialogue in ROM.
Our scripting system also enables a waterfall style approach to scene creation. Writers can build out the basic dialogue, with the different nodes of the dialogue tree and the choices the player makes to navigate it. Designers can then go in and add the tagging that acts like set direction–coloring things for emphasis, adding in pauses and pacing, and triggering music, sound effects, and animation cues, or add in the game logic that makes the world have real cause and effect.
DHGF: Describe your process for creating the puzzles.
TD: We’re trying hard to make sure the puzzles and obstacles come from the story, and not the other way around. The first part in coming up with puzzles is to look at what the player’s next goal is, and what environments that’ll take them through. We’re building up a Universe Bible for the game that covers everything: currency systems, organizations, technologies, current events, and individual characters.
Taking those, we can then start to build up an appropriate puzzle. For example, let’s say the player needs to find someone in a crowded club. We could have one of our more stubborn characters there, and the player needs to do something as simple as navigate through a dialogue tree to either sweet talk them or annoy them into tossing them some information. Maybe to add a level of complexity, we can make the player realize that what the character really wants is a drink, and that by using cues from the conversation, we can figure out what their favorite is, grab it from the bartender, and mellow them out.
By fleshing out all of the pieces of our world, we can make puzzles that feel like you’re actually interacting with that world, rather than doing the same “use object on other object, bring object to person” over and over.
DHGF: A lot of adventure games suffer from what is described as “rub two things together” syndrome, where unrelated items combine to resolve puzzles. Has that been a concern during the development process?
TD: That kind of stuff is always a concern, of course. That said, I think a lot of those puzzles were a product of the time they were made and their intended audiences. Players used to be more than happy to get stuck on something, when your game was the only one they had available for weeks or months at a time, and so designers could get away with some really weird stuff. Today, if a game gets frustrating, people are more likely to put it down and find something else.
The biggest tool here is keeping things simple, and being careful when we decide to embellish an obstacle a bit. There’s definitely a fine line between keeping players challenged so they get a sense of progress and accomplishment, and making something too esoteric or convoluted. I definitely want us to have some more difficult puzzles for players who want them, but we’re trying to make sure the obstacles for the main story line aren’t going to be frustrating, and that means keeping things simple–if you have a match, you’re probably going to light it, not scrape the top into powder so you can glue it onto a picture to give someone a red mustache, and use the stick to pick a lock.
DHGF: What is is like designing a game for multiple platforms? How do you overcome differences among the platforms?
TD: I’ve always found that it’s important to embrace a platform’s limitations and work within them, rather than trying to shoehorn things in. On a computer, you can get away with having deeper menus, and having more information on screen at once, but shrink that down to a mobile phone and you end up with a cramped experience.
With the scripting system, and our core tech, I’ve tried to keep things very modular. The game knows that there’s a place to draw the scene, a menu that lets players choose what they’re doing, and a place to write out text for descriptions and dialog. On a computer screen, TV, or large tablet, this can look mostly the same, but for smaller devices, we’re able to switch out the way each of those pieces looks and feels.
Some things, like handling input, are an easier challenge. Everything in the game has been built from the ground up to be usable with directional input or with cursor input. On the PC, hovering over items you can interact with will highlight them with the mouse, or you can navigate them with the arrow or WASD keys. In the same way, dragging over the screen on the iPhone highlights things, while tapping on something selects it immediately.
UI is generally a bigger concern. With the modular system we’ve built, trying out a new layout isn’t as terrifying a prospect as it’s been for some of the projects I’ve worked on.
DHGF: What has your experience been with Steam’s Greenlight service?
TD: It’s still pretty early on, but so far most of the comments and feedback has been positive. The pessimist in me is waiting for us to start getting some negative attention as we make the rounds, but I haven’t seen it yet.
DHGF: What made your team decide to go DRM-free?
TD: Because I’m crap at writing security code.
Okay, not really. We play games, and we want people to be able to play their games, ours included. I’ve had games that ended up being heavily pirated, and while your first thought is “They stole our game!”, the reality is if they stole it they were most likely never going to buy it in the first place. Adding in DRM almost never makes it harder for people to do that, while making things trickier for the people who actually DO buy your title. Meanwhile, at least the jerks who stole it are playing it, and maybe someone looking over their shoulder will want to buy it for themselves.
DHGF: What is the biggest or most important thing you want players to take away from the game?
If we manage to do it right, then hopefully we’ll have made a game that can help broaden the types of characters that more traditional studios think to put into their games. I mean, it would be nice if AAA studios could have a gay character who didn’t have to be Jack from Will and Grace, or if they could make it so when you choose a female protagonist you aren’t treated like a man–unless the player wants to be!
If we do it wrong, then I hope we do it well enough that it inspires people to do better than us, so that the consequences are the same: more characters in games that people can relate to, without having to be a heteronormative dude.
Personally, I’m looking forward to seeing the updates on the Kickstarter page for this game and for its eventual release. I think Ted, James, and the rest of the crew have a very solid plan for the game, and I can’t wait to see the end result!
Leave a Reply