4 ms·

I think you are missing the fundamental purpose behind game engines. Game and graphics programming is really hard, and at times unapproachable to a lot of peopl

I think you are missing the fundamental purpose behind game engines. Game and graphics programming is really hard, and at times unapproachable to a lot of people. Moreover, in the real world, even experts prefer to use game engines just due to the fact that it is almost guaranteed that a raw renderer you write yourself is not going to be as good and optimized as a game egnine's renderer. Using game engines may not suffice to your use case, but for a lot of people that's the best way to develop games. This argument is similar to using a systems level language vs a higher level language. I myself prefer game frameworks over either raw graphics APIs and game engines, since it provides me with my preferred level of control while meeting my particular needs. I can see where you come from, if your goal is to learn and highlight that in your resume, writing and experimenting against the graphics APIs are likely the best bet. But for a lot of people, their main goal differs from yours, which is to... make a game.

jokoon 7y ago
If one doesn't understand how a game works, a framework is not going to help. This person will probably shoot himself in the foot. Here is a good video about benchmarking unity https://www.youtube.com/watch?v=tInaI3pU19Y https://www.youtube.com/watch?v=tInaI3pU19Y
- mntmoss 7y ago
  Most of the effort that goes into a large game project is not in the runtime code, but in content creation: you probably only need one renderer or one physics system, but lots of levels, lots of characters with unique behaviors. So what does every one of the top general-purpose game engines provide? An IDE geared around content creation. It is no surprise that you can find a benchmark where a general-purpose engine is slow. If you do nothing you go fast, but if you are supporting general-purpose use cases you add a lot of feature overhead, so you become slow. Why do pros use it, then? Because - if the engine is sufficiently extensible - they can use the built-in stuff as a placeholder and replace that subsystem with a custom one later. Project ships, everyone's happy. With microbenchmarks based around scaling simple elements like "thousands of bullets" like the one in the video this point on general-purpose elements is especially important. As soon as you want to add any additional behaviors to those bullets your performance is going to plummet. And from a game design perspective, scale becomes boring very quickly. A player cannot really appreciate seeing more than a few hundred things on-screen at any moment. So the way scenes are actually benchmarked in industry is by building out more of the behavior, adding placeholder assets at the estimated level of detail, seeing what frametimes result, and developing a scene budget around that. It all feeds back into the content creation pipeline again, because an optimized scene will have more care given to each of its assets.
- deleted 7y ago
  [deleted]

jokoon 7y ago

If one doesn't understand how a game works, a framework is not going to help. This person will probably shoot himself in the foot. Here is a good video about benchmarking unity https://www.youtube.com/watch?v=tInaI3pU19Y https://www.youtube.com/watch?v=tInaI3pU19Y

mntmoss 7y ago
Most of the effort that goes into a large game project is not in the runtime code, but in content creation: you probably only need one renderer or one physics system, but lots of levels, lots of characters with unique behaviors. So what does every one of the top general-purpose game engines provide? An IDE geared around content creation. It is no surprise that you can find a benchmark where a general-purpose engine is slow. If you do nothing you go fast, but if you are supporting general-purpose use cases you add a lot of feature overhead, so you become slow. Why do pros use it, then? Because - if the engine is sufficiently extensible - they can use the built-in stuff as a placeholder and replace that subsystem with a custom one later. Project ships, everyone's happy. With microbenchmarks based around scaling simple elements like "thousands of bullets" like the one in the video this point on general-purpose elements is especially important. As soon as you want to add any additional behaviors to those bullets your performance is going to plummet. And from a game design perspective, scale becomes boring very quickly. A player cannot really appreciate seeing more than a few hundred things on-screen at any moment. So the way scenes are actually benchmarked in industry is by building out more of the behavior, adding placeholder assets at the estimated level of detail, seeing what frametimes result, and developing a scene budget around that. It all feeds back into the content creation pipeline again, because an optimized scene will have more care given to each of its assets.
deleted 7y ago
[deleted]