13 ms·

Making video games (without an engine) in 2025

573 points by selvan 1y ago

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 ago
  animation 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 ago
    Agreed, 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 ago
      physics 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 ago
  I 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 ago
  Also 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 ago
    On 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 ago
      It 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 ago
      Me, too many times. I think this is also true beyond games, e.g. for all the different UI libraries.
    - bob1029 1y ago
      This 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 ago
  My 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 ago
    And now that you’ve done it, you could probably reimplement it better in a fraction of the time.
    - mlvljr 1y ago
      [dead]
    - pjmlp 1y ago
      Except 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 ago
    I'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 ago
      Face 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 ago
        Lots 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 ago
    It'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 ago
    This 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 ago
        If 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.
tosmatos 1y ago
I really liked this post. I've recently been learning OpenGL and C++, and the libraries surrounding it, like ImGui, which I like using a lot ! But for my projects I think I'll keep using Godot. I really want to make a game, and not the tooling required to make a game. That said, I've dabbled in GDExtension, and if I really need to have something performant, I'll use that. I've got huge amounts of respect for people doing it this way though. They have a level of control over their work that a Unity or even Godot developer cannot hope to have. It has, like any game dev approach, it's pros and cons
- imtringued 1y ago
  The one thing that perplexes me is that there are some annoying warts of Godot that make developing a game in it different than making a game yourself and nobody thinks "hey wouldn't it be easier to make Godot work in this way, than to do everything from scratch?" The key difference is the code driven development workflow that makes it easy to keep different concerns like visual assets, collision boxes, navigation, etc separate. If you do this in Godot, the standard editor features become meaningless, because they are optimized for throwaway workflows with extremely tight coupling (e.g. a player character IS a node containing subnodes, rather than the player character being a high level concept, whose nodes merely represent the player character).
  - weakfish 1y ago
    I mean, you can do Godot this way - just make your player a scene with Node2D or 3D as the root instead of a PlayerCharacter and have it respond to input
savory_pancake 1y ago
It really feels like all the open-source projects are getting more and more capable. I recently went back to fedora linux on my desktop and the nvidia support is so much better on there than it was even a year or two ago. Hyprland is such a smooth wm that wasn't around even a few years ago. I've been using wgpu for cross-platform GPU rendering, but I've heard about SDL3's recent official release, and I really want to try out those GPU rendering capabilities. What a time to be alive.
andreamonaco 1y ago
Kudos to you! I'm writing a game (a little MMO) the same way, the technical and creative freedom is priceless.
atoav 1y ago
One of my first bigger programming projects was a side-scroller in Processing. Processing.org was an amazing way to get into programming since you could draw onto the screen with minimal code. So I essentially had to write my own physics, collisions, trigger functionality, ways of describing levels, enemies etc. The resulting game wasn't really fun, but I loved the process and the lessons learned. Turns out writing your own game engine is a pretty good way of learning to understand existing ones.
_m6gi 1y ago
Many people often say that making an engine from scratch takes too long. But how long does it take to properly learn Unreal or Unity such that you can have an idea and turn it into a game without friction? Presumably, once your engine is finished, you are at that level of expertise instantly, which is a huge time saver. In my opinion, the more experienced of an engineer you are, the more the scales tip in the favor of rolling your own, from a time-spent perspective. The more unique and niche your game is, the more true this is. Stumbling around Unreal's horrid UI for 3 months just to realize that the thing you want to do is barely even possible due to how general and off-the-shelf the engine is, is not a good experience. On the other hand, if you want to make a hyper-realistic, open-world RPG, then rolling your own is probably not a good idea. I also believe that even if it's not always the most efficient thing to do, placing limitations on yourself by using a custom-made specialized engine makes the creativity really flow, and your game, even if not the most advanced, will be a lot more unique as a result of that.
- jon-wood 1y ago
  From a starting point of having dabbled in making 2D games in the past it took me a few days of working through tutorials and documentation for producing assets to be the bottleneck in building a game in Unreal. In Godot I was at the point of being able to make terrible games within a few hours. The amount of lifting that modern game engines do for you is phenomenal, and I think anyone claiming they can write an engine from scratch quicker than they can implement a game with an existing engine is deluding themselves.
  - _m6gi 1y ago
    I think reaching for the delusion card without considering people's preferences, experiences, expertise and philosophy is completely disingenuous and shows that you don't look at game development holistically. Yes, existing engines do a lot of lifting, especially in 3D rendering and physics. But what about games that don't have physics? Or have completely different physics than you would expect? You mentioned assets being the bottleneck, but what about games that don't use any assets at all? It's nice to have 3D solved, but what if your game attempts to emulate 4D? What if you just hate GUI and it slows you down? For a more concrete argument. You also said learning Unreal using tutorials took a few days, which is certainly not possible, unless we are talking only about a very basic understanding. In the same vein, it also takes a few days to make a very basic engine built on top of OpenGL.
buildj48 1y ago
[flagged]
samiv 1y ago
After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious. Engines are the easy part. The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: - importing data from various sources and formats, textures, audio, model files such as gltf, fbx, animations etc etc. - editor app with all the expected standard editing features, cut, copy, paste, undo, redo, save, delete etc. - all the visualizations and operations that let the game developer use the editor to actually create and manipulate data, entities, animations, scenes, audio graphs, scripting support etc. etc. - all the data packaging and baking such as baking static geometries, compiling shaders, resampling and packing textures, audio, creating game content asset packs etc - etc etc. And this is just a small sample of all the features and things that need to be done in order to be able to leverage the engine part. When all this is done you learn that the actual game engine (i.e. the runtime part that implements the game's main loop and the subsystems that go brrr) is actually a rather small part of the whole system. This is why game studios typically have rather small teams (relatively speaking) working on the engine and hordes of "tools" programmers that can handle all the adjacent work that is super critical for the success of the whole thing. [1] https://github.com/ensisoft/detonator https://github.com/ensisoft/detonator
- NotGMan 1y ago
  This. When working on your own engine you also feel as if 90% of the time is spend on user interface creation if you actually want to have an visual editor. People don't realize that they will spend 95% of the time on the engine and 5% on the game. Which is ok if you don't want to make a commercial living out of it. But unless you are making a game with extremely specific needs (eg Factorio) using your own engine will probably kill you commercially.
  - jeffhuys 1y ago
    Even factorio started out on tried-and-tested libraries before moving away from them primarily because of optimization concerns (right?)
Protostome 1y ago
Since you've been making games for 20 years, I'm guessing you're at least in your thirties. Just curious - do you develop games purely as a hobby, or are you able to make a living from it? If it's the latter, I'd love to hear your perspective on how to build a successful indie game-development business!
- cloogshicer 1y ago
  Not OP, but this is Noel Berry, one of the creators of Celeste, a very successful and incredible indie game.
  - Protostome 1y ago
    Didn't know that ... silly me. In any case, I think the question still relevant - is the secret just "if you build it, they will come?" I suspect it isn't since the competition is fierce, there has to be something beyond making a good game
    - msephton 1y ago
      The secret extra sauce is called marketing :)
    - archagon 1y ago
      I don’t know Berry’s game dev history, but Celeste designer Maddy Thorson has been making fantastic 2D platformers since, essentially, the very beginning of Western indie games. (Jumper 1 was released in 2004!) In other words, I think Celeste required decades of preliminary work and industry presence to end up as good as it did. If you build it for a long-ass time, maybe they will eventually come!
slowhadoken 1y ago
I agree with making games from scratch. That being said I thought Celeste was wildly overrated. Keep up he hard work though.
HelloUsername 1y ago
In the end of the post Noel mentions Aseprite, but he might be interested in Libresprite as well? https://libresprite.github.io/ https://libresprite.github.io/
- 3036e4 1y ago
  Does it add much on top of the old GPL aseprite it forked from?
deleted 1y ago
[deleted]
interludead 1y ago
It's refreshing to see someone advocate for small, custom tooling not from a "purist”"standpoint but because it's actually fun and practical for their workflow
zerr 1y ago
I believe a majority of prospective game developers got into it because of interest in game engine development. For such people, Unreal/Unity/Godot take all the fun out of game dev.
- Agingcoder 1y ago
  This is what happened to me a long time ago - I used to write software 3D engines, then 3D cards (3DFX in particular) happened. I remember losing interest at that time ( I eventually figured out that there was still work to do but still…) Now that I’m quite a bit older, I have come to appreciate the game part a lot more - it’s maybe less techie, but it’s actually also why people make games. When I play with my kids then don’t see the tech - they see the game !
  - zerr 1y ago
    That always has been my Achilles' heel - I don't play games, I think that it's a waste of time. So just enjoying the tech side of it.
  - johnnyanmac 1y ago
    I'm constantly split on it. Especially since there's two considerations for me 1. In terms of industry, potential employers do want to see my tech. So there's benefit to showing that I don't need to rely on big tools to deliver features... Unless they are a dedicated Unity/Unreal shop and then they do want someone used to the engine. It's pretty hard to win here, especially with the industry as of now being a disaster to apply into. 2. But I also want to make my own games one day. As such I will eventually need to think as a generalist and focus on shipping. But all those skills may not be what actually pays the bills in the meantime. I like both, but I also gotta eat and I realize that going straight towards my end goal isn't guaranteed to let me keep a roof over my head.
sambeau 1y ago
I recently wrote a game in Javascript (2D; Canvas). I was amazed at how simple it was and how performant plain-old-Javascript and Javascript objects were. Despite thousands of animating things moving on screen, and animated stereo audio, I couldn't get the frame rate to spill over an animation frame.
thorn 1y ago
I am always super curious to read such posts. They make me happy for no reason. I do not make games these days, but I love to read about excited and happy people explaining the process they love to do. At the same time I learn new perspectives to understand what is going on in the world of indie games. I keep this (not so) secret wish in the back of my head because I have to work for some money to support my family and my country (Ukraine). Maybe some time later I will do more of games... Thank you for writing this post, Noel!
- davedx 1y ago
  It’s also refreshing to see what IMO is a very smart selection of technology, when you see so many other people following hype (I’m reminded of the rust gamedev post the other week). C#, SDL3, and some other nice libraries. The thing is, it’s not trivial to get to the point of having enough experience and judgement to know what to choose! When I start a new game I’m often paralised by the sheer volume of engines out there. When I first started making games all I had was GWBASIC…
  - gyesxnuibh 1y ago
    My take away with the final statement of rolling it yourself if it sounds fun is to pick whatever technology that gets your pen on the paper so to speak. If unity gets you making the thing or making the engine gets you making the thing, most important thing is motion. You gotta avoid the paralysis and just pick the thing that seems feasible and start typing ;).
