5 ms·

Sure there's a place for these engines. They abstract away graphics layers and bring convenience. But if you are a (semi-?) professional game dev, that's not a

by s9w 7y ago

Sure there's a place for these engines. They abstract away graphics layers and bring convenience. But if you are a (semi-?) professional game dev, that's not a major hurdle. I have a toy game in play around in my free time and started with SDL like so many. You can create windows and draw bitmaps really easily. But sooner rather than later you discover limits (bugs, performance limitations, less than ideal APIs) and see that just writing OpenGL code yourself is actually easier and more flexible. Many people go down that road. edit: Concerning your edit about "more than a renderer": Yeah that other stuff is annoying and many still use SDL, SFML or whatever for that. See Factorio and many many others who do the rendering themselves and offload the other crap. I do that myself too.

onion2k 7y ago
They abstract away graphics layers and bring convenience. And bring physics, input, asset loading, networking, systems, scripting, etc.
- s9w 7y ago
  That depends on the engine. The big guys do. But the pure 2D engines do not. And again the point I was trying to make was about graphics. Most if not all do not roll out their own code for input management, window creation, Networking and so on. But 2D graphics is relatively easy to DIY.
  - onion2k 7y ago
    But the pure 2D engines do not. I've never seen a 2D game engine that doesn't give you at least graphics, physics, and input.
    - s9w 7y ago
      Not sure we're talking about the same thing then. SDL, glfw, SFML, Monogame.. I don't think any of them contain physics code.
      - deleted 7y ago
        [deleted]
      - meheleventyone 7y ago
        Most of those are libraries/frameworks rather than engines though. A fuzzy distinction I know but most of these are something you might build an engine of top of to avoid some of the cross-platform drudge.
        versteegen 7y ago
        GLFW, SFML, and SDL absolutely aren't game engines, I don't think it's fuzzy at all. They're libraries for graphics, audio, and other useful APIs. Monogame I'm not familiar with, but since I can't tell by skimming the wikipedia article, I'd call it fuzzy.
        pjmlp 7y ago
        MonoGame as remake from XNA is much more higher level, as Microsoft made it for Indie games on the original XBox and WP7, and with some lessons taken from the earlier Managed Direct X attempt. So while not at engine level, it already provides higher abstractions than those libraries, and a content pipeline.
      - dkersten 7y ago
        Those libraries don’t provide any game structure though (well, SDL and glfw at least, I think the other two do give you a small amount of structure), they only provide functions to get input style, open a window and basic rendering primitives. You can build an engine out of them, but I wouldn’t call them engines by themselves any more than you would call DirectX it the windows API a game engine. You can make simple games out if just hose libraries, but anything complex will tend to require a ton of support code (characters, animation, maps/levels, camera control, collision detection, event triggers and such for example) and other libraries, at which point you’re basically writing a small custom engine on top of those libraries.
        7y ago
- TeMPOraL 7y ago
  > And bring physics, input, asset loading, networking, systems, scripting, etc. Along with their own idiosyncrasies and assumptions. Which is something you may decide you do not want to deal with. E.g. hand-coding the little physics you need may be easier than learning the physics engine's API and adjusting your own architecture to mesh with it.
  - onion2k 7y ago
    Yes. That's a very fair point. Most engines I've seen try to implement a general physics model that can handle every genre of games, and there's a lot to be gained by not using that and building something more focused on what you actually need.
    - meheleventyone 7y ago
      Further to that very few engines are developing their own general purpose physics solver and are using middleware. Bullet, PhysX and Box2D are the most popular. Roblox is the only really big engine company I can think of that actually develops their own physics tech (because they started off doing it).
      - Jasper_ 7y ago
        NVIDIA completely bungled PhysX because they chased accuracy for ML/robotics reasons in the newer releases, and the latest PhysX is slower and deprecated useful games tech like cloth. So both Unreal and Unity now have their own physics tech.
        midnightclubbed 7y ago
        Aren't Unity still using PhysX? A lot of engines are still using PhysX (albeit stuck on version 3.x). Upgrading a physics engine is often a pain point, either because it is so tightly integrated in the code base or because game assets have been tuned for the current physics implementation and even a small accuracy or behavior change will require assets to be re-tuned.
DagAgren 7y ago
You are still severely underestimating what a modern game engine does. The technical side is only one part of it. Integrated content creation and editing is a huge part of it.
- dgb23 7y ago
  These things can be hand crafted to fit your needs and capabilities specifically.
  - DagAgren 7y ago
    Sure, but that is a ton of work. Getting it for free, even if it is not perfectly suited to your needs, it a huge time saver.
