The 6 Indie Game Development Mistakes

[christo]

I came across this interesting article the other day. It's a couple of years old now but it is not out of date.

To be honest I think I'm in grave danger of making 5 out of 6 of these mistakes.

"I'm going to make an RPG with 3,000 enemy types, real-time combat, and a first-person shooter mode. And dancing, lots of dancing."

"I've got my design in my head, and now I just have to make it."

"It'll be finished when it's done."

"I don't understand this. I'll figure this part out as I go along."

"I have a binder full of 300 pages of design documentation meticulously pieced together over many, many years."

"I'll just do the music for the game myself. And the art. And the programming. I'll schedule it. I'll then promote it, I'll do bug fixes, I'll handle customer support..."

What does anyone else think? Are these always mistakes?

Read the full article on Kuro5hin: The 6 Indie Game Development Mistakes

[thejahooli]

Although this does make valid points, I feel that it is too focussed on commercial interest rather than creating a game that is what you want it to be, which is more important to me and a lot of indie game developers.

[XianForce]

Well, I think 4 of those 6 can be very easily applied to noncommercial development:

"I'm going to make an RPG with 3,000 enemy types, real-time combat, and a first-person shooter mode. And dancing, lots of dancing."

"I've got my design in my head, and now I just have to make it."

"I don't understand this. I'll figure this part out as I go along."

"I have a binder full of 300 pages of design documentation meticulously pieced together over many, many years."

The first is the same scenario seen all the time, the second is one I personally have a big problem with. I think through designs in my head, but never actually get them out on paper, or in code. The third I guess isn't as applicable, but I still think it's good to aim before you fire, and not just jump in head first, but sometimes that's what you have to do.

[Falco Girgis]

Things like this never mean anything without context.

1) What kind of team are you running?
2) What are you goals?
3) How large is your project?
4) How much are you getting paid for this?
5) What is your real motivation?

By boldly giving "6 grand mistakes," you are completely neglecting the context of indie game development teams, and assuming that either 1) they run exactly as your has or 2) SHOULD run the way you believe. It seems borderline arrogant to me. One size does not fit all.

If there really was a "big mistake in indie game development," I would definitely call this one of them.

[christo]

GyroVorbis,

I think the implicit assumption common between commercial and hobby indie game development (if I can read between your lines) is to ship a completed game that you are happy with.

Commercial development is really no different from hobby development with the key exception that there is an additional way to fail (commercially).

If you are clear about your objectives, I think you can see the points that the article is trying to make and translate them to your project.

For example, the point about the 300 page doc is that you can do too much up-front planning and not benefit enough from the feedback loop of actually writing code and seeing what really works. It's a lesson about too much theory and not enough practice.

I think most of the other points can be applied to any development project with clear ideas of what constitutes success and failure.

Of course this doesn't mean the advice is correct, but I think the points being made are applicable to all sorts of projects. The other thing is that the article is trying to point out common mistakes. This means they are things that people have done which have commonly turned out to have been a mistake. Perhaps there are projects for which those same things are not mistakes.

Maybe you can elaborate on where you think those things are not mistakes since you clearly have some experience working on what I assume you consider an indie game project?

[Falco Girgis]

Commercial development is really no different from hobby development with the key exception that there is an additional way to fail (commercially).

I completely disagree. The two couldn't be more different. One is doing something that you literally get up every day and get paid to do, and one is desperately trying to find time to fit a hobby into your schedule while you still have to pay the bills.

1) You can't exactly wake up in the morning every day and work constantly on an indie project. Something has to pay the bills.

2) You can't exactly fire team-mates for not working, bitch at team members, or expect them to be continually working/producing. They aren't getting paid for their work. You have to accept completely that they just might not have time, which completely throws the "rigid scheduling and goals" bullshit right out the window. You operate on pure motivation and free time. Once again, if a team member isn't motivated or doesn't have enough free time, tough shit. There is absolutely nothing you can do about it. It's the difference between being OBLIGATED to work and working because you want to work.

3) You have no additional resources. You are forced to make do with what you have. You have no income to hire new talent or outsource work that cannot be done by the core team.

So the only difference is that with one of them you can fail commercially? And what about the dozens of benefits that being paid for your work brings to the table?

I can't imagine how long ago ES would have been done if I didn't have to juggle full-time engineering school, trying to pay the bills, and trying my damndest to cram ES into every free second of the day. Half the time I can only work in class, which causes me to miss material.

Although this does make valid points, I feel that it is too focussed on commercial interest rather than creating a game that is what you want it to be, which is more important to me and a lot of indie game developers.

