|
I work in console game development, I've made Flash games, and I spent a week trying with a startup. (Subsequently I returned to console games.) Long post ahead. When speaking of console gaming there is a considerably larger amount of formality and regulation than most web startups because of the influence manufacturers and publishers have. You work on their hardware, you are funded by hitting their milestone definitions, you are beholden to their marketing plans, and you cannot get distribution without their approvals. Studios that do big AAA titles are perpetually one project away from bankruptcy because big games ramp up to a huge staff for full production(which ideally occurs once the major unknowns of the gameplay, prototypes, engine, tools, pipeline etc. have been worked out) and unless they have a new project waiting once the first one ships, they're burning through massive overhead and face firing half or more of their employees or shutting down. The place I work for specifically avoids taking on big projects because of crushing past experiences. Independents face a problem more similar to the early-stage startup of getting traction in the marketplace. They typically succeed via radical product differentiation, since the other angle(high quality) is covered by console developers already. This market has diverged into many subsets - to name the major ones: downloadable games, browser-based multiplayer, Flash games... each one has different production requirements and monetization strategies. While you can find plenty of success stories....there are also plenty of starving indies out there. As well, indies (as a rule) are less likely to make their games available as an ongoing, continuously improved service in the way a web company does. But the ones that go the service route, in my eyes, are more likely to succeed long-term than those following a "shipped product" model. To succeed as an indie you really need a rabid fanbase that follows your brand; the alternative is to jump onto the bandwagon of the week(casual games, girl games, etc.) and peddle your clone against 10000 other clones, which ultimately leads to a quality war and the console market situation. Finally.....the biggest difference between websites and games is collision detection. To put it the way my boss does, "collision is gameplay." Not all games need collision, but those which involve simulated physical interactions do, and that requirement comes up astoundingly often, so it's a cornerstone game programming task. Plus, the particular implementation of collision radically influences the game so it's not a matter of dropping in library code. That's not to say that the programming's the only problem - art is a problem because it always takes a long time, and game design is an unbounded-size problem. Solid game design happens after prototyping many different gameplay mechanics in isolation, keeping the ones that work, and then iterating over their integration until a satisfactory combination is achieved. This means: do a lot of work. Throw most of the work out. The leftover crumbs ship. An ambitious project I am taking on now in my spare time is the angle of simplifying the game development process itself, with a website that promotes sharing and reuse of game-related content under Creative Commons. Long-term I want to add editing tools to create specific game types, but that is an easy task to underestimate and the web entrepreneurs that I've seen take it on so far have either grossly cut back on the features to get something done in a few weeks(making the service mostly useless) or allowed the scope to grow too large, finally failing after a depressingly massive effort. (see Gameclay) |