5 ms·

If anyone told me 10 years ago that Unreal and CryEngine would be, for all practical purposes, free... It's wonderful time to be a gamedev (tech-wise), I presum

If anyone told me 10 years ago that Unreal and CryEngine would be, for all practical purposes, free... It's wonderful time to be a gamedev (tech-wise), I presume. Writing your own graphics engine now seems to be more in line if you really enjoy writing your engine more than the game itself - or if you really want to do something you can't do easily with engines available.

hacker_9 11y ago
Graphics engines aren't particularly hard to write though once you grep the shader pipeline, as many/all of the latest effects are available for free online (FXAA, HDR, Deferred Lighting etc), though an engine will nicely package them together for you in a ready to use fashion. The biggest problem with this pre-packaged software is when something ultimately goes wrong, which it always does. Then you find yourself digging round in internals (assuming you have access, looking at you Unity) to find out what when wrong and why banding is appearing only when you use stencil shadows and apply SSAO factor X.. basically, it's still complicated, and you still have to know your stuff. Another problem with these engines is they force you into a particular way of working. Unreal blueprints for example are a nightmare once you add a decent amount of functionality as per the law that visual programming does not scale. Finally you underestimate how much code is the actual game logic, which is also the hardest part to write. In this case the engines don't help at all, Unity even just throws you into Visual Studio and lets that deal with you. Additionally I've yet to see a good solution for figuring out why my AI are running through walls on their way to a target, without writing a ton of custom visualization stuff myself. Many algorithms take place over time (units moving, animating, etc), so you can't just step though code in a debugger as that's like looking at a landscape through a keyhole.
- inDigiNeous 11y ago
  Writing a 3D graphics engine is one of the most complex things you can do in software. It requires so much understanding of data structures, efficiency, close to the metal programming, 3D math, vectors, translations, what have you. Of course it gets "easier" once you've done it a couple of time and understand the basics, but really doing it for the first time is a hard edge to climb. Been writing my first 3D C++/OpenGL engine for the last 2 years, one of the most taunting tasks I've taken in my career. And just to cover a very specific use case of graphics rendering, not to do cover an overly generalized case like Unreal Engine is doing. Unreal engine is also over at least 20 years old, so I think you're overly simplifying the task required. Graphics engine is so much more than just figuring out the graphics pipeline, ultimately it's about flexible data management in a way that lets you achieve what you want, with performance.
  - hacker_9 11y ago
    3d Math sucks sure, but you can't just use an engine and expect to not have to deal with it. It's just the reality of the situation. Also I'm not denying the volume of work gone into Unreal, but I am saying that roll-your-own approach is still possible, because many of Unreal's features are available online. It's just it's up to you to integrate it all. Of course writing a C++/OGL renderer from scratch is not nice, I've done the same myself and I promised myself never again :-) These days C# + Monogame solves all my Language, API and Platform distribution problems and allows for fast iteration during development.
- IshKebab 11y ago
  > Graphics engines aren't particularly hard to write though once you grep the shader pipeline That's like saying "car's aren't too hard to build once you understand the four stroke cycle". Did you read the changelog? The manpower involved is immense. (Of course you can write a much much simpler engine yourself, but we aren't talking about those.)
  - hacker_9 11y ago
    Eh, you cut off the second part of what I said.. What I mean is, if you go down the route of writing your own graphics engine, then everything Unreal has is available in bits and pieces for free online, but you have to have the know how to stitch them together - which isn't particularly hard, and something you should know if you are going into gamedev anyway as it's the basics. Note I'm only talking about the graphics aka shader side here, not the whole engine.
- jmatthews 11y ago
  Writing your own engine, when you intend to make a game is a black hole where many many projects go to die. Implementing a cross platform modern game engine is perhaps a single step below writing an operating system from scratch. Source- I've written 3 feature rich, but not feature complete, game engines over the last 25 years.
  - hacker_9 11y ago
    Writing an 'engine' is just good code reuse - as I build my game I have 2 separate groups of projects: one is for the engine where I put generic game tools such as model loading, input handling etc - and the other group of projects is my game logic which contain specific jobs and tasks my AI perform in-game for example. When new engine features come out, FXAA for example, it's mainly just a case of finding it online [1] and implementing it as needed. I've done this with many parts of my engine (model loading [2], animation [3] and physics [4] come to mind) where I don't need to re-invent the wheel, but I have full source for when I need to modify it (always the case), and it comes unrestricted by licences which is another plus. Cross platform? Mono runtime + Monogame already has me covered, and I can use a modern language to write my games for faster iterative development. [1] https://github.com/SeriousMaxx/FXAAMonoGame https://github.com/SeriousMaxx/FXAAMonoGame [2] https://github.com/assimp/assimp https://github.com/assimp/assimp [3] https://xnanimation.codeplex.com https://xnanimation.codeplex.com [4] http://community.monogame.net/t/which-physics-engine-is-working-with-monogame/472/11 http://community.monogame.net/t/which-physics-engine-is-work...
    - Keyframe 11y ago
      I both agree and disagree with you. It's certainly possible to write an engine by jury-rigging stuff you find online/in books around, but that will not lead you far. Modern graphics approach is not even possible anymore with elementary knowledge of trigonometry. You can't do anything complex if you don't have, at least, a basic grasp of calculus. It is just not possible anymore. And, on top of that, you have to be able to parse modern research in graphics in order to understand what is going on and why and then implement that. Most of modern rendering approaches lie on the shoulders of this great paper: https://graphics.stanford.edu/papers/veach_thesis/thesis.pdf https://graphics.stanford.edu/papers/veach_thesis/thesis.pdf but they have since built upon that. You have to keep at it, new stuff is always brought to light, and you have to know both how and why. It's a task that needs special attention, a lot of it, and you still have a game to write - which is a large task in itself. So, my takeaway is that it's great to outsource that large of a task to Unreal/Cryengine/Unity/whatever and concentrate on game design and mechanics itself. Unless, you enjoy writing graphics engines/renderers (I wrote a couple over the years, and used in production. I wouldn't do that again.). Other thing is if you want to do something special, not possible with what's available - streamlining performance for certain cases, some special technique, etc. One other benefit, apart from outsourcing, is that there's now a large pool of people using the same system. So, you're not working in isolation anymore and you can ask for help when you get stuck - and stuck you will get.
