Interview With Jim Mummery Of Edge Case Games, Developers Of Fractured Space Part One

I had a chance to sit down with Jim Mummery, the Chief Creative Officer of Edge Case Games who is working on Fractured Space. We talked about why the team moved from the faster pace of Strike Suit Zero to the slower pace of Fractured Space, how the game evolved into something that resembles a MOBA, and the definition of beta. We talked so much that this interview is being split in two. This is the first half.

You were on the same team that made Strike Suit Zero and a lot of the team is the same. What made you decide to move towards the slower pace of Fractured Space?

Mummery: We have the big capital ships in Strike Suit Zero and they’re roughly the size of player ships in this one. But in Strike Suit Zero you could never fly them. While we were building the game we had to put a lot of work into where the turrets would sit on the ships, how you would destroy them, how they’d move, in order to make them work. Because they’re really large and there are a lot of complex problems in making large ships that you can fly around.

We’d done so much work on it that it occurred to us that it would be cool if you could fly one of these big ships. And we intended, at one point, to make some DLC missions where you could do that. Sadly, due to a combination between how complex that became and everything else it didn’t make it into Strike Suit, but the original idea for this game started there. The idea that you could fly these huge ships crewed by thousands of different people with lots of different weapon systems. That could actually be a really interesting experience.

While we were making the game we were looking at Star Trek and Star Wars and Battlestar Galactica. We started to notice how the battles in those worked and how so much goes on when you get the Enterprise versus the Borg Cube. And it seemed so rich and such an interesting sort of place to be for a game.

The idea kind of grew and grew and we were looking at how World of Tanks had developed. We were looking at arena games rising through MOBAs and everything else and it just seemed to be a really good fit.

So that’s why we went for capital ships and when you go for capital ships, I think there’s a sense of weight and pace that kind of goes along with that. We actually did try to speed the ships up at one point to accelerate how the game worked and a lot of our community kept pointing out that “hey, these have stopped feeling like capital ships now. Slow it down.”

So you wanted to take a large part of Strike Suit Zero and make a game out of it.

Yeah, so much work went into those ships that we spent a lot of time with them and we wanted to take that somewhere. That was a huge part of it. But it was also looking at the battle scenes and Battlestar (which I think is the best reference), where you have big ships with guns and the small ships fighting in-between. That variance of scale, that’s what you think about when you think about sci-fi. And once we’d done the sort of fighter craft flying around and we were done playing games and stuff, the battleship combat was so different from forced movement, forward-firing dogfighting that we felt it was worth exploring.

Did you set out from the beginning to create a MOBA or did it just kind of happen?

Not specifically. One of the early references when we started putting the game together, just from the point of view of “multiplayer arena combat,” wasn’t actually a MOBA. There’s a question there as to whether it is a MOBA or not. I’ll leave that for you to decide. We’re looking a lot at World of Tanks, mainly for how the aiming works and how accurate it can be, and the physics involved, and where you fire your shells, and what you fire your shells at and how that works.

So we looked a lot at World of Tanks, but as the game developed one thing I specifically wanted to bring in was the fact that capital ships have a lot of systems. It shouldn’t be like tanks, which have one gun. They should have a lot of systems. They should be able to launch fighters. They should be able to do different things. And that led us down a path where our “champions,”  the ships themselves, had a series of abilities that needed to be operated by the player. As soon as you get into that kind of realm the controls for the ship move towards something you’d see on a MOBA champion, where you have a set of skills. So that’s kind of part one.

Part two was that we wanted to create a game mode that had a lot of legs. We were aware we weren’t going to be able to create a lot of maps early on. We would have to take our time introducing modes. So when we started adding a proper mode, it would have to be something that could be played a lot. That you could keep coming back to.

We started out with a lot of things. The idea of multiple sectors was something we brought in quite early because it was a great way to resolve geometry issues in space. But if you’ve got two teams, you need to be able to control the space, control the map. And a lot of systems that MOBAs use to have a sense of progression through a fixed environment that are really smart solutions to gameplay problems. The idea of escalating power through achievement in-game—leveling up in-game—and the idea of options on a map to automatically force a team into strategic decisions. Laning, basically.

