Experimental Game Dev Interviews — The First Game Dev Podcast Ever
RSS icon Home icon
  • Podcast Interview: Andrew from IBeta Quality Assurance talks about QA for Indie Games…

    Posted on September 24th, 2008 IndieGamePod No comments

    Andrew, from IBeta Quality Assurance, talks about QA for indie games…

    You can download the podcast here…
    http//www.indiegamepod.com/podcasts/ibeta-podcast.mp3

    or listen to it here…
    http://www.indiegamepod.com/dewplayer.swf?mp3=http://www.indiegamepod.com/podcasts/ibeta-podcast.mp3

    Take care,
    Action

  • Podcast Interview: Ryan talks about student game development…

    Posted on September 24th, 2008 IndieGamePod No comments

    Ryan, talks about student game development…

    You can download the podcast here…
    http//www.indiegamepod.com/podcasts/ou2-podcast.mp3

    or listen to it here…
    http://www.indiegamepod.com/dewplayer.swf?mp3=http://www.indiegamepod.com/podcasts/ou2-podcast.mp3

    Show Notes (thanks to Grace):
    Interview with Ryan , on sound effects, gaming, and animation.

    Interview was held at the Austin Game Developer’s Conference.

    Ryan was part of team of 9 developing a platform, puzzle, interactive environment concept game called “Death by Design”. The team consisted of 3 designers, 2 programmers, 1 sound person, and 2 artists. [yes we’re missing somebody]

    The game started as a class project with a deadline of 20 weeks. The team started with a couple of different ideas. One idea was an incredible machine type game, the other was something called “Death Quest” where the idea was to get your avatar killed in the most extreme way.

    They did rapid proto typing using paper and a magnet board. They used this method along with design documents and had their idea pretty well done before beginning programming or artwork. Once they had their idea down they then let their imaginations go wild, taking the concept as far as they wanted without limitations of reality (programming concerns for example). If they hadn’t done this then they would have self-sensored and it wouldn’t have been as good. They ended with a fully realized concept.

    Most people who create platform games follow a standard formula: Run right, keep the character alive for as long as possible, pick up a few objects, and then move onto the next level. They chose a static world, still picked up a few objects, but then completed some crazy objectives, and then something really silly and stupid would happen to the avatar. It was a lot of fun.

    The team would have something called game jams every week at coffee houses. Here they would take 24 hours to work out concepts and levels to the point where they were complete.

    Initially they came up with 12 levels but in the end the game was completed with only 2 levels. They were working on it up until 3 hours to deadline. They felt successful that they had actually completed the game. During the whole process there was never a slow period where they felt like they were just finishing up. The whole time they were like “Oh my God! There are problems!! There are problems!!”. Once the game was done though, it was the best feeling.

    There were issues. One issue is that everyone wants to be a designer, so if you are on the design team you should roll with it and listen to all suggestions, take it in, because everyone has something to contribute. If these people are working in games, then their gamers, and they know what gamers like. All their input is useful. If you then get a chance to use testers outside of the team, listen to all of their suggestions too.

    As part of the design team you need to keep your team moving, but you also don’t want to beat them into the ground.
    Top 3 things Ryan learned:
    1) No matter what you think it’s going to look like in the beginning, it won’t look like that in the end – and that’s not a bad thing! It probably means you learned something. Also be open to outside input, it’s very valuable.
    2) Don’t take ALL the outside input! You can lose the integrity of your personal touch.
    3) Working with people is challenging, but rewarding in the end.

    Advice to wanna be indy game developers – Come to Austin Game Developer’s Conference!

    Take care,
    Action

  • Podcast Interview: Producer of Student Game, Chromatica

    Posted on September 24th, 2008 IndieGamePod 1 comment

    Gene, from student-developed game Chromatica, talks about developing an indie student game…

    You can download the podcast here…
    http//www.indiegamepod.com/podcasts/chromatica-podcast.mp3

    or listen to it here…
    http://www.indiegamepod.com/dewplayer.swf?mp3=http://www.indiegamepod.com/podcasts/chromatica-podcast.mp3

    Show Notes (thanks to Grace):
    Interview with Monjoni, gaming student, and part of the production team of Chromatica. http://www.chromaticagame.com/index2.html

    Interview was held at the Austin Game Developer’s Conference.

    16 students in Ohio University’s brand new game development program, were asked by their professor, John Bowditch, to come up with a game during their first week of class. They all sat in a room and thought about what they were good at, and what they were capable of, and came up with a series of game designs. At the end of the week they picked one which turned into Chromatica.

    Students as a rule are hard to manage. There are personality conflicts, and especially with a team of 16. There were a couple of incidents which Monjoni speaks of. In one, a stressed member of the design team created a big scene when a meeting was scheduled at a time when she couldn’t attend. In another example, a couple of people on the tech team were fighting over who was doing more work. Monjoni says that there were some huge fights which required mediation and a desire on the part of everyone to come together and work harder on the game. Drama won’t get the game done – sitting down and working, will.

    Two people who’d never done code before in their lives were put on the tech team. The game was started in Torque game builder. They went through what few tutorials there were. They were overwhelmed! They put their noses to the grindstone and for the first solid month spent all their time learning code, even weekends. The made mistakes, but worked through, figuring out their mistakes and fixing them. After three months an experienced coder came into the project and analyzed their code and helped them with their mistakes. It was a learning experience for everyone. Sometimes that happens, you get thrown into a situation you’re not comfortable with. You’re a student, you’re supposed to make mistakes. What’s important is that you learn from your mistakes and move forward.

    Problems for management are more about motivation than size. Every team no matter how big has a naysayer or two who aren’t excited or even interested in the game they are helping create. The hardest thing as a producer is getting these people excited and interested in the game. Some people just aren’t excited by certain genre’s of games. Professionalism is doing the job well even when it’s not exactly, or even close to the kind of game you might have wanted to do. If you feel like “I don’t want to do this – this doesn’t matter” – punch yourself in the face, because you’re wrong!! Everything you do as a student developer, matters. If you forget that, you’re screwing your own future.

    The design doc for Chromatica was done during first month of development. Mockup, story, and levels were being developed during the same period. It took them too long to find the fun. Weekly QA tests helped them find the fun. He regrets not doing QA earlier. His advice is to get your prototype out there early and have QA early. Also, if it’s not fun then go back and fix it. The game has to be fun – #1 rule!

    They worked on the game up until the last minute before shipping. Only three days before did they feel that the game would be successful. If you’re a student and it’s early in development, don’t be disheartened, it won’t look like a game, or much of anything, for awhile. Once you get other people outside of the team in to play it, then you’ll start to see what you really have.

    Top 3 Lessons:
    1) Game development is a whole lot of Hell – but once your game gets out there, there’s no better feeling!
    2) Players are the most important thing! Get feed back from people outside of the team. They will affirm everything you thought was wrong and right about your game.
    3) Student development is a wonderful opportunity. Even if you’re not a student, get out there, get a team, and make a game. It’ll be the best experience of your life!!

    Take care,
    Action