Slashdot Mirror
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?
You end up paying either way, assuming your game actually has any sales, since the "free" and subscription plans all include a pretty healthy royalty for the engine developer. So, what's $10 a month?
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?")
You still pay a 5% royalty, which is a rather high price if you make high-end games. For indies and students it might be a good deal, but if your studio is into AAA, paying up-front is a better deal.
Should readers continue to read Slashdot with Dice junk making it to the front page?
No.
And by "real programming project", you mean a bloated project with dozens of programmers wasting their time arguing and figuring out how to work together?
By "real programming project", I mean were all the participants are being paid at market rates and the budget is large enough to produce a product of the quality (polish, size, art quality, gameplay, etc.) that is expected by current iOS and Android customers. My suspicion is that budget is in the hundreds of thousands, but I low-balled it at $100K.
I'm not denigrating hobbyist projects, after all, that's all I've ever been involved in. But my point (which I think you agree with) is with a real programming project, the up-front engine cost is trivial compared to the cost of employees.
That's not what Betteridge's Law is about.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
... over on Reddit. It keeps getting rehashed:
* Game Engine Design
* UE4 is now completely free
* wishlist game engine from scratch
* differences between Unity and Unreal
* UE4 vs Unity Faceoff
* More AAA games using unity?
* AAA are all free
There are still 2 reasons to "roll your own" game engine:
- To learn. i.e. See this uber diagram of all the components of a modern game engine!
and
- The popular engines still do a terrible job of dynamic terrain management, instancing, meshing, etc. Rolling your own such as Proc World, say using dual contouring, etc., means it is easier to fit into your rendering pipeline instead of trying to figure out someone else's architecture.
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.
You can help the discussion by telling us the name of the engine you created, and the list of commercially released games that used it. We need some perspective.
All those moments will be lost in time, like tears in rain.
Of course there's trivial costs in a business. If you're worrying about the costs of pens and whether you can get them 10 cents cheaper, you're wasting your time. If you're worried about the cost savings of turning the thermostat from 70 to 71, you're wasting your time. If you're worried about the cost of something that is less than 1% of your budget, you're wasting your time- even if you reduce it to 0 you'd have saved more by focusing elsewhere. A good businessman realizes whats worth being concerned about and what you just have to live with. Nothing is 100% efficient in life.
I still have more fans than freaks. WTF is wrong with you people?
Or at least they think they can, they think they can, they think they can.
When the premise is "this tool lets you reduce the number of programmers you need from 10 to 2", that's a good premise.
I want to know about any tool that makes programmers five times more effective!
Moreover, we've probably both seen cases where the philosophy was "this tools is expensive, so it *must* be good".
But I've seen a lot more "A thousand dollars is a lot of money" when I see it add 5-10% to a 100K programmer's productivity. Admittedly, it *is* hard to measure productivity, but my general philosophy is that if you *aren't* spending a few percent of an employees salary to enhance their productivity, you should be looking carefully to make sure you're getting the most out of them.
It's amazing how often you see employees losing 30 minutes a day in cumulative 1 minute delays (which frustrates the heck out of them) because spending 2K for a decent computer is out of the question. Far cheaper to lose 15% of the employees productivity and the increased turn-over due to the frustration is just icing on the cheapness cake!
So, with respect to the topic at hand, I strongly believe if you have decent employees, then they can probably tell you what engine will work best for them. And if it costs up front, then you pay it. And no, I don't expect 500% productivity increases. But it doesn't take much of a productivity increase to have the right product pay for itself within the year.