- iamcreasy 11y ago
  > Unreal blueprints for example are a nightmare once you add a decent amount of functionality as per the law that visual programming does not scale. Could you please elaborate on this one? Do you have first hand experience?
  - hacker_9 11y ago
    The beauty of programming with visual nodes: http://scriptsofanotherdimension.tumblr.com/ http://scriptsofanotherdimension.tumblr.com/
    - iamcreasy 11y ago
      Well, anything can be made look sufficiently complex. But there can be(should be) ways to abstract out or compartmentalize a larger problems to make it easier to focus on small sections in visual programming. It's true that there has been more questions then there are answers, but I was wondering what attempts have been taken thus far to solve it. More specifically, I was curious to hear if OP had any story to share dealing with this kind of problem.
mattnewport 11y ago
Writing your own engine is getting to be a harder to justify decision given the affordable availability of these high quality engine options but there are still situations it can make sense. All these engines make some efficiency sacrifices for generality and feature set. You can get better performance if you have a specific problem to solve and you design your rendering around it. For many games that's not going to make sense but for certain VR applications it still might. For my VR projects I've gone down both paths and there are pros and cons to each. For many projects though the biggest advantage of these engines are the editors - writing your own rendering engine for a specific use case is a lot less work than building an editor that can compare to these tools.

hacker_9 11y ago

Graphics engines aren't particularly hard to write though once you grep the shader pipeline, as many/all of the latest effects are available for free online (FXAA, HDR, Deferred Lighting etc), though an engine will nicely package them together for you in a ready to use fashion. The biggest problem with this pre-packaged software is when something ultimately goes wrong, which it always does. Then you find yourself digging round in internals (assuming you have access, looking at you Unity) to find out what when wrong and why banding is appearing only when you use stencil shadows and apply SSAO factor X.. basically, it's still complicated, and you still have to know your stuff. Another problem with these engines is they force you into a particular way of working. Unreal blueprints for example are a nightmare once you add a decent amount of functionality as per the law that visual programming does not scale. Finally you underestimate how much code is the actual game logic, which is also the hardest part to write. In this case the engines don't help at all, Unity even just throws you into Visual Studio and lets that deal with you. Additionally I've yet to see a good solution for figuring out why my AI are running through walls on their way to a target, without writing a ton of custom visualization stuff myself. Many algorithms take place over time (units moving, animating, etc), so you can't just step though code in a debugger as that's like looking at a landscape through a keyhole.

inDigiNeous 11y ago
Writing a 3D graphics engine is one of the most complex things you can do in software. It requires so much understanding of data structures, efficiency, close to the metal programming, 3D math, vectors, translations, what have you. Of course it gets "easier" once you've done it a couple of time and understand the basics, but really doing it for the first time is a hard edge to climb. Been writing my first 3D C++/OpenGL engine for the last 2 years, one of the most taunting tasks I've taken in my career. And just to cover a very specific use case of graphics rendering, not to do cover an overly generalized case like Unreal Engine is doing. Unreal engine is also over at least 20 years old, so I think you're overly simplifying the task required. Graphics engine is so much more than just figuring out the graphics pipeline, ultimately it's about flexible data management in a way that lets you achieve what you want, with performance.
- hacker_9 11y ago
  3d Math sucks sure, but you can't just use an engine and expect to not have to deal with it. It's just the reality of the situation. Also I'm not denying the volume of work gone into Unreal, but I am saying that roll-your-own approach is still possible, because many of Unreal's features are available online. It's just it's up to you to integrate it all. Of course writing a C++/OGL renderer from scratch is not nice, I've done the same myself and I promised myself never again :-) These days C# + Monogame solves all my Language, API and Platform distribution problems and allows for fast iteration during development.