- s9w 7y ago
  I think it was severely misunderstood what I wrote. When I wrote "2D engine" I meant the drawing code.
  - jfkebwjsbx 7y ago
    That is the point: the "drawing code" is perhaps 20% of a game engine. You are missing asset management (loading, streaming, caching...), audio (big enough to split into libraries and actual audio engines), input (of different kinds), networking (big enough to split too), AI, scripting, physics...
  - DagAgren 7y ago
    The one who misunderstood is you. When people talk about a "game engine" in 2020, they are not talking about drawing code. They are talking about something much, much bigger.
jfkebwjsbx 7y ago
"Drawing bitmaps" with SDL or OpenGL is a trivial part of developing a 2D engine. Calling SDL/SFML for "other stuff" is, again, a tiny part and it is in no way offloading "the other crap" (as you call it). I assume you are biased because you have only coded toy examples. When you start anything remotely complex, you have to do way more things than just "drawing bitmaps". As for Factorio, it is actually a very complex and fast simulation. Downplaying engine devs as "rendering and other crap" is derogatory to say the least.
- s9w 7y ago
  I'm so confused about the heat. The idea that 2D engines are orders of magnitude less complex than 3D engines is ubiquitous and frequently stated by many reputable game devs. Complex game engines will obviously have more complex code. Factorio in particular is certainly pushing the envelope there - with or without a 3rd party rendering engine. A better example would be 2D RPGs.
  - mntmoss 7y ago
    The distinction is in quantity and types of assets. In 2D you usually have some bitmap and vector assets, collision data, animations, and scene structures to tie it all together. In 3D you have all of those things plus the texture/model/material distinctions, lights, skybox, and all the other details that come in as you add more rendering capabilities. However, you can absolutely make 2D games that need lots of kinds of assets. RPGs happen to be one of them, in fact: The incidental details of adding inventory, NPCs, abilities, dialogue, etc. does add up. Every little message and description, every item's properties. You can ship a game by hardcoding much of it, but that's not going to scale with any substantial team. You need real data management, build processes, etc. Where assets interact with each other you get incidental complexity of the Dwarf Fortress bug kind, so where you can, you add static checks. The engine is built in tandem with the asset pipeline, in effect. So - whether it's 2D or 3D, what actually matters is the assets. That's why even in the early 80's you had vector games with 3D effects in them; they just took approaches that simplified the assets and the resulting scenes.
  - danaris 7y ago

by s9w 7y ago

onion2k 7y ago

They abstract away graphics layers and bring convenience. And bring physics, input, asset loading, networking, systems, scripting, etc.

s9w 7y ago
That depends on the engine. The big guys do. But the pure 2D engines do not. And again the point I was trying to make was about graphics. Most if not all do not roll out their own code for input management, window creation, Networking and so on. But 2D graphics is relatively easy to DIY.
- onion2k 7y ago
  But the pure 2D engines do not. I've never seen a 2D game engine that doesn't give you at least graphics, physics, and input.
  - s9w 7y ago
    Not sure we're talking about the same thing then. SDL, glfw, SFML, Monogame.. I don't think any of them contain physics code.
    - deleted 7y ago
      [deleted]
    - meheleventyone 7y ago
      Most of those are libraries/frameworks rather than engines though. A fuzzy distinction I know but most of these are something you might build an engine of top of to avoid some of the cross-platform drudge.
      - versteegen 7y ago
        GLFW, SFML, and SDL absolutely aren't game engines, I don't think it's fuzzy at all. They're libraries for graphics, audio, and other useful APIs. Monogame I'm not familiar with, but since I can't tell by skimming the wikipedia article, I'd call it fuzzy.
        pjmlp 7y ago
        MonoGame as remake from XNA is much more higher level, as Microsoft made it for Indie games on the original XBox and WP7, and with some lessons taken from the earlier Managed Direct X attempt. So while not at engine level, it already provides higher abstractions than those libraries, and a content pipeline.
    - dkersten 7y ago
      Those libraries don’t provide any game structure though (well, SDL and glfw at least, I think the other two do give you a small amount of structure), they only provide functions to get input style, open a window and basic rendering primitives. You can build an engine out of them, but I wouldn’t call them engines by themselves any more than you would call DirectX it the windows API a game engine. You can make simple games out if just hose libraries, but anything complex will tend to require a ton of support code (characters, animation, maps/levels, camera control, collision detection, event triggers and such for example) and other libraries, at which point you’re basically writing a small custom engine on top of those libraries.
      - 7y ago