selvan 1y ago
For simpler games, libraries such as raylib or lightweight opensource game engines such as Amulet (https://www.amulet.xyz/ https://www.amulet.xyz/) / Love 2D are good fit.
- yugoslavia4ever 1y ago
  +1 for raylib, probably the best C library ever written.
dakom 1y ago
I've never delivered a game anyone's really paid for, so take with a grain of salt, but imho the big win when you are writing your own stuff is you get to decide what not to include. That sounds obvious but it really isn't. One example: maybe you don't need any object culling at all. Nobody tells you this. Anything you look up will talk about octrees, portals, clusters, and so on - but you might be totally fine just throwing everything at the renderer and designing your game with transitions at certain points. When you know your constraints, you're not guessing, you can measure and know for a fact that it's fine. Another example: shader programming is not like other programming. There's no subclassing or traits. You have to think carefully about what you parameterize. When you know the look you're going for, you can hardcode a bunch of values and, frankly, write a bunch of shit code that looks just right. The list goes on and on... maybe you don't need fancy animation blending when you can just bake it in an external tool. Maybe you don't need 3d spatial audio because your game world isn't built that way. Thing is - when you're writing an _engine_ you need all that. You don't get to tell people writing games that you don't really need shadows or that they need to limit the number of game objects to some number etc. But when you're writing a _game_ (and you can call part of that game the engine), suddenly you get to tweak things and exclude things in all these ways that are perfectly fine. Same idea applies to anything of course.. maybe you don't need a whole SQL database when you know your data format, flat files can be fine. Maybe you don't need a whole web/dom framework when you're just spitting out simple html/css. etc. etc. I think this headspace is pretty common among gamedevs (iiuc large projects often copy/paste dependencies and tweak between projects rather than import and support a generic api too)
- meheleventyone 1y ago
  I agree with almost everything except: > Thing is - when you're writing an _engine_ you need all that. You don't get to tell people writing games that you don't really need shadows or that they need to limit the number of game objects to some number etc. But when you're writing a _game_ (and you can call part of that game the engine), suddenly you get to tweak things and exclude things in all these ways that are perfectly fine. When you're making an engine it's perfectly fine to bake in constraints. Probably most famously PICO-8 does that very intentionally and is written by just one person. Similarly RPGMaker and a bunch of other 'genre specific' game engines also do this. It's just that everyone tries to make something super general purpose which is really a Sisyphean task.
noduerme 1y ago
I really miss the days of Flash when I could write lots of mini-engines as needed (e.g. platformers or side scrollers or 2.5D, multiplayer, chat ... all hand coded but reusable) and rely on being able to mix lots of different pipelines for vector art, bitmaps, 3D, audio and UI. There's nothing like that now. I tried to reinvent a few wheels. But at this point... a fairly low level (for script) rendering library like PixiJS is really the best we have. No frameworks, please. That being said, games are kind of dead. The idea of spending another year or two on another indie game that barely cracks the top 50 for a couple days on an app store is... depressing. Going through the bureaucratic hoops to even get it there and maintain it seems like an exercise in self-torture. I'm kinda back to just making art in my spare time - screen savers, weird web experiences, one-off toys. I think having all my mini-engines in Flash suddenly deleted forever just made me realize how pointless it all was. Maybe I just spent 20 years getting to be great at the wrong thing. I don't know of a historical parallel of someone spending their life perfecting an art that literally was burned down and blackholed overnight, in quite the same way. I imagine the scribes at Alexandria could at least have gone and scriven somewhere else the following year. So screw it, when I started learning code I was 8 and my brother was a CS major, he gave me his laptop to learn BASIC, and he said "we're just writing on sand." I finally learned that was true.
- crq-yml 1y ago
  I got sour on games for a while but I think there are good things awaiting them, because we're starting to get past the hurdle of "new technology usurps the old" actually being germane to the artistic processes that go into game design. Like, it still exists because the devices are so locked down, but it's stopped being a tech-driven business - there's little interest in AAA now, and the broader trends are shaken up too; there's more of a symbiotic pipeline of "make a game that helps people make video content" taking hold, one which has little relationship to recency or production values. That said I have been pursuing the sustainable elements of gaming for years at this point, seeing the same issues - and for me what it comes down to is what I summarize as "the terrarium problem" - the bigger the software ecosystem you build the game over, the more of the jungle you have to port to the next platform du jour. When we approach gaming as a software problem it's just impossible, we can't support all the hardware and all the platforms. But within that there are elements of "I can plan for this". Using tech that is already old is one way; Flash, for example, is emulated now. But if you go back to an earlier console generation or retro computers, you can find even more accuracy, better preservation. I took the compromise of "neo retro", since there are several SBCs around that mix old chips with new stuff - those have much more comfy specs to tinker with, while building on some old ideas. Tech that assumes less of a platform is another: I've taken up Forth, because Forth is the language that assumes you have to DIY everything, so it perpetuates ground-up honesty within your software, especially within a retro environment where there's no API layer to speak of and you have full control. And tech that has more of a standardized element is good: if something is "data structure portable", it's easier to recreate(this is why there are many homebrew ports of "Another World" - it's all bytecode). The last piece of the puzzle in it is - okay, if I take things in that direction, how do I still make it fun to develop with? And that's the part I've been working on lately. I think the tools can be fun. Flash found some fun in it. But Flash as a model is too complex, too situated in just supplying every feature. PICO-8 is also fun, but very focused on a specific aesthetic. I think it's related to data models, conventions and defaults. Getting those things right clears the way.
z3t4 1y ago
I like to start all my software projects from scratch. Everyone who are used to working on large software projects know that it's very slow. But starting from scratch is fast! You just implement the bare minimum. But also on later stages of the development when you have abstractions going, then it becomes even faster to implement new features. Working on an enterprise software project and your own engine that you've written from scratch is nothing alike, you can work 1000x faster when you have written the thing yourself and can just cut out and refactor everything you want. This is why I advocate micro service architecture and small teams. Things are much smoother when you do it yourself and from scratch. There are however landmines you have to hit and it will take years of trail and error until you get a feeling for what architecture and abstractions work and which doesn't as well as learning the in and outs of the language and platform you are working on.
leonard-somero 1y ago
I'm an indie game developer with over 10 years of experience. I'm not using Unity or Unreal, but I do have some frameworks that handle things like rendering graphics or playing audio. However, I write all the game logic, data manipulation, and entity management from scratch for each game I make. It seems to be the smoothest option for me, since I have full control over how my games actually operate, but I don't have to reinvent the wheel as far as the low-level architecture goes.
trollied 1y ago
Just to note that the author wrote this game, >3 million copies sold: https://en.wikipedia.org/wiki/Celeste_(video_game) https://en.wikipedia.org/wiki/Celeste_(video_game)
pinoy420 1y ago
[dead]
throwawayffffas 1y ago
For anything I have ever tried to make, I always find myself fighting the engine. Whether it is Godot, Unity or Unreal. They all feel like a ready made game that you add assets and mod. The problem for me is that I mostly don't want to make that game. An analogy that comes to mind from the web dev world, it feels like the engines are like wordpress. Prebaked and ready to show content, but the moment your objective does not completely align with their preconfiguration you have to do a huge amount of hacking and workarounds.
- moron4hire 1y ago
  Exactly. If you want your game to look exactly like every other game on Google Play, complete with all the same, long, janky splash screens and rendering hitches and slightly screwy text rendering and random audio glitches, use Unity. All that might be acceptable for an adware befouled "idle RPG" style game on mobile (and they're all that kind of game these days). But it really galled me that people were using Unity so heavily for VR. It's extremely difficult to get a Unity game to work well on the standalone VR headsets. To hit the performance targets required by the Meta Quest Store, you really have to rewrite large portions of the engine to get around the fact that Unity is a disorganized, single-threaded, allocation-happy mess. If you want your game to be a quality piece of software, you can't start with a garbage as your foundation.
  - MattRix 1y ago
    There are games in many different genres, many different aesthetics, many different amounts of polish, and many diffrent levels of performance… all made with Unity. It’s true that they provide a bunch of baseline stuff so that low effort games look and feel similar, but it’s not that hard to end up with game made in Unity that feel unique.
- ivanjermakov 1y ago
  What adds oil to the flame is a bunch of "game templates" that you can buy and make your own game just by replacing the title screen and some models. E.g. https://assetstore.unity.com/packages/templates/systems/store-simulator-supermarket-game-template-309463 https://assetstore.unity.com/packages/templates/systems/stor... And if you open Steam games and go to the newest, you see that nearly half of the releases is some version of a generic Unity/Unreal template game in a slightly altered "skin": https://store.steampowered.com/app/2488370/Cash_Cleaner_Simulator/ https://store.steampowered.com/app/2488370/Cash_Cleaner_Simu... https://store.steampowered.com/app/2073910/A_Webbing_Journey/ https://store.steampowered.com/app/2073910/A_Webbing_Journey... https://store.steampowered.com/app/3498270/Better_Mart/ https://store.steampowered.com/app/3498270/Better_Mart/ https://store.steampowered.com/app/2625420/Drive_Beyond_Horizons/ https://store.steampowered.com/app/2625420/Drive_Beyond_Hori... https://store.steampowered.com/app/3163790/Toy_Shop_Simulator/ https://store.steampowered.com/app/3163790/Toy_Shop_Simulato... https://store.steampowered.com/app/3023600/Horse_Farm_Simulator/ https://store.steampowered.com/app/3023600/Horse_Farm_Simula... https://store.steampowered.com/app/3124550/Liquor_Store_Simulator/ https://store.steampowered.com/app/3124550/Liquor_Store_Simu...
russellbeattie 1y ago
So, does everything he said about C# sound about right? I have no real desire to use it, but I'm curious if his opinion was more or less accurate. Not looking for a flame war, just knowledge
- orthoxerox 1y ago
  Yes, C# has had low-level primitives since 1.0 and it has only gotten better in this regard. This means that it's worse than Java at things like devirtualizing calls, but you can write allocation-free hot loops in C# these days. It's also cross-platform and has multiple deployment modes: you can ship the runtime and the program separately (good when you control the end-user machines, like in an enterprise settings), you can tree-shake the runtime and ship it with the program, or you can tree-shake the runtime and use the AOT compiler to ship a go-like native binary. The JIT compiler is still better for long-running processes like servers, but for one-shot programs where the startup time is critical, like CLI tools and FaaS, the AOT compiler is really great.
  - bscphil 1y ago
    > you can tree-shake the runtime and use the AOT compiler to ship a go-like native binary. The OP talks about doing this for mobile platforms, but could I take e.g. the OP's source code (he co-wrote Celeste) and trivially compile an AOT native binary for x86_64, or would more work be required to make that possible? (Interestingly, Celeste on Linux doesn't use the dotnet runtime, but instead a portable Mono runtime which I believe is based on MonoKickstart. [1]) [1] https://github.com/flibitijibibo/MonoKickstart https://github.com/flibitijibibo/MonoKickstart
