Yesterday, I went down to
Indianapolis for the Indiana Video Game Developers Business/Game Design Panel, hosted by the
Independent Video Game Developers Association and the
Indianapolis Chapter of the
International Game Developers Association.
The bios of each of the panelists are available online, so I won't summarize who they are here, but it is noteworthy that there was a great mix of expertise, including those interested in corporate branding, serious games, independent self-funded development, and even an IP lawyer. One of my students was there with me, but it was a great discussion and I wish more could have come. I will use this post to share some of my notes, both for my own use and to share with those who could not be there.
The topic of iterative design came up several times, with the folks from
Studio Cypher especially advocating for physical prototyping. Most of the panelists strongly advocated for focus groups throughout the development of a game. I was tempted to ask about specific methodologies: no one mentioned "agile" by name, but the spirit of it was strong. I ended up holding my question, in hopes that I could follow up with some of the panelists at a later date to discuss their methodologies more closely, perhaps even in a research context.
A few panelists mentioned making games for children and using children in their focus groups, so I asked how they went about recruiting children, especially since some were adamant about needing NDAs for focus groups. Two out of the three suggestions were the same approaches I have used: friends/family and schools. The other group they mentioned was the Girl Scouts, which I had not considered. They also mentioned that research firms could be hired, at a high price, to do these things for you. That's another one I had not thought of, but all agreed that this was likely not worth the price.
There were a few questions about how to choose technology for projects, and the panelists answered with a predictable and appropriate, "it depends." The panelists observed that all programmers want to write their own game engine, but that this is impractical unless it is one of the team's core competencies. This matches advice I've heard elsewhere, but I get the impression that the younger members of the audience had not thought about the issue before. When it came down to what technology was being used, there was glowing praise for
Unity—even the teams that weren't using it seemed to wish they were. This made me feel good about getting my own game programming students this semester exposed to it.
While there was a lot of love for Unity, the relationship between HTML5 and Flash was mixed among the panelists. The consensus seemed to be that some clients had started asking for HTML5 games, but not all. While most current Web-based games were still in Flash, there was an expectation that HTML5 would be escalating quickly due to its being backed by such large corporations.
The highlight of the panel, for me, was actually something shared by a non-panelist. It was a question I was going to ask as well, but
Andy Harris beat me to it. It sounds like he's in the same boat as I am, where he is constantly asked by middle and high school students what they should do to become a "game designer." When I am posed this question by prospective students, I explain, verbosely, the relationship between video game design and programming, the history of the two, and the transfer of skills among them. Andy had a much more memorable and clever explanation that, if you want to be a game designer,
you write the code or you write the check. All the panelists agreed. This was great to hear, but I couldn't help but feel a little bad for the handful of young aspiring artists in the room who clearly had not done their homework along these lines.
The importance of a portfolio was mentioned, and after a question from the crowd, the panelists clarified that a portfolio is as important for programmers as for artists. One panelist recommend grabbing a library like
Flixel or
FlashPunk, then creating ten games with them, each one exploring a different aspect of game design such as pathfinding or AI. This would provide you, as a programmer, with evidence that you have the range of skills required. This sounds like a great break project to me!
The panel had been advertised as running from 1:00 to 3:30, but at 3:30, it was only an intermission to be followed by some other activities. Looking over the handouts, it looks like one of the activities was to be drinks at
MacNiven's to talk about the IGDA, which would have been fantastic. Alas, I already had plans to return home for dinner, and so I had to step away. I am glad I was able to attend the panel, and it was great to see some of my colleagues whom I don't see very often. Next time, I'll try to keep time for a pint in my schedule!
