This evening was an IGDA-organized “Meet The Press” event at Google campus in Mountain View, which I attended with a few friends. It was an interesting experience because it showed a completely different side of game development, something I only get a glimpse of every so often. This is the side of game development about market share, numbers, percentages, billions, social, mobile, mid-core. For the most part I’m exposed to the indie, creative, artist, nerdy, emo, poverty-stricken side of game development. It’s good to get things from both sides, but I definitely feel more at home with the indies.
Tag: events
July East Bay Indies Meetup
Tonight was the East Bay indie developers’ meetup in Berkeley at Au Coquelet, an intimate gathering of about ten locals, about half of whom didn’t come to last month’s gathering. It was an awesome time. To those of you who couldn’t make it, another one will be held in the last week of August, so follow me on Twitter if you want to be informed!
Meetups like these are essential to me. Working alone is a great way to get stuff done, until I reach that stage where I feel like I’m floating off in orbit. After enough days go by without real professional interaction, I start to raise existential questions about game development, my career, my life, and that’s just never helpful. Talking to other devs is really inspiring and energizing, and gets me back focused on the small, individual tasks that actually get the project done. It’s also great to have playtests planned ahead of time–when I know I have to show the game in 3 hours, it changes the way I work. I’m much less likely to be chasing a weird bug down a rabbit hole, and more likely to put in a quick fix to get through the day (often the better approach in the long run).
So where do we stand with Escape Goat? I’ve got pretty much all the gameplay bugs fixed and features locked, and the file system for user created levels is also pretty solid. (I don’t have a sharing system in place yet, that’ll be explored next week.) Since I’ll be having a playtest party this weekend, tomorrow is going to be a good day to remake the levels from scratch again. I’ll browse through the previous versions of the game and harvest the best room concepts and puzzles, and string them together in a logical way. I also haven’t explored a lot of the puzzles that use the later mechanics and abilities.
Also on the radar for tomorrow is a chat with long-time comrade and audio sorcerer Matt Piersall. I think I need some advice from him on how to design the soundscape for this game. The music is not a problem, but this game presents some unique challenges in that field and he’s going to have the answers. I know this.
Also, tomorrow I get to see Mary for the first time in a week!
Congratulations SuperGiantGames
Tonight was the Bastion launch party, an awesome event for many reasons. First, I got to play a new game called Joust, which I suppose every indie developer should know about, but I somehow didn’t. Here is me playing:
I lost every round but one.
Second, it was great to see the crew after they had accomplished something many set out to do but few succeed in: band together and create a high quality title independently. This is somewhere I want to be in a little while. It can be done.
Third, something Amir said during a brief toast, really struck a chord with me: that most of the people here he did not know before he began building Bastion, and that he never expected that making a game would make him this many friends. Hell yeah! This is game development at its finest.
The Playtesting Party – Some Quick Tips
Tomorrow is another Escape Goat Alpha Playtest Party! That means tonight is a blog post on playtesting, lightweight, indie-style. In other words: you’ve got friends, some of them play lots of games and others don’t, and you want both types to try out your game and give you their valuable feedback.
Throwing a party is a great way to get this free labor from your friends and family without feeling too guilty about it. Just provide them with enough food and drinks to ease your conscience. And it’s not such bad work either, playtesting games.
Now I’m not the master of testing, and a lot of these tips probably come straight from Jesse Schell’s The Art of Game Design. For Soulcaster I, II, and Escape Goat I’ve probably hosted about ten proper playtesting parties, and here’s what I’ve picked up from them.
First question: When to start playtesting? There’s a point during development where you think things have come together enough that you have what could, in some stretch of the imagination, be described as a “game.” Maybe it doesn’t have a beginning/middle/end, maybe the graphics are placeholder and there’s no audio yet, but there’s something there and you can put it in someone’s hands to be judged. This thing that has until now been called a prototype has now somehow become a game. If you’re there, let’s get started.
1. Test it yourself beforehand. If you’re making tons of last minute changes like I do on the day of the party, just be sure you’ve given it one full run-through to make sure you didn’t accidentally delete the switch that opens the door to level 3.
2. Have a cohost. A significant other or close friend will be needed to greet guests, cook food, send out for more beer, talk to the cops, etc. You’ll be way too engrossed in the testing to be a proper host, so don’t even try.
3. Fresh meat first. Anyone who hasn’t seen the game yet gets first dibs, lest they catch a glimpse of someone else’s session and have their first impression become corrupted. If someone else is testing while a newbie arrives, have your cohost distract him or her for a bit. “Have you seen the new patch changes in HON?” for example.
4. Tell your tester to speak their mind while playing. Anything that’s running through their head. Here are some direct quotes from the last playtest:
- “Wait, did that do anything?” (after skull activation)
- “That’s the same message that I read earlier.” (story tablet at region 1 entrance)
- “Did that guy just hit something?” (reaper in level 3 third room)
- “I like that he looks really, really scared” (idle edge sprite for goat)
- “Why do the blocks have color on them?”
This way, when a player is wandering back and forth in the opening area, you can get an idea of why. Can they not find the exit, or do they just like the walk animation? Personally I hope it’s the latter, because the two-frame goat run visual took me freaking forever.
5. Remain silent. No hints or explanations of how things work. You’re a fly on the wall. (The exception would be a known glitch that hides information and could cost time, for example a tutorial notification that isn’t showing up in this version for some reason, but will be in the final version.)
6. Take notes.
7. Have a roundtable discussion afterwards. If you’re making games, odds are you have friends who have strong opinions on games. This is one of my favorite parts of the testing party. I’m surprised to hear what people liked and didn’t like, what they would like to see in the next version.
8. Process your notes and thoughts the next day. I personally love using BlueMind for this, but maybe that’s because I’m a recovering organization software junkie. The point is to get a nice list of bugs to be fixed, major remaining design issues, principles on designing levels going forward, etc.
So that’s it, hope this has been somewhat helpful, and if you’ve got additional tips, please post them in the comments!