varbhat 1y ago
Isn't that a huge effort? I remember few games which developed their own game engines from scratch (factorio, limbo, bg3). But, wouldn't it be easier and better to use game engines like godot?
- OnionBlender 1y ago
  I suppose it depends where you draw the line between engine and framework. Factorio used parts of Allegro until 2018. https://www.factorio.com/blog/post/fff-230 https://www.factorio.com/blog/post/fff-230
  - 3036e4 1y ago
    Engine these days implies one of those IDEs with everything included (scene editor etc). I don't know how or why, but language drifted in the last 20 years or so.
lucraft 1y ago
Maybe a dumb question, but what is the C# compiler and runtime that you use? I used to be up to date with .NET and Mono and stuff but I'm 10 years out of date
- kkukshtel 1y ago
  Modern .NET/C# is cross-platform by default (CoreCLR runtime). You don't need Mono anymore.
- OnACoffeeBreak 1y ago
  I am not at all familiar with C# development, but the author mentions Native-AOT, which, from a cursory look, seems like a C# compiler. https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
tiniuclx 1y ago
That was a very fun read! While I’m using Godot for my hacking simulator game, Botnet of Ares [0] I think the native C# approach is very much justified in this case, and Noel clearly has had massive success with Celeste. I like Godot because of the UI primitives built into the engine. For a UI heavy simulation game like mine, the game engine does a lot of the heavy lifting. Sure, I don’t use 90% of the 2D/3D features of the engine, but that’s okay. [0] https://store.steampowered.com/app/3627290/Botnet_of_Ares/ https://store.steampowered.com/app/3627290/Botnet_of_Ares/
- deepfriedrice 1y ago
  Oh wow - I wanted to build a game just like this not too long ago but never found the time. Wishlisted!
kkukshtel 1y ago
I agree with a lot of this, and am similarily working on my own code-only C# game framework meant as a spiritual successfor to XNA/Monogame (using Sokol instead of SDL): https://zinc.graphics/ https://zinc.graphics/ In OP's post as well he brings up some of the main factors that make modern C# incredible: - Cross platform development (and runtime). - NativeAOT Compiling (great for consoles, provided you have backend headers). - Native Hot-reloading. - Reflection I'd also add: - Source Generators Modern C# is incredible. I think people still discount it due to its admittedly bad legacy, but the past five years of C# and CoreCLR development make me feel like it's truly a language that has everything necessary but isn't baroque or overburdened. My only major request, Union types, is also in proposal and will (hopefully) come in the next year or so: https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md https://github.com/dotnet/csharplang/blob/main/proposals/Typ...
- w4rh4wk5 1y ago
  Out of curiosity, do you have some pointers for getting into C# for these kinds of projects? I've only used C# for standalone win32 applications and inside of Unity. I am familiar with low-level game engine stuff in C/C++, but always discarded C# as not being viable for cross-platform projects (as in game consoles). Guess I was wrong. :)
OnACoffeeBreak 1y ago
The author says that they tend to load all of the assets on init. This sidesteps the issue of the C#'s garbage collector (GC). I am not a C# developer, but seem to recall reading that GC can cause unexpected slow downs. Web search shows articles on tips and tricks for optimizing GC in C#, so it seems like a real issue. Does anyone have any first hand experience they would like to share? Is it easy to avoid the GC slowing down your game unexpectedly? Is it only a problem for a certain class of games?
- Const-me 1y ago
  There’s a recent promising development relevant to the GC pause issue. It seems couple weeks ago some smart developer working for Microsoft has made a version of GC called “Satori” which pretty much solved these GC pauses for many real-world use cases. An overview article: https://blog.applied-algorithms.tech/a-sub-millisecond-gc-for-net https://blog.applied-algorithms.tech/a-sub-millisecond-gc-fo... Long discussion thread with many graphs with measurements: https://github.com/dotnet/runtime/discussions/115627 https://github.com/dotnet/runtime/discussions/115627 I don’t yet have hands-on experience with that Satori GC, though.
- jayd16 1y ago
  In a game like the author's where you just init/pool everything on load you can simply disable the garbage collector during gameplay.
TacticalCoder 1y ago
[dead]
JKCalhoun 1y ago
This is basically what I did a couple years ago [1]. SDL2 and a bit of C++ to create a "sprite" class. Some collision code in the sprite class... If you want to call what I added an "engine" it was more like a pedal-assist bike. Too often I find "engines" end up driving the project/game. That is, you end up writing the game to the engine. It's why I've avoided Unity, etc. — high-level engines like that seem to guide you to writing the same game everyone else is writing — just with different assets. Never mind you spend too much time, in my opinion, learning the engine and not getting the game written. To be sure there was a learning curve just pulling in SDL, but the curve was slight and it seemed more universally useful to know SDL as it can be employed in other cross-platform projects I might undertake — not just games. [1] https://store.steampowered.com/app/2318420/Glypha_Vintage/ https://store.steampowered.com/app/2318420/Glypha_Vintage/
- symfoniq 1y ago
  Just wanted to say that I remember playing your game as a kid on the family Mac IIci. Thanks for the fun memories, and best wishes.
gr4vityWall 1y ago
That was a great post. I had no idea modern .NET had hot-reloading built-in like that. From my experience programming games, that's the biggest time saver you can ask for. Does it work well (or at all) with Godot/C#? A few years ago, a notorious developer in the GameMaker community wrote a tool that added live reloading to it, and immediately it got widely adopted by big projects. In terms of prototyping, I think an 'ideal' engine for extremely fast iteration would be something like GameMaker 8.1, but with hot reloading and slightly better window management inside the editor itself. I don't share the core needs of the author though, I prefer using an engine with a built-in editor, specially in the beginning of a project. I really wanted to like Godot, by the abstractions it provides never 'clicked' with me. I can't think of a game like a bunch of nodes. That's unfortunate for me as Godot it the most popular free game engine AFAIK, with all the goods that comes with that. I also really don't want to spend years mastering a proprietary tool again.
- tigerlily 1y ago
  > That was a great post. I had no idea modern .NET had hot-reloading built-in like that. I fully concur, that was a great post. And on full time Linux, just incredible. Definitely it's given me the itch to try a few new things :)
EdgeCaseExist 1y ago
That's kind of an engine though ? An engine is just a bunch of low level types, DS, algos that go onto build mid level abstractions that go onto form systems. In this case you can argue the game itself (aka the runtime) is the game engine? As others say, getting data (Assets) in/out of the engine is the hard part. Especially as they are the real contribution to the shipped game been so large (unless smart compression, delivery optimisation is used, sadly not common).
Fokamul 1y ago
Good example of game with custom game engine is Factorio. They also documented their development a lot on their website and I think they have no problem to answer anything regarding developing own engine in their forum.
enbugger 1y ago
Game engine is an art tool in the same way like Blender or Photoshop are. You have to learn its tips and tricks the same way artists do. Usually programmers consider anything that does not have a dedicated UI as fatal flaw hence all the bias towards big engines. For example, you want to make and thumbnail picture of a 3d model/character. My first thought as a programmer on "correct" approach to that in UE was like well I need to setup a separate world with brand new lightning and have some renderer features off. The perfect "hack" for this is to have a separate "dressing room" under the level where the model teleports into and then back during single frame. Hundreds of such nuances can be only learned.
codeproject 1y ago
there is a minor mistake in this.." their minds jump to what it looked like circa 2003 - a closed source, interpreted, verbose...", C# was never interpreted. From the beginning, C# code has always been compiled to Intermediate Language (IL), which is then JIT-compiled by the .NET CLR at runtime.
- dragonwriter 1y ago
  To be fair, “compiled to bytecode which is JITted af runtime” is pretty common of lnaguage implementations described as “interpreted”, like CRuby.
curtisszmania 1y ago
[dead]
deleted 1y ago
[deleted]
nico 1y ago
And now you can also just vibecode little games and start having fun right away, they are great for kids https://rosebud.ai/p/800a3295-ea07-4c80-a4f1-10fd8db24088 https://rosebud.ai/p/800a3295-ea07-4c80-a4f1-10fd8db24088 https://openjam.ai/lonely_ant_702/v3nyt4if54 https://openjam.ai/lonely_ant_702/v3nyt4if54 https://rosebud.ai https://rosebud.ai https://openjam.ai/ https://openjam.ai/
- jagger27 1y ago
  Why should less thought be put into things made for children?
  - nico 1y ago
    Why do you think vibecoding and learning together with kids is putting less thought? However, kids don't care too much about thought. They care a lot more about attention and fun With these tools you get to the fun part faster and can give them a lot more attention You also get to co-create with them and they get to express their creativity seeing results in realtime
