As anyone in the industry knows, either you make a game engine or a game.

There are plenty of successful studios that have their own in-house engines. Naughty Dog, From Software, ex Kojima Productions...

Besides, for simple games, using those engines are a huge overhead and an unnecessary cost.

I understand what you're saying, but I don't like how you make it sound a simple, already-made-for-you decision, when reality is much more nuanced. Each case is a case, and no one should turn down their critical sense when making these decisions, there are no rules.

> Besides, for simple games, using those engines are a huge overhead and an unnecessary cost.

I don't think the pricing of $0-$75/month is a huge cost. They made some big changes to their fee structure this year.

Engines bring their overhead, but they also bring expertise small studios most likely lack. It's easy to cripple your performance with a single error. This can also happen to you while using an engine but even more so when writing your own engine.

Or put differently: Simple games probably have so sleek game logic code that the engine overhead can safely be ignored.

I don't say custom engines are pointless, but for the hundreds of games that are released on the App Store daily, a ready to use engine is "enough".

Yes, I understand that, the expertise point is very pertinent indeed. I am not against using available engines at all.

My main point is still that this should be a decision that you make when starting a project, not one that has presumably been made for you. Team members expertise, project cost, for how long you'll be using the tech you're developing, etc. should all be taken into account.

A practical example: Imagine trying to optimize loading times when the whole resource system is a massive generic thing that has been made for you. Now imagine having to support a new platform. You could be in a bind simply because you're using third-party tech (especially if closed-source).

Simple games will be simple enough to be able to move without too much cost/time.

The big companies with their in-house engines will be able to pay someone to do the job.

> There are plenty of successful studios that have their own in-house engines.

None of which develop for Mac.

"Besides, for simple games, using those engines are a huge overhead and an unnecessary cost."

For simple games, you're probably not going to be reaching down to the Metal layer anyway. You're probably gonna stay up at the CoreGraphics layer, use SpriteKit/SceneKit, or something like Cocos or something similar.

Having gotten lots of Gamasutra postmortens and GDC presentations, is why I just oversimplified the statement.

Well not necessarily. I work in a large games studio for one of the largest publishers in the world, and pretty much all of our games are made using our own engines. No Unity or UT in sight. But working on those engines is a huge part of every project, it wouldn't be possible if we didn't have hundreds of programmers working on it.

> But working in those engines is a huge part of every project, it wouldn't be possible if we didn't have hundreds of programmers working on it.

Yes, but was my point. I just oversimplified it.

Without a big team, resources are soaked up developing the engine, as so many Gamasutra Postmortens testify.

You don't have to, but they reduce development cost by reducing the impact of per-device differences such as those between various versions of OpenGL ES, various versions of OpenGL, various manufacturer-specific implementation quirks of OpenGL, D3D, the existing desktop below-OpenGL APIs and now, presumably, metal.

I was being slightly sarcastic: the point is that there are people who enjoy doing both (and indie games are for the most part a work of love/enjoyment). If Mac drops OpenGL (or never adds Vulkan) there is a chance that someone simply won't bother making their engine+game work on Mac - meaning lost potential on the platform. Who's to say the next Minecraft (which is an engine+game) won't support Mac because it doesn't support Metal and instead went the Vulkan route?

Apple can port Metal, it makes sense: there are tons of mobile games that would pose immediate value for the platform; adding Vulkan into the mix (or even fixing their completely broken OpenGL implementation) would have been a much stronger message.