TeMPOraL 7y ago
> And bring physics, input, asset loading, networking, systems, scripting, etc. Along with their own idiosyncrasies and assumptions. Which is something you may decide you do not want to deal with. E.g. hand-coding the little physics you need may be easier than learning the physics engine's API and adjusting your own architecture to mesh with it.
- onion2k 7y ago
  Yes. That's a very fair point. Most engines I've seen try to implement a general physics model that can handle every genre of games, and there's a lot to be gained by not using that and building something more focused on what you actually need.
  - meheleventyone 7y ago
    Further to that very few engines are developing their own general purpose physics solver and are using middleware. Bullet, PhysX and Box2D are the most popular. Roblox is the only really big engine company I can think of that actually develops their own physics tech (because they started off doing it).
    - Jasper_ 7y ago
      NVIDIA completely bungled PhysX because they chased accuracy for ML/robotics reasons in the newer releases, and the latest PhysX is slower and deprecated useful games tech like cloth. So both Unreal and Unity now have their own physics tech.
      - midnightclubbed 7y ago
        Aren't Unity still using PhysX? A lot of engines are still using PhysX (albeit stuck on version 3.x). Upgrading a physics engine is often a pain point, either because it is so tightly integrated in the code base or because game assets have been tuned for the current physics implementation and even a small accuracy or behavior change will require assets to be re-tuned.

DagAgren 7y ago

You are still severely underestimating what a modern game engine does. The technical side is only one part of it. Integrated content creation and editing is a huge part of it.

dgb23 7y ago
These things can be hand crafted to fit your needs and capabilities specifically.
- DagAgren 7y ago
  Sure, but that is a ton of work. Getting it for free, even if it is not perfectly suited to your needs, it a huge time saver.
s9w 7y ago
I think it was severely misunderstood what I wrote. When I wrote "2D engine" I meant the drawing code.
- jfkebwjsbx 7y ago
  That is the point: the "drawing code" is perhaps 20% of a game engine. You are missing asset management (loading, streaming, caching...), audio (big enough to split into libraries and actual audio engines), input (of different kinds), networking (big enough to split too), AI, scripting, physics...
- DagAgren 7y ago
  The one who misunderstood is you. When people talk about a "game engine" in 2020, they are not talking about drawing code. They are talking about something much, much bigger.

jfkebwjsbx 7y ago

"Drawing bitmaps" with SDL or OpenGL is a trivial part of developing a 2D engine. Calling SDL/SFML for "other stuff" is, again, a tiny part and it is in no way offloading "the other crap" (as you call it). I assume you are biased because you have only coded toy examples. When you start anything remotely complex, you have to do way more things than just "drawing bitmaps". As for Factorio, it is actually a very complex and fast simulation. Downplaying engine devs as "rendering and other crap" is derogatory to say the least.

s9w 7y ago
I'm so confused about the heat. The idea that 2D engines are orders of magnitude less complex than 3D engines is ubiquitous and frequently stated by many reputable game devs. Complex game engines will obviously have more complex code. Factorio in particular is certainly pushing the envelope there - with or without a 3rd party rendering engine. A better example would be 2D RPGs.
- mntmoss 7y ago
  The distinction is in quantity and types of assets. In 2D you usually have some bitmap and vector assets, collision data, animations, and scene structures to tie it all together. In 3D you have all of those things plus the texture/model/material distinctions, lights, skybox, and all the other details that come in as you add more rendering capabilities. However, you can absolutely make 2D games that need lots of kinds of assets. RPGs happen to be one of them, in fact: The incidental details of adding inventory, NPCs, abilities, dialogue, etc. does add up. Every little message and description, every item's properties. You can ship a game by hardcoding much of it, but that's not going to scale with any substantial team. You need real data management, build processes, etc. Where assets interact with each other you get incidental complexity of the Dwarf Fortress bug kind, so where you can, you add static checks. The engine is built in tandem with the asset pipeline, in effect. So - whether it's 2D or 3D, what actually matters is the assets. That's why even in the early 80's you had vector games with 3D effects in them; they just took approaches that simplified the assets and the resulting scenes.
- danaris 7y ago