What I Learned at GDC: Indie Games Summit
Sorry about this post being pretty late, but I will have the rest of the What I Learned at GDC 2011 series posted within the next two or three weeks as I finish up my finals.
Today I’d like to talk a little bit about what I learned at some of the sessions from the Indie Games Summit. While I was not able to go to all of the sessions for the summit, I did go to a few in which I learned some valuable information for independent developers, or even students. This post will be a culmination of several different talks, including “Making Monthly Games” by Luke Schneider (Radian Games), “Retro City Rampage” by Brian Provinciano (vBlank), and “How to Win the IGF in 15 Weeks or Less” by Andy Schatz. I know that there were a lot of other great talks, but these were the ones I was able to make it to and took back the most from. If you didn’t get a chance to see them, I’d definitely recommend to check out all three on the GDC Vault if you can!
Independent Games have been rising in popularity to the point where everyone seems to want to make them. This isn’t to say that people shouldn’t make them, as I very much support the indie games community, but there are a few things that are helpful to know before trying to take first at the Independent Games Festival (IGF). The sections are divided up by the talks mentioned earlier, and most of this can apply to student projects, as well.
Making Monthly Games
For those who don’t know who Luke Schneider is or any of the games he makes, take a moment to check out the web site for Radiangames. He released seven games over the course of eleven months on Xbox Live. You can also read more details about his GDC talk at the Armless Octopus.
During Luke’s talk, he focused on three key features that helped him to make monthly games and still be successful. Those three features were scope control, not starting from scratch, and maximizing efficiency. When it comes to scope control, you want to keep things small and simple. It’s important to avoid anything too difficult, especially if you are a one person studio. Before you even begin creation of a game, you need to select a single platform and resolution, and stick with it. You should also put restrictions on both art and programming, keeping to simple things like arcade style art and basic programming concepts. Remember: you’re trying to build a game, not an entire engine. Luke suggests playing to your personal strengths and taking on only what you are capable of handling.
Another feature mentioned was to not start from scratch; this mostly applies when creating multiple games in succession. Creating a brand new project means new code, new art, new everything – something you probably don’t have the time, resources, or manpower to take on for each new game. Luke built one game from scratch, making sure the code was flexible, and then built all of his other games off that. By tweaking and adding in new bits of code, you save a lot of time and energy and can get a working prototype up almost immediately. There are a few drawbacks to this method, although it really depends on the kind of game you’ll be making. All of the games Luke has released have been very similar, so if you do not want that same effect, this might not be the best option for you. However, it is important to remember that by writing the initial code to be very flexible and creating different styled art for each game, you can avoid that sameness while still reaping the benefits of building off of earlier games.
The last key feature mentioned was to maximize efficiency. You need to remember that, although fun, creating games is still a job, and you have a lot of work to accomplish in a short amount of time. In simple terms: you just need to do it, and do it fast. Depending on your schedule and deadlines, you will need to get as much done as you can without wasting up valuable time that could have been spent doing more with your game. Like Luke said, just say no if it doesn’t help finish the game.
Luke completed his talk with a reminder that building the game is only half the battle. Remember to playtest throughout development, and have others playtest, as well. When it comes time for launch, things are going to be just as hectic as the building process, so try to get everything as organized and prepared as possible pre-launch. Launch is a stressful time for any studio, but it’s post-launch that is the most stressful for indies since it determines if the title is a success or a failure. Try to keep a level head through all of this and remember that not every game you make is going to be mind-blowing amazing.
Retro City Rampage
The focus of Brian’s talk was on the development of his game title Retro City Rampage, although you may have heard it under the name Grand Theftendo. Brian didn’t do what Luke Schneider was saying about not doing anything too difficult, and he actually built his own engine, level editor, exporter, and more. While this didn’t set him back (he said it only took him about a day to make all of that!), the development of the game took many years. During the talk, he identified some issues he came across during development, such as being overly ambitious; doing everything, including contracts, business, and PR work, himself; taking too much time polishing; switching platforms; and rewriting the code. However, through all of this, Brian was still able to create a fun and humorous game.
Brian mentioned a few things that indie developers need to have when creating games, which included passion, automation in some aspects of creation, and design skills. These are especially important when it comes to one-man teams, like Brian was doing. It’s also a good idea to make sure your game isn’t violating any copyright laws, since Brian had to scrap all of the original GTA content he developed because of issues with IP. He also suggested to focus on making the game functional, then making it fun, and always playtesting along the way. He stated that great ideas are often the evolution of good ideas, with Retro City Rampage serving as a prime example.
How to Win the IGF in 15 Weeks or Less
Andy Schatz’ game Monaco was a 2010 IGF winner and a 2011 IGC Finalist, and the details of it can be seen on the Indie Game Challenge site. You can hear more about his GDC talk over at GameDev.net or you can learn more about the game’s development on the Monaco Facebook page.
When Andy began development of Monaco, he began with board games to learn mechanics. Board games are literally all about game mechanics, so understanding the design behind them and being able to build your own is of great value. Andy began building a few board games before prototyping the game in an actual engine, and would recommend doing this whenever possible. When it came time to move to an engine, he chose one that already had the look and feel he wanted for the game, without needing to do a lot of extra work to get the right visuals. Andy tried to work on one “cool” thing every day, saying that anything considered “cool” would be considered cool from the player’s standpoint. By setting these milestones for himself, he was able to get a lot of work done of the game without losing inspiration. Working on cool things often kept Andy passionate and interested in what he was creating, which is something other developers could learn from if they seem to have issues in those areas. At the same time, however, you need to keep your ambition in check. Andy noted that he became too ambitious with the project, and things got complicated very quickly. Try your best to keep from getting too ahead of yourself when building games, and remember to keep things as simple as you can. Remember: the more cool stuff you keep adding, the more work you will need to do and the release of the game will get farther and farther away.
Like Luke and Brian, Andy mentioned that playtesting is very important, but you you don’t want to have only gamers playtest your game. He suggested bringing in non-gamers to playtest your game, and ask them questions like, “What did you like? What did you not like?” or “What confused you?” Simple, non-gamey questions can help you to get effective feedback from them, and it may shine things in a new light since non-gamers have a different understanding and perspective of games than gamers do.
I really wish I had been able to see some of the other sessions from the Indie Games Summit, but I will certainly add anything extra as I come across it in the GDC Vault. Hope this post provided some interesting insight from a few successful independent developers, and as always, feel free to leave any comments, questions, or critiques!