I’ve heard Alex speak a number of times in the past and a recurring theme is that he is always being asked when his game is finished, and when it will be released. Alex has some strong views on this that I completely agree with, relating to quality levels required before a game is ready for release. Our own game Battle Group has been pushed back from our (internally planned) release date a number of times in it’s 4 month development. It’s a recurring theme on every game I’ve worked on, both independently and at larger studios, they are always late. The question is, how can we objectively determine when the game is finished?

“You’re game is finished when someone who hasn’t played it before can play through it’s entirety without assistance” 

Lets dig a little into what this means. Firstly you (or a few key team members) need to sit and watch people play your game. If you’re not doing this, your game shouldn’t be released, period. Without sufficient playtesting there’s no objective way you can determine if your game is ready or not.

Someone can only play through your entire game once you have no show stopper bugs. I can play a game I’m working on for days on end and never come across an issue which a play tester finds within the first few minutes of playing. The game also needs to teach them enough to be able to play through it’s entirety without your help. This is a really difficult task when watching someone make seemingly simple mistakes in your game. I’ve spoken about this previously with “Virgin” playtesters and spending the weekend watching people play Battle Group only reinforced this for me. If you have to help someone through a certain part, something is wrong.

Related to bugs and assistance is the requirement that you are happy to show people the game in it’s current state. This seems like a no brainer, if you’re not happy to show someone, why would you release? Surprisingly, I’ve seen a number of people so desperate to “just get it out there” that they break this rule. They were all apologies and excuses when I tried to play the game but they felt they were still ready to release it to the world, as if people they don’t know would be more forgiving.

When deciding when a game is finished, there are two areas that people run into trouble:

1. Some people fall into the “it’s never finished” trap. They are usually small teams that aim for absolute perfection and are never happy with the game. These games often disappear and the team gets bored and moves on to something else.

2. At the other extreme are games that are shipped far too soon. These often come from larger studios with external time and money constraints imposed on them.

Either extreme is dangerous and obviously we want to aim for the middle ground between these. Knowing which end of the spectrum you are more likely to favour is important so you can set expectations at the start of the project. The further a game progresses in development the easier it is to diverge towards one of these extremes. When talking about setting the quality level before you begin production on a game I use the analogy of going out drinking. It’s important to set the number of drinks you plan to have in an evening before you start drinking as once you’ve started down that path, your judgement is impaired. The longer your on a project, the more impaired your judgement becomes. Either wanting to “get it out the door” because your sick of working on it, or not wanting to waste the months you’ve been working by releasing an imperfect game.

Only by setting your expectations at the beginning of a project can you have a reasonable chance of setting the quality bar at a safe level. Look at the team makeup, objectives of the game (retail success vs portfolio piece) and project budget/length when deciding what quality bar to aim for.

Multi-platform development

If, like us, you’re making games for web and iOS then this is really a no-brainer. The extra development time is not something we can afford when there’s a perfect alternative in Unity. With Flick Buddies, we developed the web and iOS version simultaneously without any extra effort. All our games in the future will see simultaneous releases for both web and iOS which will help drive customers from the free web version up to the paid iOS version.

The main argument against using Unity is that with such a low penetration rate (for arguments sake we’ll go with 1%) users will bounce from your site when they hit the Unity installation page. Taking the statistics (from Unity and others) lets go for the low end and say that 50% of users will bounce when they see the Unity installation page.

Rather than looking at it from percentage of users being lost, let’s look the other way around. If you’re developing an iOS game you can release a web version for relatively little development cost and capture 50% of the potential web market. If you were to instead create a flash version you would have the full development costs of porting the game to get 100% of the market.

Looking at the cost/benefit ratio the Unity version is a much better option. The only time this becomes a negative is if you have a highly successful game, in which case losing 50% of the market will end up costing an order of magnitude more than the development costs of porting to flash. In that case, go for it! There’s nothing stopping you from later creating the game in flash once you know there’s a large enough market for it.  Where the cost of porting the game will easily be made up by the 50% more users you’ll receive.