If you have a team of five but three options on a lane—which is the classic MOBA—you can’t send them all to the same place. You can’t split them evenly between the lanes. You see, MOBAs have developed a sort of grammar where you know where your class goes. But those early concepts where the team has to make strategic decisions are really, really useful for making a game work time after time or be different each time.

So partially it was inspired by us playing a lot of those games and partially, they’re just great gameplay mechanisms. So, from that point of view, the kind of game we wanted to make moved towards a MOBA-style game because we wanted to have those sort of legs and that kind of depth. Between the complexity of the ships and the decisions we want to force on the team from the mode and the map, they all head in that direction.

As to whether we’re a MOBA or not, I’m not sure that’s our decision to make. In my mind MOBAs are very much—with the exception of Smite, of course—in a top-down kind of look. We aren’t that. We don’t have a concept of creeps in the same way. But we have so much in common with them that I think it’s a hard thing to pull away from.

You mentioned that you divided the map into sectors because of geometry. Was there also a gameplay aspect that played into that?

Massively. The game has existed on paper for a long time. We were working on the Director’s Cut for Strike Suit Zero. We were doing other things. There was a lot of work that went on paper. And one of the things we knew from Strike Suit Zero is that you need to resolve is containment. Multiplayer games need to contain the players inside space, they need to provide strategic decisions based on geometry. But in space, you can fly around things. You fly over the object, around the object. It’s very hard to make choke points. And good map structure is very dependent on that. So the idea of sectors was to resolve that problem—the geometry problem—which is that it allows you to create the structure of the map outside of the space itself by creating lots of spaces.

But it also plays to the science fiction side of it. You see Battlestar jump out. In a crucial combat moment, you want to be able to do that. Those kind of moments, you want to relive. Adding a jump system to our game allows us to add that. Not in terms of “cool sci-fi media,” but also in terms of the strategy of it: when to jump, how to jump, where to jump, and what will be there when you get there. These are all gameplay considerations. We love the idea that, initially, in the game, you’re jumping into a sector blind and, as more and more information comes through in the game, you’re making more and more strategic decisions on how to deal with how the enemy is behaving. Jumps are a huge part of that.

One thing we noticed earlier on is that we kind of always knew that we needed to control jumps. If the player can always jump in and out of anywhere else, it’s a massive problem for combat. So we tried a number of solutions and the one we have in game at the moment seems to work most effectively. If you try to jump in combat, you take much, much more damage. We originally made it so that combat would stop damage, but it just ended up being frustrating that you would end up in a situation where it was too easy for somebody to stop you moving around and the idea that there’s a risk involved, where you can try and jump out in combat, became much more player choice.

So it’s generally a bad idea but people do get away with it, in which case they’re not trapped in a sector. They can try and escape the combat. They can just the jump to do it, but they’re aware that jump is a form of movement, not something you want to do under fire. And it’s those kind of moments that actually become quite cool in-game, where somebody manages to escape. What’s also common is when somebody in a completely empty lane jumps to support their teammates, but at that moment a hidden assassin will decloak and take them out by using the jump damage as a way to finish them off.

There’s a lot of cool moments that come out of the jump system and the way it works in-game.

I was going to ask why jump points are so predictable, but it seems that it is done that way so that you can create choke points, according to your answer.

Yeah. We’ve evolved the system quite dramatically. Originally, when we put it in, I created a series of jump gates that players would use. It was really, really obvious that you would fly to this point and it takes you to the next sector. That made it way too predictable. You could block people from getting to jump gates. The arrival points were even more obvious than they are now, so it was even easier to cap an arrival point.

The way it works at the moment is that, in the live game, there is a random point based on an arrival point. So you can’t be sure exactly where somebody’s going to arrive, but you’re aware that people have to come in from certain spots. That allows you to control the map.

If you forward and take an enemy base that opens up additional jump points, so that you can travel to new places, but the number of jump points in that mode are relatively simple and easy to understand. Something we recently experimented with in Frontline was having many, many jump points within a sector so that, if you are outside combat, you can reposition inside the sector. That’s something we’re experimenting with in an evolved version of the live mode so we can make more of the jump system, even within a sector.

So it sort of forces players to play within a sort of “lane.”

