Pistol Shrimp and the importance of owning what you make

Pistol Shrimp was established by a group of veteran Toys For Bob developers who had learned the importance of owning what they make through first-hand experience.

Speaking with GamesIndustry.biz, two of Pistol Shrimp's four co-founders Fred Ford and Dan Gerstein say it's an important consideration because while the medium itself has changed tremendously in the decades they've been making games, some things remain largely unchanged.

"I've seen it in many stages and many guises, but one thing that's pretty constant is publishers tend to want to keep everything they can [in exchange for] the money that you get from them," Ford says.

Ford has been involved in legal disputes for control of the sci-fi strategy series Star Control he created with fellow Pistol Shrimp co-founder Paul Reiche under the studio name Toys For Bob.

While working for Crystal Dynamics in the '90s, they built a long-term tool suite and pitched an IP that was never picked up. Since they were employees, Crystal Dynamics technically owned both, which became an issue when Reiche and Ford stopped working with the studio.

"When we separated from them, not only could we not have our IP, but we knew they were never going to use their tools and it was pretty clear our IP was just going to languish there as well," Ford says.

"So we asked them can we have these back because you're not going to use them? And they said 'Sure, for $1 million.'"

Fortunately for the newly independent developers, Crystal Dynamics came back shortly after saying it needed their help with a matter, giving them the leverage they needed to get their tools and IP back as they struck out on their own as Toys For Bob.

Ford says the IP in question served as an inspiration for a key part of Toys For Bob's 2011 hit Skylanders, but the benefits to the studio were not as large as you might imagine considering Toys For Bob accepted an acquisition deal from Activision in 2005.

There were other problems with lack of ownership. Toys For Bob had been relying on Criterion's Renderware middleware when it was working on a contract basis for Activision, but after EA acquired Criterion (including Renderware), Activision refused to include its rival in the development pipeline and insisted on the company dump it. A similar thing happened when Microsoft acquired physics engine middleware Havok.

Gerstein says the studio learned its lesson, even though it was already fortunate to be working in a way that made such switches less painful.

"Even though we had to switch out parts and move the bricks in the building, so to speak, the people working in the house maybe didn't notice as much. We were able to keep a lot of stuff because we put our stake in the ground and said, 'This is how our game logic works, period.'"

After years of working with the Toys For Bob toolset to build it out as needed and a team of developers at the studio who tended to stick around for many years, Gerstein said the company had built up a team that worked especially well with the tools it built.

"We were able to go from Skylanders: Spyro's Adventure, which was a Wii only title, to the next year shipping Skylanders Giants multiplatform all within the span of a year because we had built up a technological… what's the opposite of debt? Cache? We were able to build a lot of stuff and spin it into more things and that became so much easier because we got to keep what we had already done."

But as the Skylanders series progressed, Toys For Bob alternated installments with Vicarious Visions, which had its own tools. Gerstein says in seeking to unify the series, Activision mandated that Toys For Bob drop its own tools in favor of Vicarious Visions'.

"We were able to build a lot of stuff and spin it into more things and that became so much easier because we got to keep what we had already done"Dan Gerstein

"When we started using Vicarious Visions' tools, we lost all of that [technical cache]," Gerstein says. "And we lost all that institutional knowledge and had to learn how to do it a different way… The initial transition was pretty rough because we felt like we had solved a lot of problems. And if we had license to do it the way we thought made sense, we probably would have kept on going."

All of those experiences have informed Pistol Shrimp's approach to game development.

In his waning days with Activision, Ford received a conflict-of-interest waiver from the publisher so he could start working on the next conceptual evolution of what he thought Toys For Bob's tools could be, and that tool (which he calls Simple) is how the studio is building its Star Control follow-up The Ur-Quan Masters 2.

As for the engine underneath the thing, it was up until recently a "homebrew" engine the team planned to stick with for as long as it made sense. A switch to something else – be it Unreal or Unity – was always a consideration eventually, and Ford had designed the tools with basic engine functions in mind so it could be adapted wherever needed.

"We've always been leery of third-party stuff," Ford says, "not just because it can be taken away from us, but also because it tends to give you everything and the kitchen sink and the gas station down the road and the city 50 miles away. It's easy to lose focus on what you're making because of all the things you can grasp, but maybe not master."

While Gerstein says it's great that engines like Unity and Unreal are making game development more accessible, he is less thrilled with the effect ubiquitous corporate solutions for game development have on developers and the games themselves.

"[A third-party engine] tends to give you everything and the kitchen sink and the gas station down the road and the city 50 miles away"Fred Ford

"One thing I don't love about these monolithic tools is they try to solve everything for you," Gerstein says. "Regardless of the corporate control, it's really when you think about it one person's idea of how things should be done. And as we're seeing with all technology, we're still learning better and better ways to do things.