Another interesting point I’ve heard is that the more popular a game is, the lower the bounce rate.  If you have a highly successful game that people really want to play, the act of installing a plugin will be less of an issue for them. This goes some way to negating the lost sales for a highly successful game.

Web games only

What if you’re making web games only? In this case it’s not quite as clear cut and we have to dig a little further. I’m still inclined to go with Unity for web only games for a number of key reasons:

1. You can give a richer game experience including 3D. While 3D is coming to Flash soon, it’s at a lot lower level requiring far more development time and cutting out many less experienced developers.
2. Much richer tools and pipeline. I’ve previously discussed how much I love the Unity editor and asset pipeline. This lets you get your games out faster and cheaper. This saving offsets the 50% bounce rate.
3. There’s the opportunity to have a unified language running between client and server when using C# within Unity.  This simplifies communication as well as allowing the exact same code to run at both ends if required.

The Minecraft example

I like to use Minecraft as an example of bounce rate when discussing Unity and Flash. Minecraft requires an .exe to be downloaded and run before the game can be played. This is far more intrusive than a browser plugin and yet it’s still had great success. With Unity developers can create something as successful as Minecraft with a lower bounce rate due to installation and have the ability to port to iOS and other platforms easily.

Flash was once like this

I remember when Flash was at a similar position to Unity, albeit with web pages rather than games. Many people said that you shouldn’t make websites with Flash as it required users to download a plugin if they didn’t have it. Not only did Flash reach the penetration rates it desired, times have also changed in Unity’s favour:

1. Faster downloads mean there’s less of an issue in the download time of the plugin
2. Seamless installation reduces the bounce rate with unsophisticated users
3. Larger sites (like Kongregate) are getting behind Unity which makes it more trustworthy in users eyes

What can Unity Technologies do about it?

I saw a similar issue with Silverlight penetration and I find myself again thinking of inventive ways for companies to increase penetration of their plugins. This could be as simple as a referral program, offering 1-10c each time a user installs the Unity plugin on your site. This motivates developers to make awesome free games with a guaranteed return as an alternative to advertising. Unity can then buy installations for as little as $10k per 1 million users.

It’s in Unity Technologies best interest for penetration rates to go up as quickly as possible and I’d like to see a novel approach to achieving this. While the penetration rate will naturally increase over time, it will take quite a while.

Conclusion

What are your thoughts on Unity’s penetration rates? Is the bounce rate just too high for you to switch over?

What do you want to get out of your game?

Many indie’s are soldiering along in a multi-month (or multi-year) project without having clearly defined goals for their project.  When asking developers the common responses included:

• Express creativity or artistic ability (e.g. I just have to be making games all the time, to stop the voices in my head)
• To make enough money so I can quit my day job and go indie full time (often accompanied by a long tirade of complaining about current boss)
• Bootstrapping a larger game company
• To get girls!

If you haven’t already, stop and list the top 5 goals you want to get out of your current game.  Do this for each individual team member, as well as the team as a whole.  Make sure each team member is compatible and make sure the goals are realistic.  More importantly, look at whether the game you are making is the best way of achieving your set of goals. 

Write this list on a piece of paper and put it on the wall.  Every time you (or your team) have a question or are unsure of a direction to take, use this list to help with the difficult decision.  It’s crucial that everything you do is driving you towards these goals otherwise you will not reach them.  This is particularly important if you are making your independent game in your spare time (as most people I spoke to are).  The less time you have, the more productive your limited resources must be.

We’re all on the same team: share, learn and collaborate

Unlike mainstream game development, we are not competing with each other.  When making small, low priced games, there’s less competition than between the big developers.  Gamers can easily buy many awesome indie games released on the iPhone for less than the cost of a single full priced AAA title.  It’s not you OR another indie, it’s you AND another indie.  As people start to enjoy games from indie developers they are more likely to buy more indie games.