There’s a massive balance here. We want to use jump. It’s something unique that we have and we want to use it as effectively as possible to give players a chance to jump to forward points within a sector or use their jump ability to outmaneuver and flank other enemies. But we need to make sure that, while we do that, we’re not breaking the classes that exist. We have a number of long-range classes that are vulnerable at close range and we need to make sure that they aren’t automatically invalidated by the fact that we allow sector jumps.

So it’s a careful balancing act, but the way we’ve got it set up allows players to maneuver using jump, but not automatically close using jump. There’s a nice balance between the classes that exists by giving freedom to the player.

On the topic of map design, I noticed that each of the outside sectors have a clear “lane” with what almost appears to be a “jungle” with the asteroid fragments surrounding it. Was that intentional?

The lanes thing wasn’t something that we thought “oh yeah, we should have that.” It evolved out of creating multiple sector maps. The first sector map I made was seven sectors. If you imagine, there’s the two bases, the central point, and, instead of the two lanes you have three sectors, so the one that is closest to each base and then the middle one. That kind of creates a concept of a left and right side of the map in sectors, but the problem is that the idea of what you’re jumping into in that map became a problem because there was no advantage for you to jump into that central sector. You’d be losing the advantage of your station, your space, or your controlled area. You could arrive at a different time to your teammates, possibly lose a battle of numbers until your mates arrived.

And so, there came a point where the game automatically developed stalemates. We were aware that the sector system was breaking fluid movement within the game. It was breaking the existence of a front line where enemies automatically and naturally come together and try to force ownership of the map and create the momentum that moves between teams.

The obvious solution was just to massively simplify it so that, when you jump into the right side of the map, that is just one massive, big sector so that there is a push. You can push between bases. You can dominate the lane because, ultimately, that kind of behavior, that laning behavior is the largest portion of the game. It’s how you control the mode. If you do it well, you win. But then you’ve got two lanes to compete and you’ve got five players split, so it actually started out with a more complex setup, but simplifying it helped create that MOBA-style laning gameplay. But it came out of a need to simplify the way that sectors work.

You mentioned that maps are going to take a while. Are you planning to do multiple maps in the future?

Yeah, we’re planning on new modes, new maps. We’ve just trialed the first new mode we did, which is Frontline, a very simple, single-sector combat map. There’s multiple reasons for that. One of them is because we wanted to give an alternate way to play the game, but also that map will eventually serve as part of a new player experience coming into the game. Because we have a relatively complex game and the idea of bringing people in through a simpler game mode so that they can learn about the ships, learn about the game, and have a few games in a simpler game mode before hitting the multiple sectors map will give them a better chance in the game.

So we developed that partially as part of the new player experience, but also as a separate way to play. We want to add new maps in the future, but also, our current live map exists as a single map with five sectors in it. We have this nice idea that we want to create alternate sectors for both lanes and probably gamma as well. When we finally get a drafting screen in, players could theoretically block or select different ships that they have, but they could also select lanes. So a team preferring a specific team combo could opt for an open lane or a heavily-filled lane, where there’s a lot of geometry, lots of asteroids, lots of crannies. And those kinds of decisions would help and form team balance and help the teams decide how they’re going to play in that environment. The idea being that the players would have more control over the map they’re about to go into and could try and ban certain options or select certain options as they move into the main map.

I was going to ask why you decided to assign ships at random in Frontline, but it seems that it’s because it’s a new player mode and you want new players to experience the full range of ships?

Yeah, the final version of the way the randomizer works is that it will pick ships that you’ve unlocked. It’s how other modes work, so it wouldn’t actually pick from any set but when we originally trialed Frontline, we wanted players to come back and enjoy what we’d changed in the game. Those guys would have not had the opportunity to unlock some of the new ships. With bringing them back and putting the randomizer on the way we did, we allowed them to come back, try out the new mode, but also try a lot of different ships.

It was also a great equalizer. This isn’t specifically what we’d intended, but a lot of our really good players are very focused on the ships they play and one thing we’d discovered is that, although new players were were playing ships for the first time, because of the randomizer, a lot of more experienced players were playing ships for the first time. So it was a great equalizer for the short period we ran it.

