Interview: Fleet Hackers’ Ruben Tipparach

This week, NerdQ’s Erik Meyer caught up with Ruben Tipparach, the Creative Director of Fleet Hackers: Breach of Contracts, a VR game in development by Vacuum Door. Ruben’s been busy in 2017 with two open demos and a just-released trailer, not to mention his ongoing project work, and watching his team refine game elements over the last few months has been exciting.

Erik Meyer: How did Fleet Hackers initially get started, and how has it changed as a group effort since that time?

Ruben Tipparach: The inception of this idea started in late 2012, as a modern version of Starfleet Command with the 3D spaceship movements of Homeworld.

Back then I wrote my own game engine in XNA/C#.

It had basic mechanics such as flight rotation controls, altitude changes, enemy targeting; it even featured a primitive subsystem simulation.

I still think that the original idea was my favorite, but it didn’t quite have enough appeal, and it didn’t truly incorporate the complexity in navigation and fleet controls that I wanted.

The next iteration was in Java in the JMonkey engine, developed as a final project for my college senior semester. A friend of mine introduced me to Unity back then, but I somehow didn’t quite get it. It was also mostly just JavaScript back then. This version wasn’t all that different from the XNA version, but it featured enemy AI and rigid body physics.

In late 2013, I met with Irina, the first concept artist to work on the project, and we started developing more of the story elements.

And the Unity versions were born.

For a few years, it stayed that way, a simple point-and-click game to move ships around. Different gameplay mechanics were tested with the ships having different behaviors and the UI going through a massive number of iterations in a futile attempt to create some kind of breakthrough in intuitive 3D fleet navigation.

2015 was the pinnacle of that vision. One of Ivan’s ships is featured here, The Lone Ranger; it was modeled in a week and is still used today, albeit somewhat modified with its interiors fleshed out to accommodate VR.

2016 came along, and I moved to Fargo. By summer, I had grown frustrated in my attempts to figure out a decent mechanic and poured every bit of my time into the RTS version that has become the backbone of our space simulation.

This simulation was an effort of over 6 months in studying the physics systems used to drive cruise and cargo ships at sea, as applied to 3D space environments. Game testing was difficult since we felt that the prototype had little appeal to someone who was not a huge fan of RTS. The summer 2016 version was also the first version where I started working with others besides a concept artist. We recruited sound engineers, programmers, voice actors, and animators. A lot of them seem to not be quite up to the challenge, and so we still only comprise a single programmer, a concept artist, a voice actor, and 2 sound engineers who have done the bulk of the work.

The big breakthrough in VR came along when we threw together an Oculus Rift test:

As it turns out, we had accomplished that full 3D immersive spaceship feel and solved our RTS issue by allowing players to navigate in full 3D.

As far as group dynamics were concerned, we all turned to strict scheduling, disciplined consistency of content development, and constantly evolved our management models to be more efficient.

EM: You’ve worked on projects besides Fleet Hackers; give a rundown of other game projects you’ve toyed with. What challenge do you find in each?

RT: I made a little demo reel of my adventures in Unity back in 2015:

And there was this little thing I worked on with an old friend for a couple weeks:

A lot of what I do in terms of game development (besides Fleet Hackers), has been just for my own enjoyment in my spare time. I’ve added quite a few games to my list since moving to Fargo, most of which are available on GitHub.

This Includes:
– Seagull Simulator (MMO): you play as a seagull with your friends.
– Sputnik: an incomplete project about playing as a probe that needs to plot slingshots to complete scientific objectives. It’s a turn-based game and doesn’t use actual physics.
– Cow vs UFO: a game that a friend described to me over the phone, so I decided to throw something small together.
– Valkyrie/FishCommander: designed to be a small-scale simple RTS. These utilize similar code base and were the basis for the Fleet Hackers RTS version. Since then, it has been updated to Fleet Hackers: Taccom for use as a mobile/cross-platform game.
– Christmas Island – a traditional Age of Empires-like game about North Pole elves at war before being united by St. Nick. They build magical contraptions and try to eradicated the other clans in order to control the island.
– Unnamed Time Travel Game – I haven’t settled on a name for this yet, but it’s a game about causing time travel paradoxes and requires quantum suicides in order to advance in the game.

The biggest challenge with any game is making it feel like a game and not just a shared mesh of interesting mechanics. I mostly dabble with different genres to test out implementation ideas that would otherwise slow down a bigger project.

EM: What do you see as the big challenges for VR, as it stands currently? Where do you see VR going?

RT: The cost of VR is still too high for many people to pick it up; in contrast, Nintendo Switch offers little innovation but has a lot of similarities with a small twist at a much cheaper price. Looks like it’ll sell pretty well; however, VR is still where the next generation is at.

The biggest challenge is creating an adventure where you could potentially be running around in the game physically, but you’ve got the constraints of a living room to deal with. Hence, designers have tried hundreds of clever techniques such as teleportation, pulling, climbing, sliding, and numerous other ways to get around the movement problem. A lot of these cause discomfort and break the immersion experience. Some games, like Accounting, don’t allow you to move anywhere at all except for the designated area. The amount of time a player spends in VR is also another issue. How do we develop a game so that the players can feel comfortable for 3 or more hours?

I’m seeing VR being used as a very small percentage of its true potential. VR, despite its isolation, can become a huge tool for social games, and not like the Farmville or Game of War clones, but for truly social games where friends across the country can all sit together and watch TV on the same couch, or go on dragon-slaying adventures in person instead of using an avatar on a 2D screen.

