Should Developers Still Pay For Game Engines?
Nerval's Lobster writes: Game developers no longer have to pay for the software they need to make great video games, because the tools used by some of the biggest and most successful studios in the world are available to everyone, for free. Among the existing major engines, there is one holdout that does not offer a free version: Crytek continues to charge everyone for CryEngine, and is intent on continuing to do so. That's not to say Crytek is being unreasonable. The company introduced a $10-per-month subscription last year, making it accessible to indie developers who can't afford the higher-priced package that includes full source code. "With CryEngine, Crytek is going to the high-end," Crytek co-founder Faruk Yerli recently told Develop, a news site for developers. Unity3D is going for the low-end while Unreal is aiming for everything from low- to high-end, he added. But according to some developers queried by Dice, there is little reality to the idea that the big three engines are divided between low, mid-end, and high-end capabilities. If you're a developer, is it still worth paying for a game engine?
If one is talking about a hobbyist/near-hobbyist project (budget < $100K), then free (= low upfront cost) is good. But for a real programming project, the up-front cost of the engine is pretty small compared to the possible difference in programming time. If a fully-outfitted programmer is $10K/month after tax and tip, one is in danger of costing the project dollars (of programmer times) in order to save pennies.
In other words, evaluate the engines based on their qualities, not the up-front costs.
(On the other hand, lots of game programming nowadays does involve hobbyist-level budgets, in which case the real criteria is "if they're not being paid much, will the programmer's at least have fun using this tool?")
That's not what Betteridge's Law is about.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
One of my and my group's major sources of income is cleaning up after those "one developer" projects. The "rone developer" often has no idea how, or no willingness, to set up a testing plan before releases, to integrate robust security, to make software high availability, or to scale it behind a certain very modest size.
The result is that the first project or demo works well and is very lean and agile in the performance sense. But as the number of customers grow, or as people find and report bugs, scaling up and keeping it working well is much easier for the larger, more cautious team. Ideally, they code reviewed each other's work and pointed out where a fix here broke a feature elsewhere, or pointed out the edge cases that also need to be handled. As an example, what works on a laptop sitting next to the server running the multi-player game may not work so well behind three firewalls, NAT, and an overburdened local cable network setup. Lone developers often are not expected to spend time on those issues.