Making Lots of Small Games Without Going Crazy
Speaker: J.C. Connors – Studio Head, Griptonite
Overview/History
Started working in Baltimore making small games. Started by doing tech support and had to do testing, made a pen-and-paper RPG in 10 months, and fixing this game called Ninja that wasn’t fun. So he was used to multi-tasking all over the place. So two years ago, he started as the studio head of Griptonite. He’d just recently shipped a big budget console title and shifted to a smaller studio, and not all of the skills crossed over.
The small game studio as a meteor shower
• Projects are coming in fast.
• Most are on fire
• Some are chunky, bland, and devoid of anything interesting.
• People are confused and scared
• How long will it last?!?
Everyone had their own idea of what would make their game really great, and there were various issues that were caused by a number of different reasons, so he needed to come up with rules to prioritize. These rules needed to be transparent so everyone in the studio would understand what was most important.
Lesson #1: Strong leaders make strong games.
A lot of small studios assume that strong leaders mean strong technical skills, but it’s not. Producers and leads are like fruit flies- the point here is that short projects are so abbreviated, that they contain all of the parts of major projects, that people are constantly learning from incredibly fast projects. The successful projects had really strong producers. The producers would guarantee games that would be on-time and great.
Leadership is really cultural: foster a culture of asking questions and learning among producers and leads. Watch out for those who make the same mistakes twice. Really foster a community of people talking to each other. Art reviews and game reviews; anything to get people talking is a good thing. In a small studio with lots of small projects, the best educational assets are the ones that surround you- if you don’t learn from them, you’re going to fail.
Make roles clear to people. If this is left to be grown organically, then many things will fall through the cracks. In looking at Mystery Case Files – there turned out to be a client-side producer who was a full of really great design ideas, a designer on the project, and another producer who all had design ideas, and while they all had ownership on various features, there were features that didn’t have a clear owner.
Have a strike team in mind for emergencies. Delegate this so that you aren’t always functioning as the firefighter on every single project. Examples of firefighter roles:
• The Technician (aka Batman)
o Strong technical understanding of your pipeline and tech
o Willing to do the dirty work
o Empowered to get things done
o Ability to be subtle and work behind the scenes
o Autonomous
o Example: In making realistic water effects on a DS game, they tasked him with it and when the team needed help, this person was there to just step in and actively, happily, tackle it.
• The Man of the People (aka Superman)
o Positive personality
o Sell doing the right thing to teams and clients
o Decisive yet empathic
o Strong execution
• The Jack of All Trades (aka Green Lantern)
o Multitasker; can be given multiple projects and problems to deal with
o Can work with any team
o Willingness to use creative solutions
o Intuitive
• The Specialist (aka Aquaman)
o When a certain team has a very specific problem
o Understands his specialty very well
o Extremely consistent
o Don’t have a studio full of Aquamen!
Lesson 2: Give innovation the same respect you’d give a mountain lion
Innovation – something where there isn’t a clear template to follow.
Innovation is the coolest thing about creating small games. Innovation can also completely destroy game production- one of the main features of innovation is failure and iterating upon that failure.
Unless everyone on the team, the leads, the clients, are all about innovation, then innovation is best in small doses. In looking at Spore Creatures, they knew going into it that there were a number of incredibly innovative features.
• Innovative Features
o Creature Creator
o Internet Pollenation
o Shadowbox Visual Style
o All-Touchscreen Combat
• Tried and True Features
o Linear, Quest-based Level Design
o Elite Beat Agents-like social game
o Achievement/Badge System
Replayability and accessibility is often more important then innovation on small titles. Everyone wants to make an innovative, but not necessarily an accessible game. It’s more important to get people into small games and handheld games, and once that barrier is lowered, then you can surprise people with how you can twist the rules and innovate.
Your game is as strong as your weakest, most-played component. Prioritize core mechanics, prioritize controls, prioritize where your games’ strength really comes from.
Lesson #3 – Fun is everyone’s job
Everyone should be able to play their game in their head from the 2nd week of the project. We always have a tendency to improve on what we’ve already done in the past. If someone can’t communicate the game that they’re working on, then that’s a problem. Producers should always be making sure that everyone’s on the same page.
• Create a Game Culture
o Game Days
o Competitions
o Giveaways
o Shared play sessions
If everyone has a shared vocabulary, fewer people will be making a mistake.
Lesson #4 – Monitoring scope is one person’s job
You need somebody on the project to ring that bell if the scope isn’t making sense. In looking at the problems with Spore Creatures, they didn’t realize that there were whole tasks and features that weren’t on anyone’s radars since they involved integration of all of the various systems. No one was looking at the big picture.
The Great Fibonacci Videogame Equation for Fun and Perfect Scheduling
• Time estimate Multiplier for Fun
o Moment to Moment x 5
o Minute to minute x 3
o Hour to hour x 2
o Once… ever x1
The more the player is going to be doing something, the more time should be spent on it.
Lesson #5 – Understand the difference between urgent and important
• Always talk to your clients… regularly
• Fix features that aren’t fun asap.
• Deal with problem children
• Don’t send anything sloppy.
At the beginning of a project, spell out what’s important to the team. They’ve done a lot of work with Dreamworks and Activision, so they focus a lot on those projects that the humor is really important; this is what’s important to our client and this is what’s important to our studio.
Lesson #6 – Surprises are bad
Always give publishers fair warning of what’s happening, good or bad. If suddently forecasts change, then give publishers as much heads up, and never wait until the last minute. This applies to internal development too. Make sure everyone is open and honest and don’t be afraid to share bad news to one another.
Even good surprises can be bad! They were working on a licensed movie title and it was getting off to a slow start, so they created a new level to go at the beginning of the game and they were really proud of this change, submitted it, and the client was really upset by this was because the publisher thought the timeliness of the project was the most important. In retrospect, it seemed as though the developer was focusing on the wrong thing.
Lesson #7 – Manage your projects like a portfolio
The more you diversify, the more likely you are to branch out, you’ll then be able to keep your stronger talent.
Lesson #8 – Leave time to think
You have to plan your studio’s future – you have to think 6 months, a year, two years out. You have to be really honest about your evaluations – you have to plan these guys’ future and make sure they’re staying at your company. If you’re always fighting fires, it’s hard to find that time.
• Suggestions
o No meeting Mondays/Fridays
o Close the door; get off-site with your managers for some time
o Make time for lunch
o Talk to people you haven’t talked to before
o If you think you have too much going on, you do. Fix it.
Embrace the insanity. There’s always going to be a little bit of craziness, no matter what.
Q&A
Question 1: Making small games have very tight schedules and you’re dealing with licenses as well, how do you find yourself managing the publisher and licensor and still successfully hit the launch date?
I think identifying what’s important to the project and share that list with the publisher. Get a document early-on and prioritize; this is what we feel is really important and that will help to avoid hassles from appearing later. At least every other-day conversations with these people. Foster better relationships with these people.
Question 2: I’m curious if your specialists were on your engine team?
Our engine is more of an open-source project internally. Various projects contribute to the engine with what they think it needs. If a game needs a tool, that game team builds it, and if it’s really useful, then it rolls out to the rest of the team.
Question 3: How do you set up your hierarchy? One team per project?
Griptonite has dedicated teams, we don’t want to shuffle people between projects. We’re a big enough studio that we have dedicated art, tech and design leads. Making sure that riskier projects have a senior producer on the project to mentor some of the younger producers
Question 4: Are you working on next-gen?
Because we’re part of Foundation 9, our specialty is handheld, and we’ve blurred the line into downloadable and cell phone. But because the handheld industry is so large, we’re focusing on making great handheld games.
Question 5: Everyone’s job to make the game fun, but how do you prevent too many cooks in the kitchen?
Once a few weeks, we get everyone in a room and the producer is at the white board and writing down suggestions as everyone plays the games. The producers are in charge with filtering that feedback to see if it’s an issue that needs to be fixed.
Question 6: How do you avoid taking on too much or too little work?
I think what we mostly do is that we’re very good at the beginning of a project focusing on what is really important and figuring out how many man-days or man-months are tied to that. Then making sure that you re-assess the scope throughout the entire project and maintaining open communication with the publishers.
Question 7: When a project balloons out of control, what do you do?
We send in the troops to find out exactly what happened. Sometimes it’s pretty easy: the game is too short, how can we fix it? We exist as an independent developer, so we have to evaluate the scope and have honest discussions with our collaborators and be honest about the risk. Early on, people used to just throw people out of QA at producing handheld games, but since the handheld industry has grown, more and more focus has been placed on making handheld properties great.
Question 8: What’s your list of worst practices for a company?
The worst thing you can do is having a reputation for being late or making crappy games. We try to make really strong games and we’re never ever, ever late. If we abandoned those ideologies, we’d have a hard time getting work.
Question 9: Can you talk a little more about the Fibonnacci time is split and how you go about carrying that out on projects?
We make sure that we don’t schedule down to the hour; we schedule something in days. For something like the Spore Creature Creator, we divvied up the important features into multiple parts for whatever makes sense to the team. It’s about making sure what’s the most important
Question 10: How do you manage information sharing and knowledge sharing across teams?
We’re just really good at sharing knowledge. Bi-weekly meetings to share knowledge. Dedicated background art meetings where people share their work. It’s harder for producers to share since they’re generally very tunnel vision on their projects, but having senior producers to oversee them has helped a lot.
Question 11: It’s good when you’re in a team to play the game in their head. How do you create the conditions to let that happen?
We have designers prepare mini-presentations to share what the game is about and we supplement that with visuals and diagrams. Starting that discussion and getting people playing games that are similar will allow people to have a common knowledge base to discuss the game’s design.
Question 12: With such a large number of games and short cycles how do you prevent burnout?
Minimizing crunch. It’s a very organic progress. I hold my producers accountable – if there’s a crunch, they’re responsible.
Question 13: Do you have rough metrics for a certain amount of crunch that equates to time off?
We handle it on a one-on-one basis. Sometimes people crunch because they’re really passionate about a game. Other times it’s got to be on a case-by-case basis.