IshKebab 11y ago
> Graphics engines aren't particularly hard to write though once you grep the shader pipeline That's like saying "car's aren't too hard to build once you understand the four stroke cycle". Did you read the changelog? The manpower involved is immense. (Of course you can write a much much simpler engine yourself, but we aren't talking about those.)
- hacker_9 11y ago
  Eh, you cut off the second part of what I said.. What I mean is, if you go down the route of writing your own graphics engine, then everything Unreal has is available in bits and pieces for free online, but you have to have the know how to stitch them together - which isn't particularly hard, and something you should know if you are going into gamedev anyway as it's the basics. Note I'm only talking about the graphics aka shader side here, not the whole engine.
jmatthews 11y ago
Writing your own engine, when you intend to make a game is a black hole where many many projects go to die. Implementing a cross platform modern game engine is perhaps a single step below writing an operating system from scratch. Source- I've written 3 feature rich, but not feature complete, game engines over the last 25 years.
- hacker_9 11y ago
  Writing an 'engine' is just good code reuse - as I build my game I have 2 separate groups of projects: one is for the engine where I put generic game tools such as model loading, input handling etc - and the other group of projects is my game logic which contain specific jobs and tasks my AI perform in-game for example. When new engine features come out, FXAA for example, it's mainly just a case of finding it online [1] and implementing it as needed. I've done this with many parts of my engine (model loading [2], animation [3] and physics [4] come to mind) where I don't need to re-invent the wheel, but I have full source for when I need to modify it (always the case), and it comes unrestricted by licences which is another plus. Cross platform? Mono runtime + Monogame already has me covered, and I can use a modern language to write my games for faster iterative development. [1] https://github.com/SeriousMaxx/FXAAMonoGame https://github.com/SeriousMaxx/FXAAMonoGame [2] https://github.com/assimp/assimp https://github.com/assimp/assimp [3] https://xnanimation.codeplex.com https://xnanimation.codeplex.com [4] http://community.monogame.net/t/which-physics-engine-is-working-with-monogame/472/11 http://community.monogame.net/t/which-physics-engine-is-work...
  - Keyframe 11y ago
    I both agree and disagree with you. It's certainly possible to write an engine by jury-rigging stuff you find online/in books around, but that will not lead you far. Modern graphics approach is not even possible anymore with elementary knowledge of trigonometry. You can't do anything complex if you don't have, at least, a basic grasp of calculus. It is just not possible anymore. And, on top of that, you have to be able to parse modern research in graphics in order to understand what is going on and why and then implement that. Most of modern rendering approaches lie on the shoulders of this great paper: https://graphics.stanford.edu/papers/veach_thesis/thesis.pdf https://graphics.stanford.edu/papers/veach_thesis/thesis.pdf but they have since built upon that. You have to keep at it, new stuff is always brought to light, and you have to know both how and why. It's a task that needs special attention, a lot of it, and you still have a game to write - which is a large task in itself. So, my takeaway is that it's great to outsource that large of a task to Unreal/Cryengine/Unity/whatever and concentrate on game design and mechanics itself. Unless, you enjoy writing graphics engines/renderers (I wrote a couple over the years, and used in production. I wouldn't do that again.). Other thing is if you want to do something special, not possible with what's available - streamlining performance for certain cases, some special technique, etc. One other benefit, apart from outsourcing, is that there's now a large pool of people using the same system. So, you're not working in isolation anymore and you can ask for help when you get stuck - and stuck you will get.
iamcreasy 11y ago
> Unreal blueprints for example are a nightmare once you add a decent amount of functionality as per the law that visual programming does not scale. Could you please elaborate on this one? Do you have first hand experience?
- hacker_9 11y ago
  The beauty of programming with visual nodes: http://scriptsofanotherdimension.tumblr.com/ http://scriptsofanotherdimension.tumblr.com/
  - iamcreasy 11y ago
    Well, anything can be made look sufficiently complex. But there can be(should be) ways to abstract out or compartmentalize a larger problems to make it easier to focus on small sections in visual programming. It's true that there has been more questions then there are answers, but I was wondering what attempts have been taken thus far to solve it. More specifically, I was curious to hear if OP had any story to share dealing with this kind of problem.

mattnewport 11y ago

Writing your own engine is getting to be a harder to justify decision given the affordable availability of these high quality engine options but there are still situations it can make sense. All these engines make some efficiency sacrifices for generality and feature set. You can get better performance if you have a specific problem to solve and you design your rendering around it. For many games that's not going to make sense but for certain VR applications it still might. For my VR projects I've gone down both paths and there are pros and cons to each. For many projects though the biggest advantage of these engines are the editors - writing your own rendering engine for a specific use case is a lot less work than building an editor that can compare to these tools.