Everyone has their own strengths and weaknesses.  This also goes for small teams.  Unlike large developers we can’t just hire in the top talent to do a specific area of development.  However within the indie community there will usually be someone with the specific skill you are after.  By maintaining an open relationship between indie developers we can tap into a larger pool of resources to help with specific problems.

Finish SOMETHING

Get out there and finish something.  Many indie developers I spoke to were in the middle of working on their first indie game.  Some developers had been doing this for months or even years and still hadn’t released their first game.  Common reasons for this included:

• Stopping work on a project to start on a smaller game (which is often still too ambitious)
• Getting bored with an idea and moving on
• The entire game was one big feature creep where it would never be finished
• Far too ambitious for the team size and skill

Pick something extremely small and make it.  Adam Atomic gave one of the keynotes at Freeplay and commented on how Canabalt took him five days to create.  While he may be an exception, it goes to show that small, successful games can be created in a short period of time.

For your first game, I recommend giving yourself one month and creating whatever you can in that time.  Aim to complete the game in three weeks with one week of polish.  It’s important that you release something.  Like building a deck in Magic: The Gathering, it’s a lot of fun making a game, however until you’ve released it, you haven’t fully experienced game development.

It’s the best way to learn.  You can talk to as many developers as you want, go to as many conferences or read as many books as you can find.  Nothing compares to the experience of releasing a game.  You’ll learn a lot about yourself, your team and your players.  This ranges from time taken for polish to headaches with distributing your game after it’s complete.  It will also make your next game better…

Finish something GOOD

The next largest group of indie developers I spoke to were those that had released a small game that had reached little success.  Many of these games were (almost) direct copies of existing games.  If you want to have a successful game, you need to make something that stands out.  Put yourself in the shoes of your player.  Why would they buy your game?  What value do you add to their gaming life?  If this isn’t an easy question to answer then you need to stop and re-assess your main goals.

Conclusion

Are you working on your first indie game?  How long have you been working on it, how do you keep motivation and what are your top five goals from the project?

Over the past few years the mainstream has moved further towards sequels, playing it safe and limiting creativity.  It seems indie game developers are reacting to this by becoming “more indie”.  A case in point is the IGF.  Many of my indie friends complain that it’s impossible to win the IGF without making a controversial game that has no chance of making money.  Surely we can find a middle ground between these two opposed views.

Let’s look at key parts of game development and see where Mindie developers fit into the mix compared to pure mainstream and indie developers.

Profits – Money is the root of all evil but the source of all Twinkie’s

Most indie developers I know don’t have the luxury of making games just for the love of it.  At the end of the day, we all need money to live.  Mindie developers are mindful of making a profit from their games but not at the expense of the game itself.  The current landscape of game distribution is the perfect time for this lofty ideal.  Digital distribution, micro-transactions and huge user bases on platforms like Facebook mean that we no longer have to make a boxed product that sinks or swims based on the first few months of sales.  This gives Mindie developers the freedom to flex our creative muscles and then find a sales model that fits our product.  There are many options to take opening up many more possibilities for game design and creativity.

Competition – Competition creates better products, alliances create better companies – Brian Graham

The general consensus is that indie developers don’t focus on their competition while mainstream developers are obsessed with them.  Where does the Mindie game developer fit in?  This time, we are closer to our indie roots.  While it’s important to be aware of the competition and create something new and interesting, it should not drive development.  Indie developers begin with their own ideas and creativity and adjust their plans based on competition.  Mainstream developers begin with their competition and adjust their plans slightly to create their own game.

Publishers/Investors – Time is more valuable than money. You can get more money, but you cannot get more time – Jim Rohn