msephton 1y ago
I use Lua & Love2D to make games with a similar ethos. Being able to set my own constraints is fun, and that's what game dev is about for me. As soon as something stops being fun, I know I'm doing it wrong and there must be a better way. My game YOYOZO is a tiny 39KB but made it to Ars Technica's "Best Games of 2023" list alongside heavyweights like Super Mario Wonder and Tears of the Kingdom! https://news.ycombinator.com/item?id=38372936 https://news.ycombinator.com/item?id=38372936
- hbn 1y ago
  Hey I recognize that game, great work! I've had my Playdate for a couple years but it was only this past weekend I finally got inspired to start playing around with the SDK like I've been telling myself I would since I bought the thing. I had never used Lua prior to now so that's also part of the learning experience. I'd really like some strong typing and some other language safety features, but it's good for what it needs to do. So far all I've made is a little tech demo of text that rotates around in fake 3D space in relation to the crank, like the iOS options picker. Clip here: https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a The other thing I learned from this project is I forgot more trigonometry skills than I thought in my years of CRUD/webapp development. One of the best things about developing for Playdate is how freeing it is to have a fixed canvas that you're drawing to. I'm so used to having to make all my UIs responsive, I love being able to just position something at a pixel value and know it'll work on everyone's device.
- hernandipietro 1y ago
  Congratulations man, great work.
  - msephton 1y ago
    Thanks so much, it's appreciated.
VikingCoder 1y ago
Please help me figure out the best way to share code between Github repositories... I love C#, and I acknowledge Github as the king of source control. I make a new Repository a couple times a week, and use Visual Studio Code to clone it, and open a terminal and "dotnet new gitignore" and then use dotnet to make new projects all over the place... On multiple machines, even. On a VM on my NAS. On my Windows machine. On my Windows laptop. On a VPS. And I'm happy. But how in the holy hell am I supposed to share code from one repository to another? I want to make VikingCoderLib as a C# library (classlib), and drop in all of my favorite Extensions for generics and strings, and etc. And then make another classlib for some of my Protocol Buffer utilities. And another classlib for setting up a terminal.js console for an app. And... What's the best way to do that? Submodules? They really seem to suck. I can't easily make changes here, and use them there, without it being a huge pain in the rear. Am I doing this wrong? Am I missing something?
- wsc981 1y ago
  I don't mind submodules much. I mean when I first used them I thought it was sucked, but now I use it all the time for personal projects. I like to make small Lua libs or fork existing Lua libs and include those in a lib directory in my LÖVE / LÖVR projects. Works fine for me. Perhaps the only thing that sucks a bit about submodules, might be if you work with multiple people and some reference of a submodule is updated and you need to go into the submodule directory to update the reference locally. But I think that's the only thing, no big deal. I don't think you deal with this issue much when you work by yourself on a solo project, on a single machine.
- coffeebeqn 1y ago
  Monorepo?
  - VikingCoder 1y ago
    I hate that you're almost certainly right. It feels like there should be a good way to have a dotnet classlib in one repository, and use it from others, but it just doesn't feel like they fit together the way they should.
orthoxerox 1y ago
A lot of the time the indie game developer is a former professional programmer. This of course affects how they interact with the game development process. Someone who's coming from a different walk of life (say, an artist or a TTRPG designer trying to make a game) will obviously be much more productive with an off-the-shelf engine like GameMaker or Unity. They accept the engine with its editor as the only way to make a game and get cracking. A programmer opens the editor and is presented with the 3D scene editor. "Nonono, where's main()?" they immediately ask. "Why is there a 3D scene editor if I want to procgen my levels?" "How do mods work?" "Who told you I needed physics simulation in my game by default?" "Running the game inside the editor is cool and all that, but I'd rather run the editor inside the game."
Lichtso 1y ago
Made me realize that most of the games I really enjoyed have their own custom engines (made for a single game or franchise): Starbound, Stardew Valley, Minecraft, Factorio, RollerCoaster Tycoon, Empire Earth, The Sims, Project Zomboid ... Only exception might be Portal, but even that is using an in-house solution mostly for developed for one franchise. Like with most things: If you are new and have to learn everything or if you actually need to pump titles out you should prefer quantity over quality and the major game engines are the way to go. But, if you really want to polish something it will require a long long time and then investing in engine development can pay off. The trap is starting with the later if you haven't made a few dozen games yet and never shipped anything. Then it will stay that way.
- jebarker 1y ago
  Just to clarify, are you saying that if you've never shipped any games then you should start with an established engine and only go artisanal once you have that experience?
  - Lichtso 1y ago
    Yes, pretty much. I don't say the custom engine first path can't work, heck I did ship my own games on custom engines first myself, but it is probably not the path of least resistance.
- dismalaf 1y ago
  This... I don't think I've ever truly enjoyed a Unity game. Maybe KSP, but it runs like shit and isn't a good advertisement for that engine. Even Unreal Engine: I've only enjoyed Unreal itself.
  - bscphil 1y ago
    There are definitely some Unity games I've really liked - the Ori games, Hollow Knight - but the engine has never been a positive of my experience with the game. They're full of jank and physics bugs, and in a weird hard to describe way kind of feel "alike". You know you're playing a Unity game, which is bizarre for a part of the game experience that's so low level.