Thank you. That is the exact point that this kind of generalization completely neglects.

The implicit goal with this kind of shit is that you wish to get a game to the market as quickly as possible. We could have finished ES years ago with the original shitty engine with the original shitty art. We would not have learned half as much as we did, and we would not have ultimately gained the knowledge to make the engine what it is today.

This kind of shit COMPLETELY negates the passion or voluntary commitment factor of indie game development. People work on a game without getting paid because they WANT to. They all have different reasons for wanting that. Personally, I want to grow as a programmer, I want to learn, I want to build things. Yes, I want to make a game, but if I'm not 100% completely satisfied, I'm not going to be motivated to see it through. The same goes for artists who want to create a work of artistic brilliance, the musician who wants to create a musical work of art, etc.

And you know what? I can afford to take all the time that I want to, and so can most INDIE developers. Unless you are banking your income and financial well-being on the game, what is the point of releasing a "decent" game that you are partially satisfied with? I'm about to graduate with a CPE degree. I will be making pretty decent money. More than a game development job. The financial revenue that ES could produce is almost irrelevant to me. What is relevant is that people will play and enjoy my work--and that means that I should take my time and do it correctly.

"It'll be finished when it's done."

Riiiight. Have you ever tried actually putting a deadline on things in an indie team? Have you ever tried telling the guy who is balls deep in biology homework or is taking care of his kid that he has to have his shit in the repository by Friday? 1) not only is that almost completely unrealistic, but 2) what if they aren't ready? What if they aren't 100% satisfied with their work? Being forced to move on with sub-par work is one of the biggest motivation killers that I have ever experienced. "It'll be finished when it kicks ass" is a better motto.

"I'll just do the music for the game myself. And the art. And the programming. I'll schedule it. I'll then promote it, I'll do bug fixes, I'll handle customer support..."

Excuse me? And where is the money, the manpower, the connections, and the resources coming from to outsource all of this work? Once again, treating indie game development as though its a business investment, not a group of people voluntarily working their asses off when they can.

I can't stand things like this. As I said: context. There are different teams with different goals with different people with different motives. It is arrogant to believe that your method is so supreme to fit all sizes.

We are commonly criticized in the ES dev team for taking our sweet time on the project. The truth is that with this rushed, sloppy, schedule-based mindset, I would have lost motivation to work long ago. We've been here for so long, because we are always satisfied with our work before we take a step forward. The only thing that will make a man pour that last cup of coffee, stay up that extra hour, or go that extra mile is pure passion for his work. Not throwing "acceptable" shit out as quickly as he can.

[bnpph]

If hobby programmers followed that list, then everyone would be using linux and free software.

[eatcomics]

Thank you for that Gyro. I was actually thinking about putting some due dates on my project, but I was worried that I would fall into my old habit of knowing that I should be working on something and doing something completely different because its a burden. Tonight I'm done with my homework, chores are done, friends are taken care of and I'm going to enjoy myself with some coffee, music, and code!

[christo]

GyroVorbis,

Thanks for the detailed reply. Also, just clarifying, the original quotes are not my opinions, I was quoting from the article, so I'm not saying that these are mistakes, the original author of the article is.

My own remarks about the differences between commercial development of games and hobby development (not that this is the same as Indie game development) was more of an assumption. I'm no expert on this.

I guess you've taken what I said quite literally. That's probably my mistake. I was unclear. Of course there are differences when you're getting paid.

But I don't think it's true that you can't "fire" your team mates when you are working on a hobby/spare time project. In fact if I recall correctly, you've done that. Just because there's no money changing hands doesn't mean there's no agreement of exchange. Perhaps your agreement is that it's fair to do nothing for X months - that's fine that's your agreement. But there are things that could break that agreement.

I think there are lots of similarities - limited time and resources are a fact of every project, commercial and not.

My assumption was that there is a goal to ship a completed game. I think you're disagreeing with that, and that's fine.

Also, I'm picking up a bit of a defensive tone from you about ES. I can see you're frustrated with the progress even though you don't believe you could have done more. I didn't mean to be critical of ES. I was thinking generally of Indie game development because I'm interested in it for myself.

[TheBuzzSaw]

As much as I would like to profit from my endeavors, passion is where it's at. It's so satisfying to just code and learn things.

The other night, I did nothing but poke around with the latest version of libpng. Arguably, my game projects made zero progress, but in the grand scheme of things, they all made indirect progress because of the knowledge I gained from experimenting.

I still have goals to actually FINISH these projects, but I have to side with Gyro on this one. The very purpose of the projects strongly drives how the logistics are handled.