The traditional indie developer is defined by not having a publisher or large investor, hence the term “independent”.  They are usually self-funded or take on small amounts of angel investment.  The general consensus from mindie developers is that they would take on money, so long as it doesn’t water down their game.  This is often shown by their realistic expectations of money required rather than the “more is better” attitude of most mainstream developers.

Project Size – It’s not the size of the dog in the fight, it’s the size of the fight in the dog – Mark Twain

Mainstream loves big, multi-million dollar games.  Every year the cost keeps going up.  Indie developers either through love, or more often than not, through necessity go for simple, small projects.  Mindie developers need to find the middle ground again.  Projects that are of a substantial size that they can make a profit while keeping development costs low at all levels of development.  From team sizes to feature lists, they focus on finding the fun with the least possible features.

Art – If you think a game is ‘Madden 2008,’ then hey, games probably aren’t art – Jonathan Blow

Many indie developers make art.  Mainstream developers are skilled in the art of spending copious amounts of money making a game that is 10% better than the previous game or competitor.  Mindie developers are pragmatic.  They focus on making a fun, deep game and letting everyone else decide whether it’s art.  Pragmatism over pretentiousism*.

*Yes that’s not really a word, but neither is Mindie

Conclusion

So that’s my attempt to bring some unity between the mainstream and indie developers.  I look forward to seeing what the coming years bring for mindie’s and particularly in Australia where the collapse of the mainstream game development industry has left most of my friends turning indie in hopes of fame and fortune (or at least recognition and Twinkies).

What do you define as a mindie and are you one?

The Problem

Indie developers have trouble finding other like-minded indie developers to work with.

I talk with a lot of indie developers and they tend to fall into three main categories:  programmers, designers and artist.  Each of these groups has a hard time finding quality people from the other two groups.  This is a major problem for indie game development as fewer games are being produced and talent is going to waste.

The Cause

The main cause of this problem is a lack of communication between the groups.  There is no reliable way for Programmer Pete to find Artist Andy or Designer Dave.  Pete was in the games industry for 10 years before “going indie” but he knows few people.  He kept to himself and while he is friends with a lot of other programmers he hasn’t kept in contact with many artists or designers.  Andy has a lot of trouble finding programmers and designers he can work with.  They are always so restrictive in what they let Andy achieve.  Dave is full of great ideas but can’t find a good programmer who’s happy to implement his idea.

There are hundreds of Pete’s, Andy’s and Dave’s in the world, but few of them know or have a reliable way of finding each other.

Key Contention Points

In the rare occasions when developers from these individual groups do meet up, often they are incompatible.  From my experience, the key points of contention fall into these main categories:

• Compensation – Working for free, profit share, an hour rate or a fixed amount.  Where a developer is in their life will often drive their monetary needs.  While Dave has 3 years of savings he’s happy to burn through, Pete needs a large paycheque to buy all his programming books and pizza.
• Game Type – Each developer has their favourite game type and many developers don’t like to stray too far from their comfort zone.  Andy just wants to work on an FPS but Pete is an RTS fanatic while Dave has an idea for the greatest MMO of all time.
• Game Size – Projects range from days to years to develop.  The level of investment needs to match each individual’s situation.  While Pete might be happy to spend the next 3 years slowly plugging away at a game, Andy wants it down within the next month so he can get back to working on his comic book.
• Availability – The bills still need to be paid and the time dedicated to a “real job” directly affects how much time each developer can spend on the game.  Pete is a contract programmer who has half his week spare to work on the game while Dave works at McDonald’s 50 hours a week to make ends meet.

The Solution

One solution I’ve seen for this problem comes in the form of “help wanted” sections in popular websites such as gamedev.net and indiegamer.net.  These sites allow teams to post their project and the skills they are after.  Another solution is networking.  Taking every opportunity to meet like minded game developers and talking to as many people as possible until like-minded people are found.  Whether visiting an IGDA meeting, the GDC or the local game development educational institute.