doawoo 1y ago
I always saw it like this: - If you're building an engine without a game in mind, you're just going to end up with tools you don't use. - If you have a game you want to see to the end, and make an engine for it, you're going to build exactly what you need and nothing else. With the bonus of having lots of code you can reuse for the next project. All that said I'm sticking with Godot since I have limited time, and if I want to bang out a quick gameplay idea to see if it even works, I don't want to start from nothing. (I say all this after building a 2.5D-ish engine with c# and monogame)
RyanOD 1y ago
As a "for fun" side project, I've started building clones of retro classics in Pygame as a way to help beginners gain knowledge of procedural game dev fundamentals. Python seems like a nice entry point and Pygame works well for the 2D classics like Frogger or Defender or Dig Dug or whatever. It's a lot of fun, but, woah! It's a lot more work than I was expecting.
hannofcart 1y ago
From the limited game dev experience I have/had, my recommendation is to introspect whether building the tech is just fun escapism from working on the really hard part of game dev: designing something that's really fun to play. Building your own engine may "feel" like progress but it isn't. A fun game loop implemented with the most rudimentary frameworks, (or sometimes even pen and paper!) is more valuable than just a fancy custom engine implementation without a fun game mechanic. Very often I find some friends of mine still in gamedev getting sidetracked by the intellectual stimulation that building tech gives them (because they are programmers) and burn out before they actually design/discover a fun game mechanic that they can actually ship a game with. All this is ofcourse assuming you want to make money off your game. If you are just having fun with a hobby project or doing it to hone your programming skills, go nuts with the custom game engine code; more power to you!
ccvannorman 1y ago
Game dev here, building a game using the "engine-only" version of PlayCanvas (a 3d engine). Asset loading, rendering, physics, object management, update loops, raycasting is all handled by the engine (js). My code is everything else, including a low-tech drag and drop scene editor. I've got to say it's the deepest I've ever been in the abstraction stack for building a game. I have to hand build everything. I definitely wouldn't want to write engine code itself unless I was building an engine; building a good engine takes heaps of engineering and time which I don't have. I will say though, I absolutely love the level of fine control I have over every aspect of my game (when compared say to a Unity game or even a PlayCanvas game built by their editor).
BryanLegend 1y ago
Hate to be mean, but this guys last game was a complete failure after multiple years of development: https://www.exok.com/posts/2025-01-22-earthblade-final-update/ https://www.exok.com/posts/2025-01-22-earthblade-final-updat...
- hbn 1y ago
  That's not a failure, it was just never finished. And more because of personal matters than anything technical. I'm not sure why this is relevant.
  - BryanLegend 1y ago
    Of course it was relevant. If they had a better game engine it would have been further along.
    - filleduchaos 1y ago
      They didn't need "a better game engine" to create Celeste.
    - hbn 1y ago
      The article you yourself linked says the game's development troubles were from pressure to surpass their previous game which was a smash hit. How would a better engine fix that?
bitwize 1y ago
If you're serious about making video games, you should probably be using a commercial engine. Period. No exceptions. Unless you're EA or Microsoft, you're just not going to develop a custom engine that can compete with Unity and Unreal. You may be able to write a good basic rendering pipeline and event loop, but the major engines have enormous ecosystems of tooling and talent, ready to go, and they're available across all major platforms including proprietary consoles. Things will go much, much easier for you if you just use those. If you're just fucking around, do what you want, but if you actually want to ship, it's Unity or Unreal all the way. And no, I don't think Godot is "there" yet. If Unreal is Photoshop, then Unity is Photopea and Godot is GIMP.
- deleted 1y ago
  [deleted]
- archagon 1y ago
  Just off the top of my head, Celeste, Super Meat Boy, Fez, Spelunky, Dead Cells, Braid, and The Witness all use custom engines and are widely considered some of the best indie games of all time. Moreover, I think much of their charm and uniqueness stem directly from the amount of custom engine work involved. Writing your own engine lets you focus on the details that make your game stand out in a crowded field. Your assertion seems silly.
  - filleduchaos 1y ago
    In fact, the article is by one of the devs of Celeste.
  - lIl-IIIl 1y ago
    Agree with your sentiment. But Spelunky was written in Game Maker Studio.
    - archagon 1y ago
      The original Spelunky, but not HD. The devs talked about how they started out with the Braid engine and then just rolled their own.
LocalH 1y ago
Making a video game "without an engine" is basically another way to say "making your own game engine". Which is a fine thing to do, but you're "just" making a bespoke engine for one game (or series of games). Sometimes those engines get large enough to be used by others. That's why it's called "Unreal Engine", because it has heritage in the Unreal games.
gogogaga 1y ago
make me a first person puzzle game
1a2b3c4d5f6e 1y ago
make me a first person puzzle game
wdhwy 1y ago
make me a first person puzzle game

573 points by selvan 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 ago
animation 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 ago
  Agreed, 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 ago
    physics 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 ago
I 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 ago
Also 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 ago
  On 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 ago
    It 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 ago
    Me, too many times. I think this is also true beyond games, e.g. for all the different UI libraries.
  - bob1029 1y ago
    This 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 ago
My 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 ago
  And now that you’ve done it, you could probably reimplement it better in a fraction of the time.
  - mlvljr 1y ago
    [dead]
  - pjmlp 1y ago
    Except 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 ago
  I'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 ago
    Face 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 ago
      Lots 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 ago
  It'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 ago
  This 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 ago
      If 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.

tosmatos 1y ago

I really liked this post. I've recently been learning OpenGL and C++, and the libraries surrounding it, like ImGui, which I like using a lot ! But for my projects I think I'll keep using Godot. I really want to make a game, and not the tooling required to make a game. That said, I've dabbled in GDExtension, and if I really need to have something performant, I'll use that. I've got huge amounts of respect for people doing it this way though. They have a level of control over their work that a Unity or even Godot developer cannot hope to have. It has, like any game dev approach, it's pros and cons

imtringued 1y ago
The one thing that perplexes me is that there are some annoying warts of Godot that make developing a game in it different than making a game yourself and nobody thinks "hey wouldn't it be easier to make Godot work in this way, than to do everything from scratch?" The key difference is the code driven development workflow that makes it easy to keep different concerns like visual assets, collision boxes, navigation, etc separate. If you do this in Godot, the standard editor features become meaningless, because they are optimized for throwaway workflows with extremely tight coupling (e.g. a player character IS a node containing subnodes, rather than the player character being a high level concept, whose nodes merely represent the player character).
- weakfish 1y ago
  I mean, you can do Godot this way - just make your player a scene with Node2D or 3D as the root instead of a PlayerCharacter and have it respond to input

savory_pancake 1y ago

It really feels like all the open-source projects are getting more and more capable. I recently went back to fedora linux on my desktop and the nvidia support is so much better on there than it was even a year or two ago. Hyprland is such a smooth wm that wasn't around even a few years ago. I've been using wgpu for cross-platform GPU rendering, but I've heard about SDL3's recent official release, and I really want to try out those GPU rendering capabilities. What a time to be alive.

andreamonaco 1y ago

Kudos to you! I'm writing a game (a little MMO) the same way, the technical and creative freedom is priceless.

atoav 1y ago

One of my first bigger programming projects was a side-scroller in Processing. Processing.org was an amazing way to get into programming since you could draw onto the screen with minimal code. So I essentially had to write my own physics, collisions, trigger functionality, ways of describing levels, enemies etc. The resulting game wasn't really fun, but I loved the process and the lessons learned. Turns out writing your own game engine is a pretty good way of learning to understand existing ones.

_m6gi 1y ago

Many people often say that making an engine from scratch takes too long. But how long does it take to properly learn Unreal or Unity such that you can have an idea and turn it into a game without friction? Presumably, once your engine is finished, you are at that level of expertise instantly, which is a huge time saver. In my opinion, the more experienced of an engineer you are, the more the scales tip in the favor of rolling your own, from a time-spent perspective. The more unique and niche your game is, the more true this is. Stumbling around Unreal's horrid UI for 3 months just to realize that the thing you want to do is barely even possible due to how general and off-the-shelf the engine is, is not a good experience. On the other hand, if you want to make a hyper-realistic, open-world RPG, then rolling your own is probably not a good idea. I also believe that even if it's not always the most efficient thing to do, placing limitations on yourself by using a custom-made specialized engine makes the creativity really flow, and your game, even if not the most advanced, will be a lot more unique as a result of that.

jon-wood 1y ago
From a starting point of having dabbled in making 2D games in the past it took me a few days of working through tutorials and documentation for producing assets to be the bottleneck in building a game in Unreal. In Godot I was at the point of being able to make terrible games within a few hours. The amount of lifting that modern game engines do for you is phenomenal, and I think anyone claiming they can write an engine from scratch quicker than they can implement a game with an existing engine is deluding themselves.
- _m6gi 1y ago
  I think reaching for the delusion card without considering people's preferences, experiences, expertise and philosophy is completely disingenuous and shows that you don't look at game development holistically. Yes, existing engines do a lot of lifting, especially in 3D rendering and physics. But what about games that don't have physics? Or have completely different physics than you would expect? You mentioned assets being the bottleneck, but what about games that don't use any assets at all? It's nice to have 3D solved, but what if your game attempts to emulate 4D? What if you just hate GUI and it slows you down? For a more concrete argument. You also said learning Unreal using tutorials took a few days, which is certainly not possible, unless we are talking only about a very basic understanding. In the same vein, it also takes a few days to make a very basic engine built on top of OpenGL.

buildj48 1y ago

[flagged]

samiv 1y ago

After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious. Engines are the easy part. The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: - importing data from various sources and formats, textures, audio, model files such as gltf, fbx, animations etc etc. - editor app with all the expected standard editing features, cut, copy, paste, undo, redo, save, delete etc. - all the visualizations and operations that let the game developer use the editor to actually create and manipulate data, entities, animations, scenes, audio graphs, scripting support etc. etc. - all the data packaging and baking such as baking static geometries, compiling shaders, resampling and packing textures, audio, creating game content asset packs etc - etc etc. And this is just a small sample of all the features and things that need to be done in order to be able to leverage the engine part. When all this is done you learn that the actual game engine (i.e. the runtime part that implements the game's main loop and the subsystems that go brrr) is actually a rather small part of the whole system. This is why game studios typically have rather small teams (relatively speaking) working on the engine and hordes of "tools" programmers that can handle all the adjacent work that is super critical for the success of the whole thing. [1] https://github.com/ensisoft/detonator https://github.com/ensisoft/detonator

NotGMan 1y ago
This. When working on your own engine you also feel as if 90% of the time is spend on user interface creation if you actually want to have an visual editor. People don't realize that they will spend 95% of the time on the engine and 5% on the game. Which is ok if you don't want to make a commercial living out of it. But unless you are making a game with extremely specific needs (eg Factorio) using your own engine will probably kill you commercially.
- jeffhuys 1y ago
  Even factorio started out on tried-and-tested libraries before moving away from them primarily because of optimization concerns (right?)

Protostome 1y ago

Since you've been making games for 20 years, I'm guessing you're at least in your thirties. Just curious - do you develop games purely as a hobby, or are you able to make a living from it? If it's the latter, I'd love to hear your perspective on how to build a successful indie game-development business!

cloogshicer 1y ago
Not OP, but this is Noel Berry, one of the creators of Celeste, a very successful and incredible indie game.
- Protostome 1y ago
  Didn't know that ... silly me. In any case, I think the question still relevant - is the secret just "if you build it, they will come?" I suspect it isn't since the competition is fierce, there has to be something beyond making a good game
  - msephton 1y ago
    The secret extra sauce is called marketing :)
  - archagon 1y ago
    I don’t know Berry’s game dev history, but Celeste designer Maddy Thorson has been making fantastic 2D platformers since, essentially, the very beginning of Western indie games. (Jumper 1 was released in 2004!) In other words, I think Celeste required decades of preliminary work and industry presence to end up as good as it did. If you build it for a long-ass time, maybe they will eventually come!

slowhadoken 1y ago

I agree with making games from scratch. That being said I thought Celeste was wildly overrated. Keep up he hard work though.

HelloUsername 1y ago

In the end of the post Noel mentions Aseprite, but he might be interested in Libresprite as well? https://libresprite.github.io/ https://libresprite.github.io/

3036e4 1y ago
Does it add much on top of the old GPL aseprite it forked from?

deleted 1y ago

[deleted]

interludead 1y ago

It's refreshing to see someone advocate for small, custom tooling not from a "purist”"standpoint but because it's actually fun and practical for their workflow

zerr 1y ago

I believe a majority of prospective game developers got into it because of interest in game engine development. For such people, Unreal/Unity/Godot take all the fun out of game dev.

Agingcoder 1y ago
This is what happened to me a long time ago - I used to write software 3D engines, then 3D cards (3DFX in particular) happened. I remember losing interest at that time ( I eventually figured out that there was still work to do but still…) Now that I’m quite a bit older, I have come to appreciate the game part a lot more - it’s maybe less techie, but it’s actually also why people make games. When I play with my kids then don’t see the tech - they see the game !
- zerr 1y ago
  That always has been my Achilles' heel - I don't play games, I think that it's a waste of time. So just enjoying the tech side of it.
- johnnyanmac 1y ago
  I'm constantly split on it. Especially since there's two considerations for me 1. In terms of industry, potential employers do want to see my tech. So there's benefit to showing that I don't need to rely on big tools to deliver features... Unless they are a dedicated Unity/Unreal shop and then they do want someone used to the engine. It's pretty hard to win here, especially with the industry as of now being a disaster to apply into. 2. But I also want to make my own games one day. As such I will eventually need to think as a generalist and focus on shipping. But all those skills may not be what actually pays the bills in the meantime. I like both, but I also gotta eat and I realize that going straight towards my end goal isn't guaranteed to let me keep a roof over my head.

sambeau 1y ago

I recently wrote a game in Javascript (2D; Canvas). I was amazed at how simple it was and how performant plain-old-Javascript and Javascript objects were. Despite thousands of animating things moving on screen, and animated stereo audio, I couldn't get the frame rate to spill over an animation frame.

thorn 1y ago

I am always super curious to read such posts. They make me happy for no reason. I do not make games these days, but I love to read about excited and happy people explaining the process they love to do. At the same time I learn new perspectives to understand what is going on in the world of indie games. I keep this (not so) secret wish in the back of my head because I have to work for some money to support my family and my country (Ukraine). Maybe some time later I will do more of games... Thank you for writing this post, Noel!

davedx 1y ago
It’s also refreshing to see what IMO is a very smart selection of technology, when you see so many other people following hype (I’m reminded of the rust gamedev post the other week). C#, SDL3, and some other nice libraries. The thing is, it’s not trivial to get to the point of having enough experience and judgement to know what to choose! When I start a new game I’m often paralised by the sheer volume of engines out there. When I first started making games all I had was GWBASIC…
- gyesxnuibh 1y ago
  My take away with the final statement of rolling it yourself if it sounds fun is to pick whatever technology that gets your pen on the paper so to speak. If unity gets you making the thing or making the engine gets you making the thing, most important thing is motion. You gotta avoid the paralysis and just pick the thing that seems feasible and start typing ;).

