7 ms·
> I genuinely believe making games without a big "do everything" engine can be easier, more fun, and often less overhead. I am not making a "do everything" game
by danielbarla 1y ago
> I genuinely believe making games without a big "do everything" engine can be easier, more fun, and often less overhead. I am not making a "do everything" game and I do not need 90% of the features these engines provide.
At that point, of course, you don't need the engine. Having said that, every time I've really deep-dived into some particular feature of an engine - such as inverse kinematics and animation blending in Unreal - I've come away thinking "boy, am I glad I didn't spend several weeks trying to code that up from scratch".
There's definitely an argument to be made for minimalism and anti-bloat, but the reason engines are popular is that they really do some heavy lifting for you.
- rishflab 1y agoanimation blending isn't that bad. If you have a two poses represented as lists of quaternions and positions, all you have to do slerp between the quaternions and lerp between the positions. FABRIK IK algo is a ~100 loc function.
- danielbarla 1y agoAgreed, though getting to that point of understanding is what takes time. Also, there are literally dozens of similar topics where a solo dev should be happy to take any help they can get, IMHO. I'm sure audio is similarly easy, as is input, pathfinding, AI decision trees, physics, etc, etc.
- rishflab 1y agophysics is not easy. its pretty challenging and has unending scope. audio can also have unending scope if you want to do physically simulated Spatial Audio. Im not sure if AI/pathfinding are worth developing as part of an engine. I feel like their implementation is heavily dependant on the game type, engine implementations often get in the way, rather than helping. rendering is a beast, especially if you need a long draw distance and have a world that doesnt fit into gpu memory. The whole task of putting all the pieces together into a cohesive package is a huge undertaking as well.
- canpan 1y agoI was like this in the past. Making my first 3D game: After weeks of implementing all input, object management, culling, model loading, math lib, gfx, normal mapping, SSAA,... I had 0% progress on my game. However, for my fun hobby 2D projects, I still self roll without dependency in the web canvas. You could call the browser an engine though.
- billfruit 1y agoAlso using an engine allows us to make progress on the project itself, rather than sinking major time into building infrastructure. Reinventing the wheel isn't that fun for most people.
- pjc50 1y agoOn the contrary, lots of people enjoy the reinventing the wheel part as a means of avoiding all the tricky creative choices and risk of actually shipping a completed game.
- StefanBatory 1y agoIt does feel like for many people, it's a form of procrastination and escapism. I'm still working on the game, I just need to do this and this and this first. Of course - sometimes you just need to learn how it works below, but if your goal is to ship, and you don't have a lot of time, then what I said strikes true to me.
- ben_w 1y agoMe, too many times. I think this is also true beyond games, e.g. for all the different UI libraries.
- bob1029 1y agoThis happens absolutely everywhere. Many B2B SaaS products could have been a single T-SQL script in MSSQL or some other paid/non-OSS/evil capitalist equivalent. I think a lot of developers lean on ideological angles to deflect rational criticism of their lack of progress and direction. Unity and Unreal are absolute powerhouses if you have an actual idea and a burning desire to express it as quickly as possible to as many customers as possible.
- aleph_minus_one 1y ago> Unity and Unreal are absolute powerhouses if you have an actual idea and a burning desire to express it as quickly as possible to as many customers as possible. If your game idea fits well into the structure of these engines: perhaps. But I can tell you that lot of ideas that I have for games ("games" is to be understood in a somewhat more broader sense) don't fit these structures well. So I am very certain that for the game ideas that I have in mind, writing an own game engine would very likely be the better choice.
- pjmlp 1y agoMy graduation thesis was porting a particles visualization engine from NeXTSTEP/Objective-C into Windows 95/Visual C++, based on OpenGL, with samples like marching cubes. This is a single bullet point on modern engines feature list.
- gyomu 1y agoAnd now that you’ve done it, you could probably reimplement it better in a fraction of the time.
- mlvljr 1y ago[dead]
- pjmlp 1y agoExcept that I wouldn't, because most of that stuff would be a shader nowdays, and depending on the API version, not the same kind of shader. This kind of stuff is fun, if the end goal is to become a game engine or tools engineer, if the goal is to make a game, it is mostly yak shaving.
- deleted 1y ago[deleted]
- gyomu 1y ago> “boy, am I glad I didn't spend several weeks trying to code that up from scratch". If your goal is several decades of a career as an independent developer (like OP), what is an investment of a few weeks for a) understanding a topic deeply and b) having source code that you deeply understand, 100% own, and can reuse across future projects?
- ido 1y agoI'm in the same demographic (less successful than Noel, but I have made my living from game dev for the last 15 years, a lot if from my own indie games). I've used multiple engines throughout that time as they seem to have a lifespan before either tech or business reasons obsolete them (e.g. my first commercial release was made with Flash). My only regret were the times I tried to roll my own, I would have saved a lot of time and effort focusing on picking the best tool for the job that saved me as much work as possible. At the end I want to make games and not engines, and only do as much programming as I have to. All those person-millennia spent at epic/unity/etc actually spent doing a lot of stuff (even if you don't need 90% of it, 10% 1000s of people working for decades is still a lot).
- chickenzzzzu 1y agoFace it, you just don't know how to do it and are trying to convince yourself that you don't need to learn how to
- ido 1y agoLots of things I don’t know how to do and can spend time learning, many will be better use of that time and effort than reimplementing a game engine from scratch vs using middleware.
- yakcyll 1y agoIt's worth remembering when deciding on rolling out your own engine that this is a multi-layer trade-off as well, I have an anecdote on this. I have decided a couple years back that my setup will have a hand-rolled physics engine, specifically for the reasons you outlined - having complete understanding over what the code does, how it's structured and how it manages data - but after starting actually-not-so-arduous process of getting it together, it quickly became rather clear that whatever I could implement would pale in comparison to solutions that are robust, field-tested and generally created by professionals. Physics development in particular is known for wonky nonsense, but there are better and worse heuristics and ways to deal with their shortcomings; a handful of books and Youtube presentations still couldn't prepare me for the actual depth of the problems ahead. What I have now works, is relatively stable in initial demos and I am proud of it, I'm going to tweak and use it in the game I'm working on. It is however pretty obvious already that a lot of time is yet to be spent on massaging jank out of the equations. I wholeheartedly recommend spending more than several weeks on implementing various subsystems if one either is generally interested in how these things work or silently wishes for that badge of honour (it shines brightly). However, as they say, if you want to make games, do NOT make an engine. Not just because of the time it takes - it doesn't have to take that much (even though it usually does) - but also because along with total control over the medium for expressing your creative vision, it gives you total responsibility for it as well. Sometimes it's better to work in the confines of rules set out by actual engine developers.
- monkeyelite 1y ago> inverse kinematics and animation blending Either this is a central feature of your game, and writing it is worth it. Or it’s a technical boondoggle, and you don’t need it.
- jayd16 1y agoThis is table stakes for any 3D animation, these days. Anim pop is embarrassing and almost certainly you'll want look IK let alone any of the more complex usage.
- monkeyelite 1y ago> This is table stakes for any 3D animation You’re doing 3d skeletal animation for your indie game? How many skeletons and animations are you going to make? And you don’t consider it a central feature?
- jayd16 1y agoIf you have any animations you're going to want to blend them. If you don't want to make a lot of animations you're probably going to want to use IK for procedural animation. If you use an engine, you won't be forced to spend time and make it a defacto central feature (because you wont have time for other features). You'll just have access to it. Evan a 2.5D platformer, a common indie genre, would want animation blending and foot IK without innovating on it.
- monkeyelite 1y ago> If you have any animations you're going to want to blend them. Yes, if 3d skeletal animation is a central feature of your game it’s not a big deal to spend time making a good system that works for you. > you're probably going to want to use IK Plenty of 3D games with 3d animation don’t have IK > for procedural animation. Wow your game has 3d procedural animation! That better be the main feature right? The reason I’m so skeptical is a feature has cost whether it’s written in the engine you use or not. You have to do work to make your content look good for IK, and for an indie games that’s critical resources to invest in that. For most games, spending time tweaking rigs for IK is not going to make your product better.