I'd actually argue that some indie games compare favorably to similar commercial titles, but they usually aren't first person shooters or real-time strategy games. For example, right now I'm totally addicted to Dominions 2. It's just more fun than the strategy games released by big companies recently (say, Civilization 3) and isn't any worse in the graphics/tech department either. It will probably be quite profitable to the two guys who made it.

So one of the things to think about is picking the right genre. Some types of games are simply more suitable for small teams and individual developers than others. Unfortunately too many people are only interested in making shooters or multiplayer RPG's or other resource-intensive games. I suppose it's because everybody wants to make games that they'd like to play themselves.

Quote:

Original post by ApochPiQ I suspect that if there were a reliable and well-known channel through which small-time developers could release their creations and make money at it, there would be enough money to go around that people could live on selling games through that channel without needing a "real" job. This solves both issues, and also would provide the impetus for more newcomers to take up game development, which of course provides competition and encourages better development from everyone - win/win situation. Now all we need is someone to back that kind of venture and keep it afloat.

Doesn't GarageGames provide all that? You don't have to be using their tools to have a game published by them.

Quote:

Original post by TechnoGoth One of main stumbling blocks with hobbiest developers, is that they get into because of the coolness factor, they have a couple of ideas that they think are cool and want to make a game based on them. Because of this they also tend to loose interest in a project rather quickly after the coolness factor wears off.

I think that sums up the post by Kurt Miller, author of Strayfire. He says that the first 90% of creating the game is the most fun, the time that you add features and see the game evolve into something cool. The other 10% is actually 90% of the work as it involves tedious bug-fixing, testing and general tweaking to make things work.

To me, this always seems to be a problem I've had in the past - partially due to the fragmented nature of tutorials and such. If you take a look at my soon-to-be-renovated Manta-X website, you'll see that I spent a whole lot of time on what were quite frankly beautiful particle effects but what was the actual 'engine' of the game like to program on? Horrific. I simply had no clue about how to put a large project together. In fact I could argue that I did, but by trying to do things the way that the 'professionals' would I shot myself in the foot over and over.

Each day on Gamedev I see new starters talk about creating their 'engine' and sometimes it makes me feel geniunely sad. Sad because I know how devastating it is to find that the 'code entropy' (John Carmack) eventually wins. I think that instead of creating your engines (I'm effectively talking to myself in the third person here), you should be creating basic libraries that can be reused over and over. This is essentially the concept of the 'engine' but I think the sights get lost when we try and aim too high. A point of reference that may be useful is Chris Hargrove's Code on the Cob series. It's helping me kick myself back into shape by pointing out the flaws in my code design.

Whilst it is true that a lot of very very clever and talented people reside on these forums (Yann L has been mentioned), there will be a lot of people who come here with dreams. I'd hazard to guess that many of these people probably leave with their dreams in pieces because of the way their projects are designed. The step up from "I've created pong" to "I want to make Doom 4" doesn't seem that great when you have a few excellent tech demos under your belt. But 3 failed Manta-X games later and I can say that the step is very big and very real. What is needed to bridge this gap? Maybe more tutorials in game creation. Taking a game forward with small steps, understanding it completely.

I do feel liberated though. A phoenix from the ashes.

Quote:

Original post by evolutional I think that instead of creating your engines (I'm effectively talking to myself in the third person here), you should be creating basic libraries that can be reused over and over. This is essentially the concept of the 'engine' but I think the sights get lost when we try and aim too high.

This is my (new) philosophy too. See CodeDread (my site).

Regards,
Jeff

What prompted you to change your philosophy? What was it previously?

Goals set too high for one person with the limited amount of spare time that I have.

high != expensive

Quote:

Original post by Diodor high != expensive

I think I'm missing your point? Would you care to elaborate a little please? :D

Quote:

Original post by evolutional I think I'm missing your point? Would you care to elaborate a little please? :D

It's a higher goal to make a one-week game that sweeps the internet over (play Icy Tower to see what I mean) than to make a below average three years worth of time MMORPG. The former is a higher goal because it requires brilliance and it is much more unlikely to achieve than the latter.

If you thought it was difficult being a hobbyist game programmer, please spare a thought for those poor people at Eidos, the makers of Tomb Raider, who have recently announce that they are just too small to be profitable in the game industry.

Here's a link to the article.

What a strange industry it is!