selvan 1y ago

For simpler games, libraries such as raylib or lightweight opensource game engines such as Amulet (https://www.amulet.xyz/ https://www.amulet.xyz/) / Love 2D are good fit.

yugoslavia4ever 1y ago
+1 for raylib, probably the best C library ever written.

dakom 1y ago

I've never delivered a game anyone's really paid for, so take with a grain of salt, but imho the big win when you are writing your own stuff is you get to decide what not to include. That sounds obvious but it really isn't. One example: maybe you don't need any object culling at all. Nobody tells you this. Anything you look up will talk about octrees, portals, clusters, and so on - but you might be totally fine just throwing everything at the renderer and designing your game with transitions at certain points. When you know your constraints, you're not guessing, you can measure and know for a fact that it's fine. Another example: shader programming is not like other programming. There's no subclassing or traits. You have to think carefully about what you parameterize. When you know the look you're going for, you can hardcode a bunch of values and, frankly, write a bunch of shit code that looks just right. The list goes on and on... maybe you don't need fancy animation blending when you can just bake it in an external tool. Maybe you don't need 3d spatial audio because your game world isn't built that way. Thing is - when you're writing an _engine_ you need all that. You don't get to tell people writing games that you don't really need shadows or that they need to limit the number of game objects to some number etc. But when you're writing a _game_ (and you can call part of that game the engine), suddenly you get to tweak things and exclude things in all these ways that are perfectly fine. Same idea applies to anything of course.. maybe you don't need a whole SQL database when you know your data format, flat files can be fine. Maybe you don't need a whole web/dom framework when you're just spitting out simple html/css. etc. etc. I think this headspace is pretty common among gamedevs (iiuc large projects often copy/paste dependencies and tweak between projects rather than import and support a generic api too)

meheleventyone 1y ago
I agree with almost everything except: > Thing is - when you're writing an _engine_ you need all that. You don't get to tell people writing games that you don't really need shadows or that they need to limit the number of game objects to some number etc. But when you're writing a _game_ (and you can call part of that game the engine), suddenly you get to tweak things and exclude things in all these ways that are perfectly fine. When you're making an engine it's perfectly fine to bake in constraints. Probably most famously PICO-8 does that very intentionally and is written by just one person. Similarly RPGMaker and a bunch of other 'genre specific' game engines also do this. It's just that everyone tries to make something super general purpose which is really a Sisyphean task.

noduerme 1y ago

I really miss the days of Flash when I could write lots of mini-engines as needed (e.g. platformers or side scrollers or 2.5D, multiplayer, chat ... all hand coded but reusable) and rely on being able to mix lots of different pipelines for vector art, bitmaps, 3D, audio and UI. There's nothing like that now. I tried to reinvent a few wheels. But at this point... a fairly low level (for script) rendering library like PixiJS is really the best we have. No frameworks, please. That being said, games are kind of dead. The idea of spending another year or two on another indie game that barely cracks the top 50 for a couple days on an app store is... depressing. Going through the bureaucratic hoops to even get it there and maintain it seems like an exercise in self-torture. I'm kinda back to just making art in my spare time - screen savers, weird web experiences, one-off toys. I think having all my mini-engines in Flash suddenly deleted forever just made me realize how pointless it all was. Maybe I just spent 20 years getting to be great at the wrong thing. I don't know of a historical parallel of someone spending their life perfecting an art that literally was burned down and blackholed overnight, in quite the same way. I imagine the scribes at Alexandria could at least have gone and scriven somewhere else the following year. So screw it, when I started learning code I was 8 and my brother was a CS major, he gave me his laptop to learn BASIC, and he said "we're just writing on sand." I finally learned that was true.

crq-yml 1y ago
I got sour on games for a while but I think there are good things awaiting them, because we're starting to get past the hurdle of "new technology usurps the old" actually being germane to the artistic processes that go into game design. Like, it still exists because the devices are so locked down, but it's stopped being a tech-driven business - there's little interest in AAA now, and the broader trends are shaken up too; there's more of a symbiotic pipeline of "make a game that helps people make video content" taking hold, one which has little relationship to recency or production values. That said I have been pursuing the sustainable elements of gaming for years at this point, seeing the same issues - and for me what it comes down to is what I summarize as "the terrarium problem" - the bigger the software ecosystem you build the game over, the more of the jungle you have to port to the next platform du jour. When we approach gaming as a software problem it's just impossible, we can't support all the hardware and all the platforms. But within that there are elements of "I can plan for this". Using tech that is already old is one way; Flash, for example, is emulated now. But if you go back to an earlier console generation or retro computers, you can find even more accuracy, better preservation. I took the compromise of "neo retro", since there are several SBCs around that mix old chips with new stuff - those have much more comfy specs to tinker with, while building on some old ideas. Tech that assumes less of a platform is another: I've taken up Forth, because Forth is the language that assumes you have to DIY everything, so it perpetuates ground-up honesty within your software, especially within a retro environment where there's no API layer to speak of and you have full control. And tech that has more of a standardized element is good: if something is "data structure portable", it's easier to recreate(this is why there are many homebrew ports of "Another World" - it's all bytecode). The last piece of the puzzle in it is - okay, if I take things in that direction, how do I still make it fun to develop with? And that's the part I've been working on lately. I think the tools can be fun. Flash found some fun in it. But Flash as a model is too complex, too situated in just supplying every feature. PICO-8 is also fun, but very focused on a specific aesthetic. I think it's related to data models, conventions and defaults. Getting those things right clears the way.

z3t4 1y ago

I like to start all my software projects from scratch. Everyone who are used to working on large software projects know that it's very slow. But starting from scratch is fast! You just implement the bare minimum. But also on later stages of the development when you have abstractions going, then it becomes even faster to implement new features. Working on an enterprise software project and your own engine that you've written from scratch is nothing alike, you can work 1000x faster when you have written the thing yourself and can just cut out and refactor everything you want. This is why I advocate micro service architecture and small teams. Things are much smoother when you do it yourself and from scratch. There are however landmines you have to hit and it will take years of trail and error until you get a feeling for what architecture and abstractions work and which doesn't as well as learning the in and outs of the language and platform you are working on.

leonard-somero 1y ago

I'm an indie game developer with over 10 years of experience. I'm not using Unity or Unreal, but I do have some frameworks that handle things like rendering graphics or playing audio. However, I write all the game logic, data manipulation, and entity management from scratch for each game I make. It seems to be the smoothest option for me, since I have full control over how my games actually operate, but I don't have to reinvent the wheel as far as the low-level architecture goes.

trollied 1y ago

Just to note that the author wrote this game, >3 million copies sold: https://en.wikipedia.org/wiki/Celeste_(video_game) https://en.wikipedia.org/wiki/Celeste_(video_game)

pinoy420 1y ago

[dead]

throwawayffffas 1y ago

For anything I have ever tried to make, I always find myself fighting the engine. Whether it is Godot, Unity or Unreal. They all feel like a ready made game that you add assets and mod. The problem for me is that I mostly don't want to make that game. An analogy that comes to mind from the web dev world, it feels like the engines are like wordpress. Prebaked and ready to show content, but the moment your objective does not completely align with their preconfiguration you have to do a huge amount of hacking and workarounds.

moron4hire 1y ago
Exactly. If you want your game to look exactly like every other game on Google Play, complete with all the same, long, janky splash screens and rendering hitches and slightly screwy text rendering and random audio glitches, use Unity. All that might be acceptable for an adware befouled "idle RPG" style game on mobile (and they're all that kind of game these days). But it really galled me that people were using Unity so heavily for VR. It's extremely difficult to get a Unity game to work well on the standalone VR headsets. To hit the performance targets required by the Meta Quest Store, you really have to rewrite large portions of the engine to get around the fact that Unity is a disorganized, single-threaded, allocation-happy mess. If you want your game to be a quality piece of software, you can't start with a garbage as your foundation.
- MattRix 1y ago
  There are games in many different genres, many different aesthetics, many different amounts of polish, and many diffrent levels of performance… all made with Unity. It’s true that they provide a bunch of baseline stuff so that low effort games look and feel similar, but it’s not that hard to end up with game made in Unity that feel unique.
ivanjermakov 1y ago
What adds oil to the flame is a bunch of "game templates" that you can buy and make your own game just by replacing the title screen and some models. E.g. https://assetstore.unity.com/packages/templates/systems/store-simulator-supermarket-game-template-309463 https://assetstore.unity.com/packages/templates/systems/stor... And if you open Steam games and go to the newest, you see that nearly half of the releases is some version of a generic Unity/Unreal template game in a slightly altered "skin": https://store.steampowered.com/app/2488370/Cash_Cleaner_Simulator/ https://store.steampowered.com/app/2488370/Cash_Cleaner_Simu... https://store.steampowered.com/app/2073910/A_Webbing_Journey/ https://store.steampowered.com/app/2073910/A_Webbing_Journey... https://store.steampowered.com/app/3498270/Better_Mart/ https://store.steampowered.com/app/3498270/Better_Mart/ https://store.steampowered.com/app/2625420/Drive_Beyond_Horizons/ https://store.steampowered.com/app/2625420/Drive_Beyond_Hori... https://store.steampowered.com/app/3163790/Toy_Shop_Simulator/ https://store.steampowered.com/app/3163790/Toy_Shop_Simulato... https://store.steampowered.com/app/3023600/Horse_Farm_Simulator/ https://store.steampowered.com/app/3023600/Horse_Farm_Simula... https://store.steampowered.com/app/3124550/Liquor_Store_Simulator/ https://store.steampowered.com/app/3124550/Liquor_Store_Simu...

russellbeattie 1y ago

So, does everything he said about C# sound about right? I have no real desire to use it, but I'm curious if his opinion was more or less accurate. Not looking for a flame war, just knowledge

orthoxerox 1y ago
Yes, C# has had low-level primitives since 1.0 and it has only gotten better in this regard. This means that it's worse than Java at things like devirtualizing calls, but you can write allocation-free hot loops in C# these days. It's also cross-platform and has multiple deployment modes: you can ship the runtime and the program separately (good when you control the end-user machines, like in an enterprise settings), you can tree-shake the runtime and ship it with the program, or you can tree-shake the runtime and use the AOT compiler to ship a go-like native binary. The JIT compiler is still better for long-running processes like servers, but for one-shot programs where the startup time is critical, like CLI tools and FaaS, the AOT compiler is really great.
- bscphil 1y ago
  > you can tree-shake the runtime and use the AOT compiler to ship a go-like native binary. The OP talks about doing this for mobile platforms, but could I take e.g. the OP's source code (he co-wrote Celeste) and trivially compile an AOT native binary for x86_64, or would more work be required to make that possible? (Interestingly, Celeste on Linux doesn't use the dotnet runtime, but instead a portable Mono runtime which I believe is based on MonoKickstart. [1]) [1] https://github.com/flibitijibibo/MonoKickstart https://github.com/flibitijibibo/MonoKickstart

