We often use vague catchall words to describe careers in gaming: developer, designer, producer. But those words don’t tell much of a story. What’s Your Line? is an interview series designed to demystify the people who make their living in games.

Most gamers are happy to disembowel monsters or murder enemy combatants by the truckload without giving a second thought to the millions of lines of code quietly operating behind the scenes. Epic Games Senior Programmer Josh Markiewicz actually writes the mysterious code that makes such gleeful on-screen violence possible. After beginning his career in flight simulator graphics, Markiewicz moved up the ranks at Acclaim and Namco Bandai before landing at Epic, where he’s worked on AAA titles including Bulletstorm and the Gears Of War series. He spoke to The Gameological Society about his role in the development process and how the push for online content is changing that role.

Gears Of War 3

The Gameological Society: What does a programmer do in the gaming world?

Josh Markiewicz: There are gameplay programmers who get the design on to the screen and make the game you actually see. There are engine programmers who are responsible for making the most of the technology. There are tools programmers, the guys that write the tools that help artists do their job. For Gears Of War 3, I was mostly in the online realm as an engine technology programmer. I made sure that multiple versions of the game could talk to each other, so that people could connect to the servers and play together with good bandwidth, a good online experience without any lag or hitching.

Gameological: What tools do you use to program? When you sit down to work, what are you actually looking at?

It’s not like The Matrix, where you see dropping lines of code everywhere. But there’s a certain amount of getting it.

Markiewicz: Code, code and more code. The day to day is mostly staring at text, doing math, doing physics.

Gameological: Can you look at lines of code on a screen and translate that in your head to how it would behave in a game, the way a musician might look at sheet music and be able to hear the music?

Markiewicz: It’s not like The Matrix, where you see dropping lines of code everywhere. But there’s a certain amount of just getting it. You can look at things and make decisions, like, “Is this going to run fast? Is this something that will take a lot of time for the computer to chew through?” There are a lot of algorithms in your toolbox. It can be a top-down approach. Like, say a piece of code is going to tell me the number of bullets I have in the shotgun. First, you just want to draw a number on the screen. Then come back and say, “Okay, now that part works, how do I get the shotgun to tell me how many bullets it has?” Or you can work bottom-up. I have a shotgun. What kinds of things can a shotgun do? It can tell me how many bullets it has, it can fire, it can drop on the ground, it can morph into the chain lightning gun. We have some latitude to get creative.

Fortnite

Gameological: So programming is not simply a matter of executing someone else’s vision?

Markiewicz: If you want to riff a little bit, that’s okay. At Epic, we have daily playtests, and then we talk about the game—what we liked, what we didn’t like. Things like, “I feel this map is not balanced right,” or “This weapon is too powerful, but what if we had this weapon to counter it?” That kind of feedback is welcome and encouraged. Obviously, there are designers whose job it is to create, but programmers love games, too. That’s why they’re in the industry.

Gameological: Where does programming fit into the development process?

Markiewicz: First, there’s pre-production, where you’re figuring out the two-line statement. You know, “It’s Pirates Of The Caribbean but with tanks!”…You start to nail some things down. We’re going to have three kinds of pirates, we’ll have four kinds of tanks, we have to have a ranged shooter character. In mid-cycle we’re striving for “content complete,” which is when every character’s been modeled, all the animation is done. It might not be in the game yet, but it’s finished. After that we’re striving for ZBR: zero bug release. That’s the push to ship the game, to finish up the polish and make the best possible experience for the consumer. The new thing is post-production. Until recently, you ship a game and it goes on the disc and you’re done. But iPhone games put out free releases, you know, rate us five stars and we’ll produce more content. We’re experimenting with that. You’re not just going to release a free-to-play game and say you’re done. You’re going to add more hats, add more weapons, more zones to play in.

Infinity Blade

Gameological: The free-to-play model is increasingly popular, but there must be plenty of players who simply find microtransactions or in-game ads annoying.

Markiewicz: Back in the day, arcade games were designed to take a quarter from you every two minutes. That pace was met, and you didn’t feel like you were getting bilked. We’re trying to get away from charging 60 dollars for the experience, and instead giving it away for free and hoping that 20 to 30 percent of people like it enough to want to spend money on it. At Epic, we’re trying to figure out what it means to bring a game like Gears Of War or Fortnite to that space. We don’t want, “pay to win”: We don’t want someone to pay 10 bucks and have a huge advantage over someone who just wants to play. But a lot of people like to be able to express themselves through their character or the furniture in their house.

Gameological: Is it challenging to work on games across different genres, or is programming always programming, no matter the project?

Even something like when you move the thumbstick to look around, there may be a lot of math going on there.

Markiewicz: Math and physics are always relevant. If you want to do a hardcore racing simulator, the physics of the game are going to be a lot more important, but if you want to do a platform jumper, [the character] doesn’t really fall under normal Newtonian gravity laws. Programming those aspects can be tricky, trying to ride that line between fun and real. As I said, it’s a toolbox.

Gameological: You’ve mentioned math and physics a few times. Does that mean you’re actually doing a lot of number crunching and blackboard-type calculations?

Markiewicz: Things like kinematics—gravity, velocity, acceleration—those are all very relevant. Even something like the controller, when you move the thumbstick to look around, there may be a lot of math going on there. If you jam the joystick to the right, do you want it to go really fast, or should it ramp up over time? It matters. That’s the stuff that shows up in reviews. People say the game doesn’t feel right, and often it comes down to the math. Rendering and graphics? Super heavy math. What does it mean for light to reflect off a surface? What does it mean for the physical material properties of the leather jacket you’re wearing? If the character jumps in the water, what does it look like for him to be wet and how fast does he dry?

Gameological: Does knowing what’s under the hood affect the way you play games, or can you take yourself out of the role of programmer and just have fun?

Markiewicz: When I’m really involved in the story of a game, I can put that aside and just focus on enjoying what I’m seeing. It’s when someone brings a game to work, and we’re talking about it, that we get hyper-critical of minor flaws. At least I can understand, like, if the character is not letting me do something and I’m frustrated by that, I can temper that. I can understand if there’s a game design reason that happened, or say wow, that’s a bug, but I’ve seen that bug before. So I can be like, “There, there, it’s okay, other game.”