I think, in terms of the random ships, in the way that it worked, that was very specific to that period. The game mode itself will be released with a randomizer. We think the size of that map is very dangerous if you have complete control over your ships. We actually did release—I don’t know if you played it—Frontline without the randomizer for a few days to demonstrate this. We had a lot of guys very used to ships and they were very keen for us to turn the randomizer off, and we turned it off, and they asked us to turn it on again. The mode was broken if you have complete control over your ships.

I think the existence of that map in the new player experience may be more controlled. It will probably be going through the starter ships we’re going to put in. So there may be no randomizer there or, if there is, it’s between a very limited number of ships.

We do have a lot of things to fix on the randomizer that we’re currently doing. When we first released it, it was a purist sort of random where the teams were made up of one heavy, three medium, and a small ship. We were playing it internally and, if one team didn’t get a healer, they just sort of focused on the healer, trying to remove that advantage that they had with the additional DPS they had. But what we noticed from when people is it just made a big imbalance if you played strategically. You protect your healer, you have a massive advantage.

So we’ve polished the randomizer to a point where the groups that the ship selection picks from will always include a healer group. Both teams will always get a healer. What we’ll probably do is evolve it to the point where you may not get a healer, but whatever ship selection one team gets determines the kind of ships the other team would get, so that they’re always relatively balanced in that way.

The game already feels fairly polished even though I’ve read about the assets in maps being relatively placeholder. At what point are you be willing to say that you’ve reached beta?

There’s a thing about development, anyway, where you don’t ever really finish a game. They just take it away from you. The advantage of this kind of development is that development never finishes, so we’ll be working on the game ideally forever.

But as to when we call it beta, there will be a set of features that defines when it’s beta. Depending on who you ask, those will be different. For example, I’ve been thinking about this game so long that there’s a huge list of features I want to see in it that we haven’t done yet and may or may not be that important. They may be the best thing in the game. They may be just a distraction. And so I’d have a very different opinion to, say, our CTO or my producer. I think there will be a point when the—not necessarily just art but—the functionality is solid enough that you’re adding alternate ways to play a game that exists rather than changing the way the game plays.

At the moment, I think we’re still tinkering with the way the game plays and things in it, like the way level ups work, the way the endgame works, trying to put context in the main game modes. Things like the capture spheres that we were always intended to be relatively temporary and healing, when you go to a base, wouldn’t be done by a sphere but drones would fly out and heal you. If you go out and capture a mine, there are mining drones doing the mining and hiding when you come in, which cuts your resource income down.

So it’ll all be context-based systems. It could be when those are all in and the game’s all solid, we have a couple of modes, and the metagame’s in place that that’s beta. But it could also be that we get all that stuff in, we’re looking at the metrics, and realize there’s work to do.

That’s a really elusive answer, but I think the short version is that I couldn’t tell you. I don’t think it’s anything specifically to do with art. I think the stuff we’ve determined finished in art is really, really good. The engine’s making everything look lovely. And I think the plan is that, well before beta, the game will start looking more polished than it does now. But I think it’s a question of systems in place and making sure the game is solid enough, not just in terms of stability or balance, which is an ongoing task, but also in terms of the metagame on top and the way that per-player progression works, and the idea of the player’s own personal narrative as he moves through unlocking ships and his experience, how far to take that, and knowing there’s enough content there, then we could release the game as beta knowing that it’s got enough legs to keep going while we add content.

It’s meant to be at some point next year, but we’ve got to get to free-to-play first, I think.

So then free-to-play is coming before beta?

I guess it kind of depends. I don’t know. It depends on your terminology. I suppose your closed beta and your open beta aren’t really when you go free-to-play. A lot of us here come from a box game background where alpha and beta are clearly defined in terms of alpha being all systems in place but not final art or assets and then beta everything in place and then final bug fixing.

The evolution of Early Access, for one, free-to-play. For two, games spend a lot of time in alpha states and a long time in beta states and the definition of what those are does seem to be lost when even games that have moved beyond beta are patched regularly with bug fixes and new content.

So I’m not completely sure. It could be that we are beta on free-to-play release, but I don’t know what terminology we’re using or anybody else is.

--

You can play Fractured Space on Steam now. The Early Access phase requires a minimum buy-in of $9.99 for the time being.