Episode 178: Kids and Turtles


BTG on iTunes

Intro and Welcome:

SODA!!!

Feature of the Week:

Designing games for kids

Practicing the Pitch:

Rob pitches a game about Ninja Turtles

Comments

One response to “Episode 178: Kids and Turtles”

  1. Patrick Heney Avatar

    Hi guys,

    I’ve been listening to your show for over a year now, and I have really enjoyed it. I recently reactivated my old twitter account and the first thing I did was follow you guys.

    Some meandering thoughts on today’s episode.

    Regarding using existing IP to pitch a game. I really like what you guys did with this idea. I always avoid existing IP myself, because I don’t want to fall in love with a game idea and then have to re-theme it to a new IP. But, after seeing how much fun you guys had, I think there are some benefits to it as an exercise. You nailed the ugly problem though: existing IP can make or break the game. I wonder, if you take an awesome IP away from a game and the game is no longer interesting, does that say anything?

    Regarding inspiration and designer’s block. One thing I do when the well of creativity seems to dry up, is revisit the material that inspired me to work on the game in the first place. Alternatively, I might switch to a different project that inspires me and work on that for awhile, then jump back. For new projects, a built an application that uses a database of ideas that I add to periodically. It generates character ideas, settings, odd weapons, unusual vehicles, and randomly selects a mixture of game mechanics, end goals and win conditions. I then challenge myself to build a story idea that integrates as much of the generated material as I can. From that story, I can usually pull out a game concept or two.

    Regarding the letter you got asking for your opinion about the statement “I designed a game last week.” As a game designer and developer, this statement bugs me, because it grossly devalues the effort that is put in to create a game.

    I think It’s usually made in ignorance of what it really takes to create a game. Most people that don’t know anything about game design, game building, or software development, have a very narrow focus on what it means to design a game. They think that “game design” in its entirety, consists of any one of the following:
    a) describing a single mechanic, e.g., “throw a ball through the hoop”
    b) picking a new theme for an existing game, e.g., “it’s monopoly, but set in Beverly Hills,”
    c) providing a list of stuff they want in *a* game, e.g., “there are 90 characters, 500 guns and 1000 vehicles,”
    d) designing some art, e.g., “I used Photoshop to draw these awesome cars,”
    e) or worst of all, listing stuff from other games, e.g., “it’s like GTA5, but you play Master Chief from Halo, and the vehicles are all from Star Wars, and you can modify everything like in Need For Speed, and it’s all online and you can learn skills and level up your character like my favorite MMORPG.”

    To me, “designing a game” means you have an actual *game*. It doesn’t need to physically exist, or have been coded, but the design needs to be complete (even if poorly designed). It might need adjustments, be horribly unbalanced, have a terrible theme, etc. But it has setup description, win conditions, turn order, defined methods of interaction, as well as all *functional* description of components (such as the rule text for MTG cards). Everything that is necessary to actually *play* the game. Everything else is just having an idea.

    I hope you don’t mind the long letter. Just my thoughts.

    Patrick