7 ms·

I think the biggest reason for the custom code in the small teams is that they make 2D games. A 2D engine barely deserves the name and it's usually more hassle

• jfkebwjsbx 7y ago
  > A 2D engine barely deserves the name If you say so. The vast majority of programmers would have no clue where to start if you put them up to the task. A game engine is much more than a renderer, which is the only easier part in 2D versus 3D.
  • 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.
      • 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
  • emsy 7y ago
    I'd argue most programmers would have a harder time writing reliable audio code from scratch than the rendering part.
    • account42 7y ago
      OpenAL (Soft) [0] does give you fairly easy spatial audio that will be enough for 99% of all games. [0] https://openal-soft.org/ https://openal-soft.org/
      • emsy 7y ago
        But then it wouldn't be from scratch.
  • singron 7y ago
    Animation is also a lot harder in 3D. A decent 3D engine will probably need fully featured skeletal animation: blending and interpolation, translate+scale+rotate, inverse kinematics, etc. A 2D sprite-based game might be able to get away with a much simpler animation system and still look great. E.g. sprite flip-books and really basic translation will get very far for a lot of game styles. Even if you want rotations, you probably don't even need to learn about quaternions since 2d rotations are so much simpler and you might not need to do interpolation/blending. A lot of other parts can be more complicated as well. E.g. testing navigability is difficult in 3D since it's not always clear what you are able to jump on to/fall off of/squeeze through. Relatively common bugs in 3D games are falling out the bottom of the map, escaping out the side, or getting stuck, but they almost never happen in 2D games. Controlling the camera requires a lot more thought in a 3D game. In a 2D game, a fixed camera or a camera that rigidly follows a character is often sufficient. In 3D, the field of view is awkwardly shaped in world-space, and obstructions are more likely and you may need a way to deal with them (e.g. manual camera controls, detecting obstructions and making them transparent, or moving the camera to avoid them). I guess a lot of this comes down to being able to design a 2d game that requires a very simple engine while even seemingly basic 3d games seem to need tons of features to be palatable.
    • jfkebwjsbx 7y ago
      Animations in 2D are not always flip-books and, when they are, the artist's job is harder and requires a lot of man-hours. That is why a game like Age of Empires 2 looks so good even in 2020. Quaternions are not hard, they are just a tool to deal with 3D rotations. On the other hand, 2D rotations have other set of challenges. For instance, sprites that are naively rotated look very bad. Other rendering shenanigans happen in 2D, too: arbitrary scaling, for instance, is trivial in 3D games, while a nightmare in 2D. There is no general algorithm to do so properly, and some people suggest NNs to have a good-looking solution, similar to NVIDIA's DLSS. Camera is not easy in 2D either. There are tons of ways to make cameras for different kinds of games, with different tweaks. There are entire articles written on this out there. Obstructions also happen in 2D for some kinds of perspective and different games provide different solutions. Not everything 2D is an 80's platformer. For sure, you can make trivial games in 2D easily, but that does not mean they will be good, polished games. Same way making trivial 3D games is easy yet not good enough.
• phn 7y ago
  Even for 2D games, if you have a dedicated art team, or a level designer team separate from a programming team, having an engine interface that allows each of these participants to do their own stuff without having to edit code is a massive boost in productivity.
• GaryNumanVevo 7y ago
  2d is just 3d minus the y dimention