varbhat 1y ago

Isn't that a huge effort? I remember few games which developed their own game engines from scratch (factorio, limbo, bg3). But, wouldn't it be easier and better to use game engines like godot?

OnionBlender 1y ago
I suppose it depends where you draw the line between engine and framework. Factorio used parts of Allegro until 2018. https://www.factorio.com/blog/post/fff-230 https://www.factorio.com/blog/post/fff-230
- 3036e4 1y ago
  Engine these days implies one of those IDEs with everything included (scene editor etc). I don't know how or why, but language drifted in the last 20 years or so.

lucraft 1y ago

Maybe a dumb question, but what is the C# compiler and runtime that you use? I used to be up to date with .NET and Mono and stuff but I'm 10 years out of date

kkukshtel 1y ago
Modern .NET/C# is cross-platform by default (CoreCLR runtime). You don't need Mono anymore.
OnACoffeeBreak 1y ago
I am not at all familiar with C# development, but the author mentions Native-AOT, which, from a cursory look, seems like a C# compiler. https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

tiniuclx 1y ago

That was a very fun read! While I’m using Godot for my hacking simulator game, Botnet of Ares [0] I think the native C# approach is very much justified in this case, and Noel clearly has had massive success with Celeste. I like Godot because of the UI primitives built into the engine. For a UI heavy simulation game like mine, the game engine does a lot of the heavy lifting. Sure, I don’t use 90% of the 2D/3D features of the engine, but that’s okay. [0] https://store.steampowered.com/app/3627290/Botnet_of_Ares/ https://store.steampowered.com/app/3627290/Botnet_of_Ares/

deepfriedrice 1y ago
Oh wow - I wanted to build a game just like this not too long ago but never found the time. Wishlisted!

kkukshtel 1y ago

I agree with a lot of this, and am similarily working on my own code-only C# game framework meant as a spiritual successfor to XNA/Monogame (using Sokol instead of SDL): https://zinc.graphics/ https://zinc.graphics/ In OP's post as well he brings up some of the main factors that make modern C# incredible: - Cross platform development (and runtime). - NativeAOT Compiling (great for consoles, provided you have backend headers). - Native Hot-reloading. - Reflection I'd also add: - Source Generators Modern C# is incredible. I think people still discount it due to its admittedly bad legacy, but the past five years of C# and CoreCLR development make me feel like it's truly a language that has everything necessary but isn't baroque or overburdened. My only major request, Union types, is also in proposal and will (hopefully) come in the next year or so: https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md https://github.com/dotnet/csharplang/blob/main/proposals/Typ...

w4rh4wk5 1y ago
Out of curiosity, do you have some pointers for getting into C# for these kinds of projects? I've only used C# for standalone win32 applications and inside of Unity. I am familiar with low-level game engine stuff in C/C++, but always discarded C# as not being viable for cross-platform projects (as in game consoles). Guess I was wrong. :)

OnACoffeeBreak 1y ago

The author says that they tend to load all of the assets on init. This sidesteps the issue of the C#'s garbage collector (GC). I am not a C# developer, but seem to recall reading that GC can cause unexpected slow downs. Web search shows articles on tips and tricks for optimizing GC in C#, so it seems like a real issue. Does anyone have any first hand experience they would like to share? Is it easy to avoid the GC slowing down your game unexpectedly? Is it only a problem for a certain class of games?

Const-me 1y ago
There’s a recent promising development relevant to the GC pause issue. It seems couple weeks ago some smart developer working for Microsoft has made a version of GC called “Satori” which pretty much solved these GC pauses for many real-world use cases. An overview article: https://blog.applied-algorithms.tech/a-sub-millisecond-gc-for-net https://blog.applied-algorithms.tech/a-sub-millisecond-gc-fo... Long discussion thread with many graphs with measurements: https://github.com/dotnet/runtime/discussions/115627 https://github.com/dotnet/runtime/discussions/115627 I don’t yet have hands-on experience with that Satori GC, though.
jayd16 1y ago
In a game like the author's where you just init/pool everything on load you can simply disable the garbage collector during gameplay.

TacticalCoder 1y ago

[dead]

JKCalhoun 1y ago

This is basically what I did a couple years ago [1]. SDL2 and a bit of C++ to create a "sprite" class. Some collision code in the sprite class... If you want to call what I added an "engine" it was more like a pedal-assist bike. Too often I find "engines" end up driving the project/game. That is, you end up writing the game to the engine. It's why I've avoided Unity, etc. — high-level engines like that seem to guide you to writing the same game everyone else is writing — just with different assets. Never mind you spend too much time, in my opinion, learning the engine and not getting the game written. To be sure there was a learning curve just pulling in SDL, but the curve was slight and it seemed more universally useful to know SDL as it can be employed in other cross-platform projects I might undertake — not just games. [1] https://store.steampowered.com/app/2318420/Glypha_Vintage/ https://store.steampowered.com/app/2318420/Glypha_Vintage/

symfoniq 1y ago
Just wanted to say that I remember playing your game as a kid on the family Mac IIci. Thanks for the fun memories, and best wishes.

gr4vityWall 1y ago

That was a great post. I had no idea modern .NET had hot-reloading built-in like that. From my experience programming games, that's the biggest time saver you can ask for. Does it work well (or at all) with Godot/C#? A few years ago, a notorious developer in the GameMaker community wrote a tool that added live reloading to it, and immediately it got widely adopted by big projects. In terms of prototyping, I think an 'ideal' engine for extremely fast iteration would be something like GameMaker 8.1, but with hot reloading and slightly better window management inside the editor itself. I don't share the core needs of the author though, I prefer using an engine with a built-in editor, specially in the beginning of a project. I really wanted to like Godot, by the abstractions it provides never 'clicked' with me. I can't think of a game like a bunch of nodes. That's unfortunate for me as Godot it the most popular free game engine AFAIK, with all the goods that comes with that. I also really don't want to spend years mastering a proprietary tool again.

tigerlily 1y ago
> That was a great post. I had no idea modern .NET had hot-reloading built-in like that. I fully concur, that was a great post. And on full time Linux, just incredible. Definitely it's given me the itch to try a few new things :)

EdgeCaseExist 1y ago

That's kind of an engine though ? An engine is just a bunch of low level types, DS, algos that go onto build mid level abstractions that go onto form systems. In this case you can argue the game itself (aka the runtime) is the game engine? As others say, getting data (Assets) in/out of the engine is the hard part. Especially as they are the real contribution to the shipped game been so large (unless smart compression, delivery optimisation is used, sadly not common).

Fokamul 1y ago

Good example of game with custom game engine is Factorio. They also documented their development a lot on their website and I think they have no problem to answer anything regarding developing own engine in their forum.

enbugger 1y ago

Game engine is an art tool in the same way like Blender or Photoshop are. You have to learn its tips and tricks the same way artists do. Usually programmers consider anything that does not have a dedicated UI as fatal flaw hence all the bias towards big engines. For example, you want to make and thumbnail picture of a 3d model/character. My first thought as a programmer on "correct" approach to that in UE was like well I need to setup a separate world with brand new lightning and have some renderer features off. The perfect "hack" for this is to have a separate "dressing room" under the level where the model teleports into and then back during single frame. Hundreds of such nuances can be only learned.

codeproject 1y ago

there is a minor mistake in this.." their minds jump to what it looked like circa 2003 - a closed source, interpreted, verbose...", C# was never interpreted. From the beginning, C# code has always been compiled to Intermediate Language (IL), which is then JIT-compiled by the .NET CLR at runtime.

dragonwriter 1y ago
To be fair, “compiled to bytecode which is JITted af runtime” is pretty common of lnaguage implementations described as “interpreted”, like CRuby.

curtisszmania 1y ago

[dead]

deleted 1y ago

[deleted]

nico 1y ago

And now you can also just vibecode little games and start having fun right away, they are great for kids https://rosebud.ai/p/800a3295-ea07-4c80-a4f1-10fd8db24088 https://rosebud.ai/p/800a3295-ea07-4c80-a4f1-10fd8db24088 https://openjam.ai/lonely_ant_702/v3nyt4if54 https://openjam.ai/lonely_ant_702/v3nyt4if54 https://rosebud.ai https://rosebud.ai https://openjam.ai/ https://openjam.ai/

jagger27 1y ago
Why should less thought be put into things made for children?
- nico 1y ago
  Why do you think vibecoding and learning together with kids is putting less thought? However, kids don't care too much about thought. They care a lot more about attention and fun With these tools you get to the fun part faster and can give them a lot more attention You also get to co-create with them and they get to express their creativity seeing results in realtime