I’ve often thought that a site dedicated to connecting indie developers would be beneficial.  Teams or individual developers could post their projects with exactly what they are looking for.  Developers can also post their skills so others can find them.  A match making system could connect these two groups and reduce the uncertainty when looking for other developers.  Do you think there’s a need for such a site, or does this site already exist and it’s not well known?  Would this site be beneficial to your current situation or are you happy with the current solutions?

Conclusion

Is this a problem you face as an indie developer?  Of all the indie developers I know, over half of them are facing this problem right now.  Have you managed to solve this problem, and if so, how?  How are you currently finding other developers to work with and how do you determine if you are compatible?

Roles

Game development involves a number of common roles as well as some overlooked ones.  Individual team members can handle multiple roles on smaller teams and some roles can be shared by more than one person.

Programming

Programming on an independent team is about more than just game development.  The programming department will be responsible for tools and website development.  They will also have to handle the creation of the installer.

Design

Design is one of the great areas it pays to share ownership.  The designer has the final say on decisions and is the go to if people are unsure.  They also maintain the game design document to unify the team.  A wiki is a great way to collaborate on the design document.

Art

The art department is responsible for not just game art but also creation of marketing material and web design.  Artists need to work closely with the programmers to make sure technical requirements are met and to drive the requirements for tools.  They also need to collaborate with design to make sure the look and feel of the game is met.

Sound

Often overlooked, sound is vitally important to give atmosphere to the game.  Sound should not be left to the last minute as it will feel disconnected and won’t add as much to the game.  The programmers should build the infrastructure for the sound early to allow experimentation.

Project Management

Project managers are responsible for the velocity of the team (how much they are achieving each milestone).  They need to be aware of when team members are falling behind and make sure everyone is performing their duties.  Visibility is the key to making sure everyone on the team is aware of their current goals and deadlines.

QA

Without QA the game will be unplayable.  QA is another area that is good to share across the whole team.  The team should be playing the game constantly and fixing bugs as they go.  It is preferable to have non-programmers doing QA as it is easy for them to overlook issues in their own code.  Sharing the games with friends and having a beta-testing period is a great way to share the load.

Business

Without someone managing the business side of game development, you may as well be making the game just for fun.  One team member needs to be responsible for making sure the game will be profitable.  The entire team needs to be mindful of the fact they are making a game for profit, not just fun.  Business includes marketing, sales, business plan writing and possibly seeking funding.  The team needs a business plan covering:

• Marketing Strategy – How will people find out about your game?  How will you sell the game and how much will it cost?
• Cash flow Summary – What are the expenses of the team and how will you afford to keep the business running?
• Economic Assessment – How much do you expect to make from the game, based on similar games

Co-Location

If possible, the entire team should work together in the one building.  This lets the team quickly test ideas, keep each other motivated, play-test the game together and watch each other play.  Renting an office is expensive and it’s important to keep costs as low as possible.  Get creative, work together on laptops in a coffee shop, move in together, or work in each other garages or basements.

Workloads

Depending on the situation each team member may have differing hours they can devote to the project.  Each team member’s level of commitment should be discussed and decided up front.  The closer these levels can be the better.  Having a large imbalance in working hours can lead to resentment and hostility between team members.  Some ways of evening out imbalances include:

• Larger share/profit ownership
• More creative control over project

Personalities

Personality trumps ability on indie teams.  As with most high-intelligence professions, game developers often have strong personalities.  While these personalities might be annoying at a large game studio, it can be the death of a small indie team.  Each developer needs to put the game and the team ahead of their own agenda.  When possible a team should be formed with people that have worked together previously.

Conflict

Every team has conflict.  Conflict can be minimized having a unified goal.  The best option is to have someone in a position of power to settle disputes.  This person must be trusted by everyone not to push their own agenda.  Some solutions to solving conflict in your team:

• Talk it through – Open, continuous conversation is the best way to solve problems
• Compromise – The larger the team, the harder it is to keep everyone happy.  Compromise is a necessity.  Ultimately the team is in it together and need to compromise to solve disputes.
• Give everyone a voice – Voting is a great way to solve disputes.  The team must agree that a voting mechanism will be used and respected up front.

Outsourcing vs In-house

Many Indie companies have little money, necessitating all work is done in-house.  Outsourcing gives a reliable quality for a fixed price.  Some areas worth outsourcing include:

• Game Engines – shared by the whole team, they can save a lot of development time
• Sound Libraries – can be used as building blocks to create sounds for the game
• Art – Art is often the critical path in development.  Outsourcing may save time and money

Conclusion

This should set you up on the path to creating a solid team for your next indie game project.  What are your experiences with building a team?  Where have you succeeded and failed? Do you have any recommendations for others who are building their team?

1. Inexperienced Free Timers

The people in this group include high school and university students, or more generally, people still living at home. They have plenty of spare time, don’t have a job or family that rely on them and don’t have to try and find the energy to work on their games after a 40 hour week at work.

The challenge for this group is to skill up before they have to start supporting themselves and therefore turn into group 2. How can they skill up? There are plenty of websites out there to learn including Gamedev.net, opengl.org and nehe.com. You should use all your available time to learn as much as you can. On buses or trains, instead of watching tv, or during breaks between lessons or lectures. I used to print out as many tutorials as I could off the internet and read them on my 30 minute train ride home. While textbooks are generally good for consistent, complete information on a subject, you can find nearly all the information scattered over the internet. If you have plenty of time but no money, take the time to search out this information.

Also, don’t neglect your current studies at school or university. Even the most unrelated subjects can give you a lot of important skills for starting an indie team later in life. From the psychology elective to the Haskell subject I took, I’ve learnt a lot that I use in my every day life, even if indirectly.

2. Experienced Workers

The people in this group usually have a full-time job to help support themselves (and possibly their family). I am currently in this position. Over the past years in the game industry and in my personal projects I’ve picked up the skills allowing me to create games. However working a 40-50 hour week means I don’t have the time or energy to work on my own game much. The best way to fix this is to set out definite times you will work on your indie game. Without setting out these times, it’s easy to get bored and stop working when the ‘fun’ parts are over. Forcing yourself to make a schedule and work a certain number of hours per week (even if small to start off) will help you immensely.

Overtime is a killer for this group. Each person has their own limit to how many hours they can work. To succeed in working full-time and making your own game, your limit needs to far exceed 40 hours. If you work overtime, it becomes almost impossible for your personal limit to be high enough. After the initial 40 hours, there seems to be an exponential drop in how much energy and concentration you can give to your project. I’ve found the best way of handling this is contracting 2 or 3 days per week. I found I was most productive as I didn’t have to worry about an income, while still having plenty of time to work on my game.

Working Together

The best solution I can see for these two groups is for them to work together. Their strengths and weaknesses are complimentary. 2’s (Experienced Workers) should become leads for projects made up of 1’s (Inexperienced Free Timers). 1’s should exchange their time, for knowledge/mentoring from 2’s. You need far less time manage a small team than you do to sit and code the entire project yourself; group 2’s should use this to their advantage.

Due to the anonymity of the internet this may be a problem for some people, so my recommendation is to start out slow. For 2’s, maybe see if there are current projects that are flailing that you can step into to help out as a manager. For 1’s, find people with no time to work on their projects and see if you can help them out. If the current projects are small enough, there’s little risk involved. After this you’ll be able to put more trust in each other and you’ll know whether you can work together well in a team.

Conclusion

I realise there are a few people creating indie games that don’t fit into either of these groups. These are the lucky people and you should take full advantage of this. One day you may end up as a Group 2 person and will look back on your current life with fond memories and I can guarantee you’ll not be able to forgive yourself if you waste it. So go out there, find your complimentary group and see what you can come up with.