Boston GameLoop is an annual game development unconference. I’ve been going for years, and I’m always impressed by the sheer wealth of knowledge available. I’ve written up my notes below, but I haven’t fleshed them out this year and they’re more than a bit incoherent (apologies for that!) I hope they’ll still be useful.
GameLoop participants: I have not attached anyone’s names to these writeups, and I’ve mostly scrubbed personal anecdotes out to maintain the privacy of attendees. Please contact me (carolyn at sibylmoon.com) if:
- I included something you said that should not be included, or
- I quoted you without attributing (when you would prefer attribution), or
- You think I got something from the discussion wrong
Why do games fail?
(This discussion focused on released games, not games in process. It often veered into “why do companies fail?” territory.)
Concepts of success vary… who’s defining failure?
- shareholders (didn’t make enough money)
Failure to communicate with your audience
Failure to understand your audience
- Problem: target audience/actual audience mismatch
Developer/marketing communication failure
- Solution: keep customer service/marketing in the loop!
Developer/developer communication failure
- Problem: failing to trust people to do their jobs
- Solution: respect everyone’s roles – in particular, devs should not have to (or try to) do marketing if a marketing dept exists
Before updating a released game’s content/mechanics, think about: what are people doing in the game? and how will your update change what they are doing in the game?
Keep an eye on metrics… use them as evidence when arguing for a change
Marketing and community management team need to work together
When writing patch notes, keep them positive – help people understand how the changes will make the game better
Your friends are not necessarily your best colleagues – maybe don’t start a game company with them
Respect the community of players – especially when sunsetting an online game: build a positive experience that will encourage them to transfer loyalty to one of your other/future games
Avoid burnout – you’ll lose the ability to make decisions, and that will hurt your game
Keep games fun by playtesting, playtesting, and playtesting
Use rapid prototyping to playtest early, while you can still pivot as needed
Look for ways to measure results – don’t trust anecdotes and intuition
Understand development in terms of cost and revenue – use these metrics specifically when arguing for/against changes
Who is your audience? Why? They need to be the people playtesting your game.
Usertesting.com <– affordable user experience research platform for mobile betas (not game-specific)
Someone usually knows that the game is in trouble before it fails. Getting that info to the right people is the hard part.
Be honest. Look for feedback. Listen. Address problems early.
When talking to other developers/management, be honest about your concerns – but cover your butt
- Think about exit plans if you believe the ship is sinking
Books to read: Getting To Yes and Having Difficult Conversations
- Understand each other’s needs and goals.
Why don’t people speak up? Fear of retribution.
Useful thought experiment: before the game ships, while there’s still time to make changes, pretend the game has failed. Run a postmort where people talk about why the game has failed. Helps dig out concerns in a safe environment.
Being part of a good team includes being willing to reach out and ask for help.
Open lines of communication:
- Ask why decisions are being made
- Go out of your way to hear everyone’s voices (esp. marginalized voices)
- When new, seek out mentorship opportunities
- Studio policy of 1:1 meetings with supervisors and direct reports