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)
If he has a good track record, he can probably sell his experience; he just needs to get out there and start networking in whatever field he's aiming for.
This advice is made on the assumption that he's in a major metropolitan area with the kinds of conferences and informal gatherings to allow a new start.
School gave me the time to think and dabble and develop a lot of my personal philosophies and perspective. The business world tends to do the opposite because of the endless drive for fast and cheap. Either way, you lose one aspect of your individuality and gain another.
The idea of improving "how things are done around here" - the process - is what ultimately excites me about business. Others, I think, focus on making the best products, on building a great community around the company brand, or on improving the world's condition. And I think it is these high-level endeavors that should be one's focus, no matter what the specific business is. If you don't know which of those interest you, get a job in the field you like, and the business problems you want to solve will reveal themselves quickly.
Will the cost of maintaining the hand-rolled code exceed the cost of working with XMPP tech (and subsequently benefiting from an existing community and proven reliable code)? Hiring someone for an existing standard, for example, means less legwork documenting and codifying your own system.
What rate of feature growth do you see, if any? Whatever solution you choose now, assumptions will start being made against it in future code, and they will slow down a switch later.
One way you could research this further is to do the bare minimum test case of both techniques in isolation from your other work. You won't have the "but I have to consider x" in the back of your head, doing it that way.
When I got my game gig it was through demonstrating work at a Meetup group(San Francisco Game Developers), so I know this is a good place to start. I'm planning to show for as many of these events as I can.
Thanks for your comments, everyone. I'll start following up on specific comments shortly, but some general thoughts:
My reasons for wanting to go for a new business have to do with the calcified nature of the development process; now that I've "seen the elephant" in this side of the business it's all much less interesting, and it won't get better just by changing my employer. It won't get better by going indie, even. I want to go beyond shipping products and find the next level - the franchise, the organization, whatever term might apply.
So in that sense I'm not worried about the product idea, just the process - the potential of changing and improving it. That's where I think the startup world has something to offer.
In large part the critiques seem to center around failings of minimal prefix syntax(failings which I would agree with). Minor errors that in bulkier languages are caught by the compiler, become logic errors in a Lisp; an easy way to become frustrated as a learner.
Some problems become easier when I'm sleepy because I can't think as clearly but I start to focus very well.
Other problems demand several passes of experimentation. For those it's easier to try a quick test during the day, think about it while doing other things, and then wake up with the (possible) solution the next day.
I happened to run into this in the bookstore today. I don't recall it making any waves online, but it's a fun read and uses a lot of real-world concepts. Definitely worth checking out.
If you hate having redundant types, I highly recommend using haXe. It has type inference by first-usage so in most cases you don't need to specify any type. If you want to get around the type system it has untyped{} code blocks, casts, and the "Dynamic" type, all of which throw type safety over to the runtime interpreter.
This is not a new article by any means, but it's a good overview of the kinds of approaches one might take in collision.
One of the directors at my workplace has the motto "Collision is gameplay" because of the high importance of getting these dynamics right -- whether you allow things to interpenetrate or not, how general the allowed shapes are, etc. The algorithms can get complex very quickly if you let them, and sometimes an accurate and realistic physical simulation turns out to be the wrong thing.
You have the "second move" in this chess game of monopolistic competition. Even highly successful, technically superior, first-to-market products have been beaten out by competitors.
AAA games as we know them will peak and then decline. The PC is inexorably moving towards a fully open-standard platform on which DRM-laden products cannot work. Consoles don't suffer the same problem, but by cutting themselves off from an open world and locking the hardware specs at a fixed low level, they force development costs considerably higher. The Wii points to a future console market that seeks disruptive hardware innovations over a market-share battle, but development costs mean that third parties will have few incentives to participate in such a market.
Also, games with a large engineering scope have an astonishingly poor track record. Games with a high content scope are much more likely to succeed.
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)