To fully utilize 100% of VR, I’d like to see someone develop fully wireless headsets that can track over a square mile, allowing players to go on fully-fleshed-out adventures, climbing over obstacles, fighting bad guys, and encountering real life friends physically or digitally through this huge complex structure that can be modularized and reconfigured for an endless combination of amusement parks. I see VR as a possibly life-changing experience for some people, a kind of premium thrill that truly takes you to another world.

EM: What games do you currently draw inspiration from, and what games do you see as style/concept/design influences?
RT: Fleet Hackers used to be a mash-up of all the cool games we played like Mass Effect, Bioshock, Crysis, Grand Theft Auto, and Assassin’s Creed. They all have an open world-ness to them to a certain degree, with quest structures, abilities, perception of the player’s self, and unique NPC interactions. These RPG/Open World games play a huge role in music, dialogue, and interactivity with characters.

The spaceship mechanics are very different from traditional space games, since I tend to draw from older computer games like Starfleet Command, Homeworld, and Independence War, which all take space very seriously and were all developed before the turn of the century. Less people played these games, and we have kind of hit a dead end in terms of advancements made in the design of their mechanics. One of the major features of Fleet Hackers is the navigation and collision avoidance systems. I’ve studied these games heavily and kind of reverse-engineered, adding my own take on how it would be done with today’s tools and technology.

A planned future feature will be the subsystem and repair mechanics. This is a huge part of the planned simulation model because subsystems will control even the flickering of lights, levels of oxygen, the turning rate, acceleration of the ships, weapon effectiveness, and more. We even consider the ability to just throw a wrench into an enemy reactor, imploding the ship from the inside out. A lot of this comes from Starfleet Command’s design of highly modular systems that make the ship dependent on its balance of energy (in terms of MW/GW).

EM: Name a few well-implemented game mechanics; what defines a perfect implementation of a mechanic versus a so-so attempt?

RT: The ship boarding mechanic I think is what really sells the experience. It has such a huge scope, in terms of allowing a player to hop off one ship and onto another. The state space of things that could happen is huge. I don’t really think there ever is a perfect first try for implementing a mechanic. Mechanics are often simple in my head but are made of many many small parts that I had never thought of. One of the only ways to go about coding something like that is to try to get what I want out as quickly as possible. It’s like a banana that pops into my brain and I gotta get it out before it rots. Once it’s out, we get this skeleton architecture to either redesign or add to. Either way, it’s how we’ve made it work.

Even though I’m the only programmer on my team, a lot of us do a huge share of game designing, Jon Bell-Clement being the biggest influence on how a feature gets implemented, although he probably has no idea (lol).

EM: Design documents usually play a big role in group efforts (as a compass/blueprint for members to look to as they progress); what other elements would you suggest for teams looking to work together on a larger project?

RT: We started with a really rough design document that honestly just looked like a pipe dream game to any studio. Then we threw it away; months later, we realized that over 70% of it had been accomplished. So then we decided to change that model (since it just resulted in us spending the time to painfully write the thing, not use it, stumble around, and end up with what we started out aiming for in the first place).

Generally, I’ll start by pressuring Jon into drawing a 40-something cell storyboard of possible situations the player might get into.
You can play through one of his storyboards here, it’s been clipped so you only get to play through one of the scenarios 🙂
Then, we develop the storyline of each choice. We often try and predict what the player will do and come up with a list of features that we need to get done in order to service that experience. A lot of times, the player might have to shoot his way through depending on what route or choice he makes. This makes the shooting mechanics a higher priority, since there’s a higher probability that he’ll get into a gun fight in this particular story board.

This agile approach comes from how we did design documents back in Minneapolis when I was working for OATI. It would always start with a rough outline, and requirements were filled in after each iteration, prioritizing what was most urgent.

Here is one of our many Twine documents that we use to visualize choices; this one is dialogue specific, but we have a couple more for actual gameplay.

We take a “choose your own adventure” narrative approach but do it loosely so that it becomes an extremely comprehensive game design document in the end. We use ideas that are quickly implemented so that we get the data results to further iterate on, fix bugs, and crunch out as an actual user-generated narrative as opposed to choosing path A and path B. Those paths are still there, but we’ve blurred the lines a little, and we’re currently adding different ways of guiding you to where you’re supposed to be.

EM: What other elements would you suggest for teams looking to work together on a larger project?

RT: My advice to anyone out there who wants to make video games is that it’s all about how fast you can get your idea out and interacting with a player. Demoing your game is an invaluable way to get feedback and motivation on something you’ve come up with. I personally don’t believe in a killer idea developed in a cave by someone isolated for months; I believe in ideas that grow organically as people get to try them out and help realize that amazing vision along the way.

I would say that I’m just a conduit for making video games; the real people who make the most compelling games are the players themselves, and game designers only translate that desire and facilitate a complex feedback loop that helps improve the experience. Using the scientific method and understanding how to make errors without wasting time or money are the core values of Vacuum Door Interactive. We’re not afraid of making mistakes  (our games are riddled with them), but we know the progress shines through.

Author: Erik Meyer

Erik edits content, writes articles, conducts interviews, and draws silly things for The NerdQ. He also produces Planning Session, a comic showcasing dev discussions.

Leave a Reply

Your email address will not be published. Required fields are marked *

16 − 3 =