When I attended GDC 2013 I spent most of my time at the Independent Game Developers Summit where I got to hear many successful indie developers talk about how their projects succeeded and how they've stayed in business through both success and failure. In this article I'll go over the tips I found most useful, and the ones I believe will help you be the best developer you can be.
Design Tips
Whenever possible, reuse existing elements, rather than creating new ones.
Andy Hull
In Hull's mini-talk, he discussed the work he did on the indie game Spelunky when it was being brought to the Xbox 360, and how his experience as a wooden toy designer helped him. One of the things he discussed was the fact that when you are designing a wooden toy, which actually has to be mass-produced, every aspect of the product has the potential to drastically increase the price of production. Even something as simple as adding an extra paint color increases the time and money that go into the production of a toy.
While this is not the case for video games, at least not technically, it is still very important to make good use of the game elements you have, and be cautious about adding too many elements to your game.
While developing Spelunky for the Xbox 360 the designers started to look at the usefulness of each weapon in the game, and determined that the Pistol was essentially an inferior version of the Shotgun, another weapon within the game. On top of that, Pistols had an entire ammo system that was not shared with any other items, and thus having and managing a Pistol could be annoying for the player.
When moving the game to the Xbox they decided to remove the Pistol and replace it with a Boomerang. Not only did the Boomerang do many of the same things as the pistol, it also had the added bonus of being able to hit enemies behind you if you jumped when it returned to you, instead of catching it. By removing the Pistol it gave them the freedom to add a new item to the game, and allowed them to introduce a new mechanic.
As Sid Meier says, "A game is a series of interesting choices". By making sure that your gameplay mechanics are each unique, and that there is very little overlap between their functions, you are keeping the choices interesting for the player, and giving them a reason to come back. When evaluating your gameplay elements ask yourself what the purpose of each one is. If you find two elements are very similar in nature, you may want to consider cutting one or re-designing it so that it is more unique.
Don't be afraid to take a step back and re-design or re-develop.
Dylan Cuthbert
In his talk, Cuthbert discussed the idea that sometimes, even when you have a good idea, it may be blocking you from seeing a better idea.
Before Cuthbert founded the game studio Q-Games, he worked on the original version of Star Fox for the SNES. When he was working on Star Fox, they had originally planned to make all of the levels big open areas that the player could fly around and fight in as they pleased. While the mechanic worked, and seemed to be interesting, the game itself wasn't as fun as they thought it should be. The game was in this state for a number of months until eventually the director came up with the idea of removing the free-roaming aspect of the game.
At the time this idea seemed absurd because so much of the game was based around the fact that you could fly anywhere in the game field. On top of that, free-roaming was very popular at the time so it also took away what seemed to be a huge draw to the game. Despite both of these things, when they removed the free-roaming features of the game, they found it actually became easier to develop because they had more control over the player's experience and what they were doing at any one time, and it became more fun because the player couldn't get lost, and had a greater understanding of what was going on.
While it may seem absurd at first, it's important to remember that no matter what kind of game you want to make, there is no feature that has to be in your game. Evaluating your game from multiple perspectives and trying out many different ways to implement the same type of mechanic will often lead to much more interesting games. On top of that, just because a feature seems integral to the game, it doesn't mean it is. A good question to ask yourself throughout the development of your game is "What is this feature occluding?" or "Is there a better mechanic being hidden by the shadow of this mechanic?" Simply put, don't be afraid to remove a mechanic from your game, because that may end up giving you the inspiration for an even better mechanic to use in that one's place.
I think it's also interesting to note here that while they worked on Star Fox they would often add mechanics to see how the game changed with the new mechanics included, and then remove them just as quickly. This allowed them to truly see the contrast of the game with and without the mechanic, which gave them an even stronger understanding of how it affected the game.
Focus on the content.
Matt Gilgenbach
In his talk, Gilgenbach discussed how his personal struggles with OCD and perfectionism hurt the development of his indie game Retro/Grade. While developing the game Gilgenbach obsessed over the look of the game and getting a number of advanced graphical features implemented, but in the end his time would have been better spent expanding the actual content of the game and not just making everything especially pretty.
Retro/Grade was a rhythm-based game that was in development for multiple years, yet when it finally released it only had 10 playable songs. The problem he ran into was that he didn't focus enough on content development, and focused instead on making the game engine more capable, and adding unneeded features and visuals. For example, look at the large "Octo-bot" the player is fighting in the video below:
In Gilgenbach's talk he said that there are actually a number of complex animations being done by the Octo-bot's eye, and that he spent many hours on the 3D model making sure that the eye would function correctly as if it were a real object. In a game where you had a lot of close-ups of this model or character, this would be very important and would be a good use of time, but in this game, and in this example, it's not. You can barely see the eye - and, even if you could, it is a minimally important aspect of the character at best. If Gilgenbach had spent more time on content development, or removed some of the visual features that made the art assets so time-consuming to produce, he would have ended up with a better final product overall.
When working on your games, don't let your own perceptions of the game, and the miniscule things you want fixed, prevent you from seeing what's truly important. Always consider how the thing you're working on will impact the player and their experience, and always ask yourself whether a feature will increase sales or the player's enjoyment of the game itself.
Development Tips
Reinventing the wheel is a trap.
Devin Reimer and Alexander Schwartz
In this talk, the founders of Owlchemy Labs discussed how they keep their business successful and what they do to minimize wasted time when starting new projects. One thing they touched on was the fact that you should never spend substantial time trying to do something from scratch when you could just as easily use existing tools or software to get the job done much more quickly.
As an indie developer you are either going to be making a completely original game, or doing contract work for a publisher or outside source. In both of these scenarios, having to spend countless hours at the beginning of the project implementing basic keyboard controls or getting the game engine to draw 2D images correctly, would be a waste when you could be spending your time on more important things like implementing advanced gameplay features, or balancing all of the different gameplay elements. In the end, your time is better spent designing and polishing the game, not programming a system that you've made a hundred times before.
When starting a new project, always consider whether there is an existing engine or tool you could be using, or if you could recycle elements of the art style from other games you've previously made. It's important that all of your games be unique, but it's also important that every game you make gets finished before you run out of money, so if there are ways to speed up the development by using existing tools or resources, you may want to at least consider those ideas.
Choose the right art style.
Ian Marsh
In his talk, Marsh discussed many of the things he learned over the years his company NimbleBit has been in business. One of the things he discussed was the impact your choice of art style can have on your game. Not only does the art style dictate the look and feel of the game, it also has a profound effect on how long the content will take to create. Some art styles, by necessity of their complexity, will take substantially longer, or require many more people to be executed well, so choosing to go with one of these styles could be very damaging for an indie developer.
While it would be great if you had the time or resources to commit to making your indie game look like Halo 4 or Diablo 3, those art styles were both developed over the course of many years by teams of hundreds of developers and artists. Expecting to be able to reproduce that level of detail and quality with a five-man team on a shoestring budget is simply unrealistic, and will likely prevent your game from ever getting completed.
Choosing an art style is an important step, and every aspect of that decision will have an impact on the time and energy it takes to develop each art asset. If you are making a game which could be done just as easily in 2D as it can in 3D, then committing to having full 3D assets with normal maps, specular maps, transparency maps, diffuse maps, and reflectivity maps, would be a waste and would needlessly expand the scope of development and the number of team members you would need to complete the game.
The takeaway here is this, choose your art style carefully because it will impact how players perceive your game, but it will also impact how hard your game is to make, and that is just as important in the end. Don't harm yourself by committing to doing something that is beyond the scope of your team or project and instead find the middle ground of an achievable style which also conveys the meaning you intended.
Be careful how much time you commit to each project
Multiple Talks
These are actually two tips from different sources, but they are both related to time management so I thought it was best to keep them together like this.
The developers at Owlchemy Labs said that over their career they have determined you should never spend more than a week on a prototype, because one day of prototyping is roughly equivalent to one month of polishing. This tip is somewhat specific to their team and the fact that they generally work in six month cycles, but the idea is that it's important to know how your team works and how long you usually take to accomplish a given task. This helps when determining how much time to give to a project, and when trying to figure out whether to continue on a given project, or simply move on to a new one.
Ian Marsh from NimbleBit said something similar when he said that an indie developer should never spend more than 6 months on a project. As an indie dev, especially early in your career, one of the most important things is to make as many games as you can so you can gain a lot of experience in a short time, and so you can figure out what you are good at and what you are bad at. If you put too much time into any one project it will prevent you from moving on and trying other things. On top of this, the extra time you put into the original project will just put more pressure on its success and will make its potential failure even worse.
By limiting the amount of time you commit to a project you are preventing that project from becoming bigger than you originally intended and preventing yourself from going overboard. It sucks to end a project early, but - and trust me on this because I've experienced it - it can be far worse to be entering the second or third year of development on a project you didn't expect to last longer than a few months. Sometimes you just have to let go.
Business Tips
Consider all three player types: players with skill, players with time, and players with money.
Shane Neville
In Neville's talk he spoke about the development of Shellrazer. Shellrazer was specifically designed to have in-app purchases, but Neville knew that if he geared too heavily towards those purchases the game likely wouldn't be very fun and would never attract a large user-base to begin with.
To solve this problem, the developers considered three different player types when working on the game: players with skill, players with time, and players with money.
To attract players with skill they worked extensively to make a strong combat system which had its foundations in classic RPGs. This allowed them to create a truly fun and engaging game that people would want to play even if they didn't want to spend money. The strong combat system also made it more likely for the game to draw in large amounts of players.
To attract players who had lots of time to play but who may not be very skilled, they gave each level an element of randomness in what enemies you encountered and in how the waves of enemies were constructed. This meant that even though the level would be physically identical no matter how many times you played it, the types of enemies you would be facing would never be exactly the same. This kept the game more interesting through replays and grinding sessions, and prevented less skilled players from becoming bored when they replayed levels for the third or fourth time.
Finally they considered players who had little skill, and little time to commit, but who were willing to put in money so they could see all of the content. For these players they made sure that it was possible for the player to purchase every item in the game, and upgrade every item to its maximum level, for $50 or less.
By doing this it meant that they had a strong understanding of how valuable each item needed to be in-game to make a purchase worth it since they could compare the cost of that item to the cost of the game as a whole, and it meant no player would ever go poor paying for services in their game and allowed them to "keep their souls", as they put it. Really, they just treated the players who were purchasing content as players, and not as cash cows like larger companies might.
Each player type required different considerations when making sure the game was successful, but by working hard to keep all three happy, they ended up with a stronger product than they would have otherwise.
Packaging is just as important as the product you're selling.
Andy Hull
Another thing Andy Hull discussed, while talking about his experience with wooden toys, was the importance of good packaging. In some cases, like a play-set based on an old-timey band, the package was an actual wooden crate which greatly added to the authenticity and feel of the product since even the packaging felt like it was part of the product. Doing this made the product more expensive, but it also made the product more appealing to children and parents because it increased the quality of the product as a whole.
In games, the packaging is the screenshots, the box art, the trailer, and everything else that goes into turning potential players into purchasers and fans. Making sure the "packaging" of your product reflects the quality of the game itself is incredibly important.
When preparing to release or promote your game, take the time to ensure that everything you release that's related to your game has the same appeal as the game itself, and make sure that you put the same time and energy into the packaging as you do the rest of the game. By making sure to get high-quality screenshots that really show off the game's better points, and by putting the time into making a truly incredible trailer, you are making your game seem more appealing and hopefully making people more likely to buy it.
Promote your game as much as you can.
Multiple Talks
This tip was actually echoed at many of the talks I went to and was mentioned in passing at even more. As an indie developer, one of the hardest things is often getting your work seen. With this in mind, you need to do everything you can to get people talking about and thinking about your game.
The simple fact is that you, and the rest of your team members, are probably the biggest fans of your game. While some games are lucky enough to have huge fanbases, a lot of indie games don't, and the few that do still don't have anything as big as even some small major releases. With this in mind, you need to do everything you can to spread the word about your game, and make sure that any potential players you meet know what it is.
One of the best tips I heard was that you should never be afraid of going to public events. It's easy to go to events like GDC and talk about a game you're making since you know other developers will probably be able to look past rough edges, but going to public events like PAX, or even small local conventions, can be scary since you are afraid of what potential players might think. Don't let this fear stop you from going though. Remember, every person you meet is a potential player, and if they've never heard of the game then it's a great opportunity to tell them about it. On top of that, these people are at these events because they like games, and if yours is fun they'll look past the rough edges too.
Also, don't limit yourself to just gaming events, there are lots of places you could try and get attention for your games such as local colleges or festivals, or even public places with bulletin boards. If you have a game and you want it to get attention, you should take every chance you have to do so, not just the 'safe' ones.
The point of this tip is simple: promote you game every chance you get, because any player you can find is worth having. On top of that, word of mouth is the best way to make something popular, and anyone you can convince to play your game, has the potential to get other people to play it too.
Those are the lessons I took away from this year's GDC. While some of these lessons may not be applicable to all developers, and some may simply not apply yet, there is a lot of good information here and I hope that all of you were able to get as much out of it as I personally did.
If you want to see any of the talks from GDC 2013, or any previous GDC event, you can go to the GDC Vault where they have a number of free talks from past events, and most of the other talks are available for varying fees. On top of that, many speakers uploaded the slides or audio from their talks online, so if you search around YouTube or game development communities you may be able to find some there as well.
By
