5 ms·

You probably won't use it yourself. You'll use Unity or UT4 which uses Metal under the hood.

by emsy 11y ago

zamalek 11y ago
> You'll use Unity or UT4 which uses Metal under the hood. Why do I have to use those engines?
- pjmlp 11y ago
  As anyone in the industry knows, either you make a game engine or a game.
  - gambiting 11y ago
    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.
    - pjmlp 11y ago
      > 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.
  - phn 11y ago
    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.
    - pjmlp 11y ago
      Having gotten lots of Gamasutra postmortens and GDC presentations, is why I just oversimplified the statement.
    - emsy 11y ago
      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".
      - phn 11y ago
        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).
    - chrisBob 11y ago
      > 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.
    - solidpy 11y ago
      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.
    - 11y ago
- wzdd 11y ago
  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.
  - zamalek 11y ago
    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.
izacus 11y ago
Getting people to finally start porting games to OS X was hard enough... and now Apple just threw a wrench into all that by forcing them to code against another API.

You probably won't use it yourself. You'll use Unity or UT4 which uses Metal under the hood.

by emsy 11y ago

You probably won't use it yourself. You'll use Unity or UT4 which uses Metal under the hood.

zamalek 11y ago

> You'll use Unity or UT4 which uses Metal under the hood. Why do I have to use those engines?

pjmlp 11y ago
As anyone in the industry knows, either you make a game engine or a game.
- gambiting 11y ago
  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.
  - pjmlp 11y ago
    > 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.
- phn 11y ago
  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.
  - pjmlp 11y ago
    Having gotten lots of Gamasutra postmortens and GDC presentations, is why I just oversimplified the statement.
  - emsy 11y ago
    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".
    - phn 11y ago
      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).
  - chrisBob 11y ago
    > 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.
  - solidpy 11y ago
    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.
  - 11y ago
wzdd 11y ago
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.
- zamalek 11y ago
  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.

izacus 11y ago

Getting people to finally start porting games to OS X was hard enough... and now Apple just threw a wrench into all that by forcing them to code against another API.