"So if you try to make a monolithic package that assumes it knows how every single person is going to use it, it's kind of like creating a universal paint brush and saying, 'You get one paint brush.' Well, what if I want a fan brush? What if I want a thin one?"

As an example, Gerstein says he's particularly not a fan of visual scripting used in Blender and Unreal's Blueprints, among others.

"I have really strong feelings about visual scripting and I feel like it is a mistake to do that," Gerstein says. "Some people like it and that's fine, but the point is at least we're allowed to have different viewpoints on it.

"But if a software package comes along and says, 'This is your only entry point; have fun with visual scripting,' then you're going to turn off a lot of people, and you're also going to train people in a very narrow skillset and it starts to feel like a production line and a factory… These giant packages, by trying to solve problems for everyone, start to feel like, 'I'm not really learning how to make a game; I'm learning how to play with all the bells and whistles that I've been given in this box.' And I never think about, 'What other things could I want? What other things could I have?' It gets so rigid.

"From a player's standpoint, my running joke is that I can smell an Unreal Engine game just when I look at the UI because it makes certain things so easy to do, and some things so much harder. Why would you take the path of most resistance? But then it starts to normalize games and you start seeing it. 'I see that camera motion. Yup, that's the default motion from Unity with a few tweaks applied to it.' or whatever. I love that people can get up and running, but it kind of pigeonholes you and puts you in a little box to work in."

Be that as it may, Pistol Shrimp has found an external engine solution for Ur-Quan Masters 2, and it's one that people have been talking about a lot lately: Godot.

Ford's brother and fellow Pistol Shrimp co-founder Ken had been putting together the homebrew engine the studio was working with, but recently retired. Ford felt he'd be spread too thin if he tried to take over that part of development, so Gerstein suggested taking a look at the open-source engine Godot.

Ford took a look, and within a month had the gameplay fully ported to the engine, just in time for Unity to announce its Runtime Fee and send interest in Godot skyrocketing.

"I would say Godot is more spartan compared to Unity," Ford says of the engine. "That appealed to both me and Dan. It's also C++ based and open source, and we're making our stuff in C++. I had done a Unity port of our gameplay really early on, but the fact that was just more difficult to get the C++ stuff inserted into Unity – it was just more trouble from a development perspective. Godot was just an easier path for us to follow."

"[Godot] doesn't really try to solve a lot for you, but it gives you a lot of options for how to do things"Dan Gerstein

Gerstein says the switch was made considerably easier because of the development principles the studio had embraced.

"So much of the work we've done is preserved. We learned our lesson… When we had everything up and running in a month, it's because we had invested a lot into our own technology – not just tech but the actual game we're working on – and the work I put into Ur-Quan Masters 2 was 100% portable and would work in our custom viewer. It would work in a Unity viewer if we made one, and now it works in Godot. We had not done anything that bound ourselves to work in any particular engine."

As for how Godot is to work with, Gerstein says it naturally feels like an open-source project. Because it's being made by people putting their time into it for free, there's a vast disparity between the parts that are more finished and polished and the parts that haven't yet had anyone give them particular love.

"One thing you'll find that's quite different is it doesn't really try to solve a lot for you, but it gives you a lot of options for how to do things," Gerstein says.

It also might be a challenge for less technical users, he adds.

"It's not user-unfriendly, but it expects a little bit more of the user and it wants the user to learn a little bit more," he says. "But it works quite well; you just have to get over some of those learning hurdles. If you're more artistically/designer-minded, you have to become a little bit engineering-minded, and a little bit will take you far.

There's also a great community behind it, he says, with "lots of wholesome intent" and support for it just because it exists.

"Not to sound overly sappy, but that gives me warm fuzzy feelings and I think that attracts the right communities who are here for the right reasons," Gerstein says.

As for what he would tell developers interested in picking up Godot, Gerstein is clear.

"You're not alone," he stresses. "There's a large Godot community dedicated to [providing advice for devs picking it up]. Their own Discord has set up channels for it. It's literally like refugees coming in, they don't know anything about Godot but everything about Unity. So there's this whole microclimate of Unity people coming to Godot."

Beyond that, Gerstein suggests developers just maintain their ability to adapt, when possible.

"I know agile is such an overused term, but the agility is so valuable," he says. "Agility is a strong suit. It doesn't mean 'don't commit to anything,' but if you can do things in a way that is portable, your life is going to be easier.

"For a first-time person, that might be too hard to imagine. But so many game assets can work in different places as long as they have the right implementation. It ain't so bad to learn how to do that. But if you buy in so deeply into a proprietary technology, it can be hard to dislodge yourself from that."

He notes that relying on certain technology from proprietary engines – particularly in graphics – can be committing a developer to either going with that engine or facing a painful reworking to get up and running with an alternative.

"We maybe find a little more freedom because we're gameplay-focused, and that's not a one-size-fits-all," he adds.

As for Ford, his advice echoes Gerstein's, but applies it to basically every decision in game development.

"One size doesn't fit all," he says.