While all eyes were on today's launch of Star Wars: Battlefront, two of the key creatives behind Electronic Arts' next game inspired by the sci-fi film franchise highlighted the final day of the Montreal International Game Summit. In a sit-down interview conducted by Execution Labs co-founder Jason Della Rocca, EA Visceral senior creative director Amy Hennig (pictured) and EA Motive general manager Jade Raymond discussed what it was like working on Star Wars, their philosophies of team management, and commonalities shared by indie and AAA developers alike.

Della Rocca began by asking about the creative process, specifically the process part of the equation. Hennig said she was an intuitive person, but at the same time can be "pretty anal retentive" about processes when she feels they're important. Ultimately, she said developers need to balance their own intuition with a more structured, analytical approach to problems.

"If you just tackle problems from the one side, you're kind of doomed," Hennig said.

Raymond echoed the thought, saying that as good as developers have gotten about improving their processes over the years, there is a danger of taking it a step too far and curtailing creativity as a result. In her experiences, the special touches that make games magic often come from experimentation that was never planned for or scheduled in development. There's a fine balance to streamlining processes and taking away creative blocks, but also managing the schedule properly to maintain a healthy work-life balance.

Specifically, Raymond mentioned times where developers are waiting for a new build or time spent struggling with tools as potential drags on creativity. On a bigger scale, Raymond said it was important to have as flat an organizational structure as possible, and to break tasks down between small groups that can feel creative ownership over whatever it is they're working on.

Both Hennig and Raymond have experience creating new franchises and managing existing franchises, but as Hennig said, "Making a game is making a game." Raymond added that when working on an existing franchise, you have to consider the fanbase and what their expectations are. They become the first customer and player to be considered, whereas original IP are developed for a hypothetical audience.

Obviously there are more stake-holders involved when dealing with Star Wars than an original title or Uncharted, but Hennig said people would be surprised at how different the experience of working with Star Wars is than people might expect. It's not the usual licensor-licensee relationship, and new management at EA, Visceral Games, and Lucasfilm have all gotten on the same page about how to put together the best game possible.

"You're almost paralyzed when you have something successful because it's like, 'Holy shit. We did that? Do it again?'"

Amy Hennig

"It just seems like kind of this perfect collision of everyone being in the right mindset at the right time," Hennig said.

There are even more moving parts involved with the addition of Motive as a collaborating studio, and Raymond noted that the team is also leveraging work EA DICE did for Star Wars: Battlefront. While there are complications involved with co-development across time zones and incorporating the EA DICE work into their own project, Raymond suggested the benefits far outweigh any drawbacks.

"I sort of feel like a kid in a candy store because all this stuff everywhere is being made in the same engine," Raymond said.

Regardless of the scope of the project, Hennig said the fundamental formula for success doesn't change.

"I think the same processes of working collaboratively apply whether it's four people or 400," Hennig said.

Regardless of scale, all the developers involved need to check their egos at the door, and everyone needs to have ownership over their work. Hennig said it's important to have the freedom to fail, to show your ugly work and reveal ideas that aren't fully formed in the hopes that the team can fully form them together.

There are other common trends of game development that apply to indies and AAA alike. One such issue is the challenge of success. Jenova Chen told Hennig about his concerns in the wake of Journey's success, and she found them familiar to her own feelings after her previous hits.

"You're almost paralyzed when you have something successful," Hennig said, "because it's like, 'Holy shit. We did that? Do it again?'"

Hennig also assured the audience that imposter syndrome was a constant companion of developers, "so if you all feel like frauds, it's because you're really awesome."

Full disclosure: MIGS has a media partnership with GamesIndustry.biz, and paid for our travel and accommodation during the event.

Sign up for The Daily Update and get the best of GamesIndustry.biz in your inbox.

In the agile software development world, one of the things we explicitly avoid is "code ownership," where a particular individual is the guy who makes all decisions about a particular part of the code or, even worse, is the only one allowed to change it. Everybody in the team is allowed to change any part of the code they like (though of course if there's someone who happens to have a lot of knowledge about a particular bit of code you want to touch, you'd almost invariably grab him or her for at least a chat about what you want to do).

(If some people are thinking that's weird or even impractical, think about how you would feel about a group that said that particular pages of the game spec/story/whatever were owned by particular designers. "You can't change anything on page 17; only Joe can change page 17. Any changes you want there, tell him and he'll make them for you.")

Counter-example: Imagine a game spec/story/whatever and anyone on a team of over 200 people was allowed to change any part of it they wanted to.

What you describe is how big team game development works (you do work in games, right, that's why you're here) - say in GTA each story mission is "owned" by a particular designer who knows that piece of content inside and out. They know what the art, audio and code requirements for it are. They'll work with the designers above them to make sure what they're doing in their mission fits in with the overarching game (works within the story, doesn't duplicate the content of another mission, isn't overlapping locations with another mission and creating conflicting art requests, etc.), but very few people on the team will have a big picture view of what every single bit of content is. At different times, content may be moved between designers to balance workload, but each piece still has one "owner".

Ask programmers what they think about discovering magic through an ad hoc approach to game design and deadlines, and you will usually get a different answer to what constitutes a healthy work life balance.

I think the key to being able to accommodate iterative 'find-the-fun', ad-hoc development is being able to even loosely define, relatively early, the boundaries of the sandbox you wish to creatively work within, and schedule time for engineers to build data-driven systems with designer iteration in mind.

Attempts to wildly change direction in terms of game mechanics, combined with giving the engineers zero time to do anything but hard code the basics, and you're doomed to failure, if not actual assassination at the hands of your programmers :-)