msephton 1y ago

I use Lua & Love2D to make games with a similar ethos. Being able to set my own constraints is fun, and that's what game dev is about for me. As soon as something stops being fun, I know I'm doing it wrong and there must be a better way. My game YOYOZO is a tiny 39KB but made it to Ars Technica's "Best Games of 2023" list alongside heavyweights like Super Mario Wonder and Tears of the Kingdom! https://news.ycombinator.com/item?id=38372936 https://news.ycombinator.com/item?id=38372936

hbn 1y ago
Hey I recognize that game, great work! I've had my Playdate for a couple years but it was only this past weekend I finally got inspired to start playing around with the SDK like I've been telling myself I would since I bought the thing. I had never used Lua prior to now so that's also part of the learning experience. I'd really like some strong typing and some other language safety features, but it's good for what it needs to do. So far all I've made is a little tech demo of text that rotates around in fake 3D space in relation to the crank, like the iOS options picker. Clip here: https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a The other thing I learned from this project is I forgot more trigonometry skills than I thought in my years of CRUD/webapp development. One of the best things about developing for Playdate is how freeing it is to have a fixed canvas that you're drawing to. I'm so used to having to make all my UIs responsive, I love being able to just position something at a pixel value and know it'll work on everyone's device.
hernandipietro 1y ago
Congratulations man, great work.
- msephton 1y ago
  Thanks so much, it's appreciated.

VikingCoder 1y ago

Please help me figure out the best way to share code between Github repositories... I love C#, and I acknowledge Github as the king of source control. I make a new Repository a couple times a week, and use Visual Studio Code to clone it, and open a terminal and "dotnet new gitignore" and then use dotnet to make new projects all over the place... On multiple machines, even. On a VM on my NAS. On my Windows machine. On my Windows laptop. On a VPS. And I'm happy. But how in the holy hell am I supposed to share code from one repository to another? I want to make VikingCoderLib as a C# library (classlib), and drop in all of my favorite Extensions for generics and strings, and etc. And then make another classlib for some of my Protocol Buffer utilities. And another classlib for setting up a terminal.js console for an app. And... What's the best way to do that? Submodules? They really seem to suck. I can't easily make changes here, and use them there, without it being a huge pain in the rear. Am I doing this wrong? Am I missing something?

wsc981 1y ago
I don't mind submodules much. I mean when I first used them I thought it was sucked, but now I use it all the time for personal projects. I like to make small Lua libs or fork existing Lua libs and include those in a lib directory in my LÖVE / LÖVR projects. Works fine for me. Perhaps the only thing that sucks a bit about submodules, might be if you work with multiple people and some reference of a submodule is updated and you need to go into the submodule directory to update the reference locally. But I think that's the only thing, no big deal. I don't think you deal with this issue much when you work by yourself on a solo project, on a single machine.
coffeebeqn 1y ago
Monorepo?
- VikingCoder 1y ago
  I hate that you're almost certainly right. It feels like there should be a good way to have a dotnet classlib in one repository, and use it from others, but it just doesn't feel like they fit together the way they should.

orthoxerox 1y ago

A lot of the time the indie game developer is a former professional programmer. This of course affects how they interact with the game development process. Someone who's coming from a different walk of life (say, an artist or a TTRPG designer trying to make a game) will obviously be much more productive with an off-the-shelf engine like GameMaker or Unity. They accept the engine with its editor as the only way to make a game and get cracking. A programmer opens the editor and is presented with the 3D scene editor. "Nonono, where's main()?" they immediately ask. "Why is there a 3D scene editor if I want to procgen my levels?" "How do mods work?" "Who told you I needed physics simulation in my game by default?" "Running the game inside the editor is cool and all that, but I'd rather run the editor inside the game."

Lichtso 1y ago

Made me realize that most of the games I really enjoyed have their own custom engines (made for a single game or franchise): Starbound, Stardew Valley, Minecraft, Factorio, RollerCoaster Tycoon, Empire Earth, The Sims, Project Zomboid ... Only exception might be Portal, but even that is using an in-house solution mostly for developed for one franchise. Like with most things: If you are new and have to learn everything or if you actually need to pump titles out you should prefer quantity over quality and the major game engines are the way to go. But, if you really want to polish something it will require a long long time and then investing in engine development can pay off. The trap is starting with the later if you haven't made a few dozen games yet and never shipped anything. Then it will stay that way.

jebarker 1y ago
Just to clarify, are you saying that if you've never shipped any games then you should start with an established engine and only go artisanal once you have that experience?
- Lichtso 1y ago
  Yes, pretty much. I don't say the custom engine first path can't work, heck I did ship my own games on custom engines first myself, but it is probably not the path of least resistance.
dismalaf 1y ago
This... I don't think I've ever truly enjoyed a Unity game. Maybe KSP, but it runs like shit and isn't a good advertisement for that engine. Even Unreal Engine: I've only enjoyed Unreal itself.
- bscphil 1y ago
  There are definitely some Unity games I've really liked - the Ori games, Hollow Knight - but the engine has never been a positive of my experience with the game. They're full of jank and physics bugs, and in a weird hard to describe way kind of feel "alike". You know you're playing a Unity game, which is bizarre for a part of the game experience that's so low level.

doawoo 1y ago

I always saw it like this: - If you're building an engine without a game in mind, you're just going to end up with tools you don't use. - If you have a game you want to see to the end, and make an engine for it, you're going to build exactly what you need and nothing else. With the bonus of having lots of code you can reuse for the next project. All that said I'm sticking with Godot since I have limited time, and if I want to bang out a quick gameplay idea to see if it even works, I don't want to start from nothing. (I say all this after building a 2.5D-ish engine with c# and monogame)

RyanOD 1y ago

As a "for fun" side project, I've started building clones of retro classics in Pygame as a way to help beginners gain knowledge of procedural game dev fundamentals. Python seems like a nice entry point and Pygame works well for the 2D classics like Frogger or Defender or Dig Dug or whatever. It's a lot of fun, but, woah! It's a lot more work than I was expecting.

hannofcart 1y ago

From the limited game dev experience I have/had, my recommendation is to introspect whether building the tech is just fun escapism from working on the really hard part of game dev: designing something that's really fun to play. Building your own engine may "feel" like progress but it isn't. A fun game loop implemented with the most rudimentary frameworks, (or sometimes even pen and paper!) is more valuable than just a fancy custom engine implementation without a fun game mechanic. Very often I find some friends of mine still in gamedev getting sidetracked by the intellectual stimulation that building tech gives them (because they are programmers) and burn out before they actually design/discover a fun game mechanic that they can actually ship a game with. All this is ofcourse assuming you want to make money off your game. If you are just having fun with a hobby project or doing it to hone your programming skills, go nuts with the custom game engine code; more power to you!

ccvannorman 1y ago

Game dev here, building a game using the "engine-only" version of PlayCanvas (a 3d engine). Asset loading, rendering, physics, object management, update loops, raycasting is all handled by the engine (js). My code is everything else, including a low-tech drag and drop scene editor. I've got to say it's the deepest I've ever been in the abstraction stack for building a game. I have to hand build everything. I definitely wouldn't want to write engine code itself unless I was building an engine; building a good engine takes heaps of engineering and time which I don't have. I will say though, I absolutely love the level of fine control I have over every aspect of my game (when compared say to a Unity game or even a PlayCanvas game built by their editor).

BryanLegend 1y ago

Hate to be mean, but this guys last game was a complete failure after multiple years of development: https://www.exok.com/posts/2025-01-22-earthblade-final-update/ https://www.exok.com/posts/2025-01-22-earthblade-final-updat...

hbn 1y ago
That's not a failure, it was just never finished. And more because of personal matters than anything technical. I'm not sure why this is relevant.
- BryanLegend 1y ago
  Of course it was relevant. If they had a better game engine it would have been further along.
  - filleduchaos 1y ago
    They didn't need "a better game engine" to create Celeste.
  - hbn 1y ago
    The article you yourself linked says the game's development troubles were from pressure to surpass their previous game which was a smash hit. How would a better engine fix that?

bitwize 1y ago

If you're serious about making video games, you should probably be using a commercial engine. Period. No exceptions. Unless you're EA or Microsoft, you're just not going to develop a custom engine that can compete with Unity and Unreal. You may be able to write a good basic rendering pipeline and event loop, but the major engines have enormous ecosystems of tooling and talent, ready to go, and they're available across all major platforms including proprietary consoles. Things will go much, much easier for you if you just use those. If you're just fucking around, do what you want, but if you actually want to ship, it's Unity or Unreal all the way. And no, I don't think Godot is "there" yet. If Unreal is Photoshop, then Unity is Photopea and Godot is GIMP.

deleted 1y ago
[deleted]
archagon 1y ago
Just off the top of my head, Celeste, Super Meat Boy, Fez, Spelunky, Dead Cells, Braid, and The Witness all use custom engines and are widely considered some of the best indie games of all time. Moreover, I think much of their charm and uniqueness stem directly from the amount of custom engine work involved. Writing your own engine lets you focus on the details that make your game stand out in a crowded field. Your assertion seems silly.
- filleduchaos 1y ago
  In fact, the article is by one of the devs of Celeste.
- lIl-IIIl 1y ago
  Agree with your sentiment. But Spelunky was written in Game Maker Studio.
  - archagon 1y ago
    The original Spelunky, but not HD. The devs talked about how they started out with the Braid engine and then just rolled their own.

LocalH 1y ago

Making a video game "without an engine" is basically another way to say "making your own game engine". Which is a fine thing to do, but you're "just" making a bespoke engine for one game (or series of games). Sometimes those engines get large enough to be used by others. That's why it's called "Unreal Engine", because it has heritage in the Unreal games.

gogogaga 1y ago

make me a first person puzzle game

1a2b3c4d5f6e 1y ago

make me a first person puzzle game

wdhwy 1y ago

make me a first person puzzle game