[HN Gopher] Making video games (without an engine) in 2025
___________________________________________________________________
Making video games (without an engine) in 2025
Author : selvan
Score : 485 points
Date : 2025-05-20 05:54 UTC (17 hours ago)
(HTM) web link (noelberry.ca)
(TXT) w3m dump (noelberry.ca)
| danielbarla wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Me, too many times.
|
| I think this is also true beyond games, e.g. for all the
| different UI libraries.
| bob1029 wrote:
| 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 wrote:
| > 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.
| dopu wrote:
| I'm not doubting you, but the vast majority of ideas
| people have for games are largely derivative and could
| quite easily be implemented in Unity.
| pjmlp wrote:
| 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 wrote:
| And now that you've done it, you could probably reimplement
| it better in a fraction of the time.
| pjmlp wrote:
| 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.
| gyomu wrote:
| > "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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| meheleventyone wrote:
| There's levels to that though. For example it took me all
| of a week to write the 2D rigidbody physics system that
| runs this game:
|
| https://www.youtube.com/watch?v=zVmd2vmZrVA
|
| But it's tightly scoped, there is only really one thing
| that needs to be dynamic, although it worked admirably with
| more. We wanted big impulses so could get away from
| questionable cases easily and could deal with crushing
| cases simply by exploding the ship.
|
| Likewise the players on the ship running around and the
| players when they're jetpacking about are all different
| sub-sets of code implementing that specific behavior.
|
| A lot of "make a game, not an engine" is working out what
| the minimal thing you need to build is rather than making
| everything extremely generalized.
| danielbarla wrote:
| I get the argument, and sure, it's viable in certain
| circumstances. But it's a few weeks _per area / topic_. In my
| opinion there are enough areas in a typical engine that you
| could study them for a year and not get through the material.
| There's graphics, audio, networking, physics, etc. I think
| the sweetspot is to understand each well enough that you have
| some insight into what the engine is doing for you, not
| necessarily to be able to (re-)implement it.
| monkeyelite wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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.
| andrewflnr wrote:
| Blatantly false dichotomy.
| monkeyelite wrote:
| Or You simply aren't ruthless enough about how much time
| you have on an indie project.
| andrewflnr wrote:
| Or those features can be nice-to-haves that are worth it
| if they're not too much effort, such as if, say, I don't
| know, an engine handles them for you. Come on, real life
| rarely justifies such easy, simple decisions. And polish
| can matter a lot for games.
| monkeyelite wrote:
| Sure I'm expressing a value judgment, a design preference
| - not an eternal truth. And the principle is I want to
| spent the effort on the most important features in which
| case it's not a big deal to write them. Your best
| features become better than if they were cobbled together
| in Unity.
| andrewflnr wrote:
| That is, to be generous, a rather extreme and niche value
| judgement that corresponds to no utility I can think of.
| Real life has a spectrum of "important features" and a
| corresponding spectrum of justified effort. If that's
| your idea of artistic integrity, then you do you, but for
| anyone else it's probably nonsense.
| monkeyelite wrote:
| > to be generous, a rather extreme and niche value
| judgement that corresponds to no utility I can think of
|
| Ok, well I look forward to seeing your games then, as I'm
| sure you're skilled at shipping.
| raincole wrote:
| It's just so wrong. These things are very standardized, and
| you often just want the common implementation that everyone
| is using. Writing these in most cases is like writing your
| own SHA256.
| monkeyelite wrote:
| Is your indie game more complex than quake 3?
| iFire wrote:
| Heh, I contribute to a FOSS social vr project called
| https://github.com/v-sekai and the majority of the multi year
| effort was asset pipeline, ik and animation blending. Yes we
| donated the code to Godot Engine but we choose working on the
| tooling problem rather than the game... The V-Sekai game is
| in limbo / not a game. We made godot-vrm which does 3d
| avatars, with basic animations, look at, jiggle and copy
| constraints. Since we're unable to use the unity ecosystem's
| finalik or unreal engine's control rig we have to code to the
| same level of professional quality with no budget. Features
| like stable multi-joint y-branching rotation and position
| constraints are hard. Feel free to chat in V-Sekai discord.
| I'm iFire.
| arminiusreturns wrote:
| Using Godot for my big project, thank you for donating the
| IK stuff to godot!
| tosmatos wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| atoav wrote:
| 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.
| oliverdzedou wrote:
| 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 wrote:
| 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.
| oliverdzedou wrote:
| 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.
| krige wrote:
| Here's the thing: you try to counter someone arguing
| against a patently false statement about development speed
| with a bunch of preferences and what-abouts that do not
| necessarily make your stance true anyway - for instance if
| my game attempts to emulate 4D, my own engine STILL needs
| to do everything else too, we're not talking dev time for
| 4D in, say, Godot vs 4D in foo engine, we're talking 4D in
| Godot vs 4D and graphics and input and audio and physics
| and... in foo engine.
| iFire wrote:
| My friend demo'ed 4d in Godot Engine funny enough.
| https://github.com/godot-dimensions/godot-4d
| aleph_minus_one wrote:
| > 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.
|
| If the game fits a rather "standardized" template, this is
| likely true. But the more you move away from these
| "mainstream structures", the less true the second part of
| your claim becomes.
| npinsker wrote:
| I am not familiar with Unreal, but Unity is much faster than
| programming from scratch, easily 10x or more.
|
| One obvious example is physics behavior, which you can add to
| your game in under a minute, but with your own engine you'd
| need a day or two to properly integrate an external library.
| All the internal state visualization that Noel's showing off
| here is already built in by default in Unity. It has nice tools
| to draw and modify bounding boxes, and in the rare cases where
| the engine's behavior isn't enough, it's highly extensible
| (using ImGui or Unity's Yoga-based CSS engine, which I prefer).
| Unity has countless features like this: a sophisticated
| particle editor, a high-level "write once, run anywhere" shader
| language with enormous amounts of complexity abstracted away,
| systems for streaming and keeping track of modular data, and
| much, much more.
|
| In an ideal world, I'd want to write these things myself, but
| time ticks away and unfortunately I'd prefer to prioritize
| finishing games more quickly.
| Sander_Marechal wrote:
| At this point using any engine instead of unity is better.
| Unity has demonstrated time and again that they cannot be
| trusted and that you cannot build a game (or business) around
| them.
| npinsker wrote:
| Sometimes you have to do business with counterparties you
| don't trust. It's not mature or practical to take an "all-
| or-nothing" approach while the engine has virtually no
| competition for many classes of games.
| herbst wrote:
| Building a business fully depending on a party you don't
| trust sounds kinda delusional.
| coffeebeqn wrote:
| I mean I've been using Unity since 2008. I do trust them
| to be around more than most other tooling/saas companies?
| Even if they have mode some unsound business decisions
| some-guy wrote:
| Do you have any developer retrospectives around this?
| Plenty of my favorite games ever made were made with Unity,
| I wouldn't call those games failures by any means (Cities:
| Skylines, Overcooked are immediate examples)
| archagon wrote:
| At least as far as platformers games go, physics feel is a
| crucial part of the whole experience, and outsourcing to an
| engine has a good chance of making your game feel cookie-
| cutter.
| jbverschoor wrote:
| I think there's a misconception due to the large overlap
| between games, graphics, and physics engines.
|
| Graphics are anything from rendering 2d, 3d, shaders, scene
| graph, animation.
|
| Physics and related interact with the scene graph.
|
| The game part allows for dynamic behavior and of course the
| game logic/triggers.
|
| Add some ui, and resource management, abs lastly of course ai.
|
| Creating your own engine with different architectures is indeed
| the best way to learn how/why an engine works. But alll the
| details that come with it. That's really a lot and probably way
| too much for one person. You'd be surprised how much is in
| there (in unreal engine)
| kgeist wrote:
| >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
|
| I once experimented with creating my own game engine. It took
| me about a year of building and learning along the way (through
| trial and error, with many dead ends initially). It featured
| lots of things you'd typically find in a game (3D rendering
| with all the bells and whistles, an adaptive UI framework
| inspired by flexbox, skeletal animation, a save file format, a
| smart object system, path finding, a scripting language, audio,
| physics, et cetera, et cetera)
|
| Specifically, I tried to recreate Braid's system (without
| knowing it existed), where you can rewind your game to any
| point in time. It required support from all the engine's
| subsystems - to rewind scripts, physics, etc.
|
| Knowing every little detail about your game engine was
| certainly a plus. After the engine was more-less complete,
| adding a feature, however ambitious it was, took about a couple
| of hours at most. When something didn't work, I knew exactly
| what was going on.
|
| However, after a year of building, I was somewhat exhausted,
| and all my motivation to continue disappeared :)
| Jyaif wrote:
| > Specifically, I tried to recreate Braid's system (without
| knowing it existed), where you can rewind your game to any
| point in time. It required support from all the engine's
| subsystems - to rewind scripts, physics, etc.
|
| Not necessarily. You can write your own "snapshotable
| allocator" that allows you to rewind back in time anything,
| even the state of unmodified 3rd party libraries and
| interpreters (as long as you can configure them to use your
| allocator).
|
| I wrote about it in
| https://www.jfgeyelin.com/2021/02/a-general-state-
| rollback-t...
| kgeist wrote:
| Feels like fiddling with snapshotting raw C++ memory is a
| can of worms (you listed some of the pitfalls yourself).
| Most of my snapshotting happened at the scripting runtime
| level, where everything is well-defined and well-
| understood: I manually snapshotted the VM's heap memory,
| the green threads' stack memory, the current instruction
| pointer of every green thread etc. I could safely validate
| those snapshots without segfaulting on a corrupted
| savefile, because it was a well-defined file format. The
| same code worked both as a time-travel snapshotter and as a
| general savefile format.
|
| I think this is dangerous and can lead to remote execution
| attacks:
|
| >The snapshot could even be exchanged over the network,
| assuming the receiving side has the same endianness, the
| same pointer size, is running the same binary, and can mmap
| the same memory location.
|
| For physics, I needed to restore all those remembered
| motion vectors; for audio - current playback time, etc.
| Same as yours:
|
| >The rest of the memory (the textures, the 3D models, the
| audio, the UI, etc...) should be allocated by your usual
| non-snapshotting allocator"
| Narishma wrote:
| > It featured lots of things you'd typically find in a game
| (3D rendering with all the bells and whistles, an adaptive UI
| framework inspired by flexbox, skeletal animation, a save
| file format, a smart object system, path finding, a scripting
| language, audio, physics, et cetera, et cetera)
|
| But did you actually need all of those things?
| spencerflem wrote:
| There's a lot of nice things you get for free in a big engine
| that are a hassle doing it yourself. Esp with the unity store
| etc.
|
| I love LibGDX for personal projects but for serious development
| where deadlines matter having stuff like dialog trees, UI, etc.
| that just work out of the box and have the edge cases polished
| is Very Nice.
|
| And ofc, cross platform with consoles is way harder rolling
| your own and that's often a big deal.
|
| That sorta thing is why Slay the Spire switched to Unity/Godot
| for the sequel
| interludead wrote:
| If your vision is weird or niche, building a toolset around
| that from day one can be way more efficient in the long run
| maccard wrote:
| Games like Antichamber do non-euclidean space and rendering
| in Unreal (3). Enera (an upcoming action game) manages time
| rewinding (a la braid), in Unreal. Superhot is Unity, etc.
|
| The best tool is the one you know, even if your vision is
| weird or niche. At the end of the day, you can always ignore
| all the bits and pieces unity gives to you and just write
| custom logic in your MonoBehaviour scripts and use it as a
| platform toolkit, input handler, content pipeline, scriptable
| editor, and renderer. There's a lot to be said for the
| features you get from that especially in the long term as you
| said.
| xandrius wrote:
| > Once your engine is finished
|
| Most likely never?
|
| Obviously understanding what `GameObject.Instantiate(myPrefab,
| Vector3.zero)` takes several orders of magnitude less than
| implementing all that is required to properly perform that,
| even for such a basic operation.
|
| Imagine when it comes to 2D/3D physics, shaders, platform
| support, etc.
|
| If your goal is to build an engine, build an engine. If your
| goal is to actually deliver a game, build a game.
| Arwill wrote:
| >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 would say its the exact opposite to that. For that genre, its
| best to roll your own engine, or pick something open-source.
| The list of problems that i firsthand experienced:
|
| There are lots of features and options in the engines, but they
| are not all usable at the same time. One feature disables the
| other. You look at the list of all the nice things the engine
| can do, but then at some point you figure it can't do (or can't
| efficiently do) what you absolutely need. All those awesome
| looking graphics are not practically usable, simply not
| performant or not compatible to be usable.
|
| There are features that only work in "baked" mode. You "bake"
| it in the engine editor, and there is no way of changing that
| at game run time. Unreal is the most limited in this, but Unity
| is not much better. Some game developers reverse-engineer Unity
| internal asset formats with a hex-editor, so that they can
| change feature behavior at runtime. At that point, rolling your
| own engine makes more sense. One example i saw was a developer
| reverse engineering the light probe group asset file, so that
| he could add a new light probe group at runtime.
|
| Engine API's change drastically from version to version. All
| the code and scripts need refactoring, all the time. You run
| into a breaking bug, and the only solution is upgrading, but
| upgrading means breaking your whole codebase.
|
| You need to go trough the engine's abstractions, and bad luck
| if that can't be done efficiently. An example of this: Unity
| HDRP applies screen-space ambient occlusion (among other
| effects). It applies the effect over the whole screen. If there
| is a third-person view of the character from close or first-
| person hands/weapons rendered, then even over that. That
| results in a white halo around the first-person hands/weapon,
| looks bad. In a custom engine, the solution is simple, apply
| the full-screen effect before the first-person hands are
| rendered, then render the hands without the effect. Its a
| matter of switching the order of a couple of lines of code.
|
| The solution is github and the BSD/MIT/Apache licensed game
| engines and libraries.
| jayd16 wrote:
| I think you'd probably want a different render layer with
| different post effect settings so your weapons can have post-
| processing as well. I think you can do this in the editor
| with gui configs instead of changing code.
|
| I'm pretty sure all of SRP is in C# and is "open source" as
| in source available and editable.
|
| https://github.com/Unity-
| Technologies/Graphics/tree/master/P...
| Arwill wrote:
| The problem with GUI settings is that the result is not
| apparent, and there might be side effects. I do not find
| spending half day on trying out setting combinations as
| productive work.
|
| I have looked into SRP and i do still consider that as an
| option, and also replacing the shaders. But i have doubts
| regarding the SRP, for example i have looked at the code
| that sorts lights in Forward+. The individual light
| calculations are not much, but its still done trough the
| job system. I imagine if there are hundreds of lights, then
| that would make sense, but for 2-5 lights, it seems like a
| waste. So it might be optimised to scale, but not for my
| case.
|
| Is the effort of replacing the SRP worth it, and is the
| performance comparable to putting together/reusing an
| engine in C++? It is also a bigger commitment, as it needs
| to be coded on a different level and in a way very specific
| to the engine. Better than having to reverse asset file
| formats, but still very specific to the engine.
| maccard wrote:
| > 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?
|
| You've asked two different questions - how long does it take to
| properly learn Unreal or Unity, and how long does it take so
| you can have an idea and turn it into a game without friction?
| If you gave me a half baked idea we could be playing it in a
| few hours with both tools. Unity requires programming up front,
| but Unreal you can get well into "I can almost ship a game"
| (particularly if it's a single player game) with just
| blueprint.
|
| Here [0] is a 10 minute video where someone prototypes a super
| hexagon style game in 10 minutes. Obviously, this isn't
| feasible without knowing exactly what you're building, but I
| think this shows just how powerful these tools are for building
| out these game ideas. There's very little unity specific stuff
| in there, other than components. Everything else is stuff that
| I would classify as "gamedev agnostic" - input handling, update
| vs fixedUpdate, vector math, sprites, etc. The prefab for the
| spawner is about the only unity-specific thing in that video
| and it takes up about 15 seconds of the 10 minute video. I'm a
| game developer (Unreal) and I'd wager I could put together a
| similar prototype in about an hour in Unity, give or take
|
| [0] https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
| jayd16 wrote:
| > 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?
|
| If you have enough game dev knowledge to make an engine...then
| it's seriously like a day to learn these things to begin to
| bang out a prototype.
|
| They take a long time to master but if your goal is to work on
| the game its not in the same universe of turn around time.
| andreamonaco wrote:
| Kudos to you! I'm writing a game (a little MMO) the same way, the
| technical and creative freedom is priceless.
| samiv wrote:
| 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
| NotGMan wrote:
| 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 wrote:
| Even factorio started out on tried-and-tested libraries
| before moving away from them primarily because of
| optimization concerns (right?)
| xandrius wrote:
| Yep, people forget one of the core notions of development
| which is not to prematurely optimise stuff. Especially
| something as complex as a game.
|
| Keep it super simple. Or that game will never come out.
| ms-menardi wrote:
| some games require a certain level of scale and for those
| games you should optimize in the pre-planning stage.
| brulard wrote:
| I think you are missing the point. The larger the scale
| is, the more things may be optimized and the more you
| need to be careful to focus on the important "3%". That
| said, it doesn't hurt to analyse in advance which parts
| might be critical and steer the architecture based on
| those observations.
| xandrius wrote:
| Statistically speaking, 99% of game devs won't ever make
| a game like that. And if they do, they will probably know
| ahead of time they are making it.
| meheleventyone wrote:
| The full quote is:
|
| > Programmers waste enormous amounts of time thinking
| about, or worrying about, the speed of noncritical parts
| of their programs, and these attempts at efficiency
| actually have a strong negative impact when debugging and
| maintenance are considered. We should forget about small
| efficiencies, say about 97% of the time: premature
| optimization is the root of all evil. Yet we should not
| pass up our opportunities in that critical 3%.
|
| Sometimes the best way to tackle that 3% is upfront when
| you're deciding on your system architecture.
| nkrisc wrote:
| Just the other day on reddit I saw someone asking about
| efficiently removing an item from an array for the game
| they're working on. It became this whole CS debate and
| then someone asked how big the array is and how often do
| you remove items. The OP responded that it's just a list
| of levels in their game, so not more than 20 items or so
| and is modified once every 5-10 minutes...
|
| So a day on their game wasted over efficiently removing
| an item from an array of 20 items every 5-10 minutes.
| corysama wrote:
| I used to make 3D engines and asset pipelines
| professionally. High performance really is critical in
| both. So, I'd have to check myself frequently:
|
| > If I optimize this, how much time is it going to save
| the whole world? What will be the sum of time saved by
| everyone who will ever run this code? Is that less than
| the time required of me to do the optimization? Then,
| don't do it!
|
| That question was relevant quite often.
|
| The big optimizations though really mattered. And,
| required planning before initial implementation to set
| the system up to be optimizable.
| johnnyanmac wrote:
| Really highlights the divide between industry and
| acedemia.
|
| Reminds me of when another subreddit was mocking some
| legacy code (I think Motorola? Some mobile device stuff)
| for using bubble sort. Meanwhile, the sort probably wasnt
| on more than a fee hundred items and the mobile embedded
| is constrained for space. Bubble sort is easy to read,
| write and has O(1) space. Performance isn't a concern at
| the scale being worked at. We're talking maybe
| microseconds of difference.
|
| It's not necessarily a bad thing that acedemia focuses on
| theory. But we keep using school to put a square peg into
| a round hole and wonder why students are so unprepared
| for actual production.
|
| It's ultimately the company's fault. If you want certain
| skills, you need to train for it. Your processes aren't
| public, so you can't just expect candidates to magically
| know what matters to their role.
|
| ----
|
| now acedemically: the answer is to swap an item to the
| end and reduce the buffer size. I don't think that's
| taught in acedemia either, but that's a trick you learn
| on the job. When and if you do need it.
| monkeyelite wrote:
| > using your own engine will probably kill you commercially.
|
| No - spending a lot of time making tools you don't need is
| the problem. You can write your own engine and leverage
| existing tools.
| dismalaf wrote:
| Visual editors are a waste of time. For 2D, lots of solutions
| exist (Tiled for example). For 3D, you can use Blender as
| your editor.
|
| The key to making no engine work is to make only what you
| actually need.
| whstl wrote:
| That's a great idea.
|
| I have limited experience scripting Blender, but there is a
| BPY API to add custom panels, so adding metadata to
| "entities" and simplifying the export workflow is probably
| feasible to the point it will be very close to an editor.
| dismalaf wrote:
| Even without scripting Blender, GLTF _is_ a "scene"
| format. GLTF files hold information about models,
| textures, lights, etc... So you can create your scene
| then import straight into your game with GLTF (open
| source, super common).
|
| And of course since Blender is used for movies, it does
| scenes well already.
| Supermancho wrote:
| Visual editing is how all UI is designed. It's not a waste
| of time. Visual editing is the primary way to prototype,
| which means it's heavily used at the beginning and less as
| development goes forward. Projects have some process to
| translate the prototypes into scaffolding UI in the Editor,
| then modify with state where necessary. This pipeline is
| common across all types of software.
| dismalaf wrote:
| Sorry, I thought the context was clear given the parent.
| _Making your own visual editor_ is a waste of time when
| ones exist that will output a format you can simply put
| into your game.
| johnnyanmac wrote:
| > For 3D, you can use Blender as your editor.
|
| Really depends on the team size, composition, and game. If
| you have designers on the team who aren't dedicated
| programmers, I don't think blender will cut it for them.
| interludead wrote:
| Yep, the tooling is where the real grind (and magic) happens
| insraq wrote:
| I have recently done an engine rewrite for my sequel game and I
| very much agree with this. In my postmortem[1], I wrote:
|
| > Most people think of a "game engine" as code that is shipped
| with the game executable. However, that's only half of it. The
| other half, which I'd argue is more significant, is the code
| that is not shipped with the game - level editors, content
| pipelines, debugging/profiling tools, development workflows,
| etc.
|
| Writing tools is arguably more boring and tedious compared to
| writing an engine, and that's where lots of "making a game with
| custom engine" type of project grinds to a halt
|
| [1] https://ruoyusun.com/2025/04/18/game-sequel-lessons.html
| philistine wrote:
| So that's where Chris Robert's billion dollar went.
| flohofwoe wrote:
| I keep saying that the engine is just that little runtime
| attachment dangling off the end of the asset pipeline ;)
|
| (and the same is becoming more and more true for shader
| compilers vs 3D APIs - all the interesting stuff is happening
| in the shader compiler, while the 3D API is just there to kick
| off shaders and feed them with input data)
| leonard-somero wrote:
| It really is a miracle that any video games get shipped at all.
| pwitvoet wrote:
| Writing an editor from scratch is a lot of work. That's one
| reason why I would use an existing editor whenever possible.
| For example, TrenchBroom (Quake editor) + func_godot seems to
| be getting more popular among Godot users, and Tiled looks
| pretty good for 2D games. For game data management I've seen
| CastleDB (never used it though), which now seems to be
| integrated into Hide, a full-blown 3D editor.
|
| Either way, once you get the tooling up and running, the next
| big step is actually designing a game and creating all the
| content. :)
| Keyframe wrote:
| Not saying it's a lot less work, it's still a ton of work, but
| you could always build your tooling around a DCC application by
| either extending it with scripts or modifying or attaching
| parts to it like Blender, Maya, etc. Maybe even flat out game
| engine editors like Godot, Unity, Unreal to build stuff and
| export out to be used by your own engine.
| aleph_minus_one wrote:
| > The real meat & potatoes is all the tooling and content and
| asset pipelines around the engine
|
| This depends a lot on the type of game that you create. For
| example, if a lot of content is procedurally generated, for
| example the map editor can be simpler, and you need less kinds
| of data formats to import. Also, some genres require a lot more
| "external content" than other genres. Even if you keep the
| genre constant, you will find games where the "value
| proposition" lies more in the game engine vs those where the
| "value proposition" lies in the assets.
|
| In particular for indie games, you can be much more flexible on
| how you structure your game compared to AAA titles.
| Llamamoe wrote:
| > 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:
|
| I wonder if there'd be any value in someone making a FOSS
| engine-agnostic editor designed to be as easy and powerful to
| adapt to any other engine/framework/etc as possible.
| zoky wrote:
| The problem is that the type of assets you need to design
| varies tremendously depending on the type of game you're
| making. A 2D pixel-art platformer, a multiplayer FPS, a top-
| down strategy sim, and a puzzle game are all going to require
| completely different types of assets with unique design
| requirements. You'd need an all-singing-and-dancing tool that
| probably wouldn't be as good at any one thing as the existing
| specialized tools, FOSS or otherwise.
|
| Although come to think of it, you could probably do most of
| that in Blender, so maybe such an thing already exists.
| flohofwoe wrote:
| There's basically two paths:
|
| (1) Build a generic and extensible UI tool which at the
| core is a 3D scene viewer, object outliner and an asset
| browser (similar to how VSCode is such a tool for 'mostly
| text data' for 3D scenes). Implement anything else as
| engine specific plugins - Blender can be that tool, but it
| would be important to do a complete UI overhaul to get the
| modelling and animation features out of the way.
|
| (2) Integrate the editor UI right into your engine, which
| is quite trivial with Dear Imgui - the tricky part here is
| that game state data should either be organized for
| editing, or for runtime performance. Mixing both isn't a
| good idea (unless moddability is a priority).
|
| About a decade ago I would probably have opted for option
| (1), nowadays I tend towards option (2).
| whstl wrote:
| I feel like path #1 would also run into the same problems
| as #2 as soon as there was any need for real-time editing
| of scenes.
| whstl wrote:
| > The problem is that the type of assets you need to design
| varies tremendously depending on the type of game you're
| making
|
| Unity, Godot, Unreal, Defold and others kind of get away
| with it, by having editors that work for most game types.
|
| But also: a tool doesn't have to cover all bases,
| especially a free/FOSS one.
| aleph_minus_one wrote:
| > I wonder if there'd be any value in someone making a FOSS
| engine-agnostic editor designed to be as easy and powerful to
| adapt to any other engine/framework/etc as possible.
|
| I see one problem (there very likely exist a lot of others)
| in the fact that a lot of frameworks and engines are "deep
| ecosystems" that take a lot of effort to get deeply into.
| Once inside the engine ecosystem, a lot of concepts are "very
| integrated/intertangled" (though not necessarily in the "best
| possible way").
|
| So, a lot of implementation time will have to be invested for
| each individual supported engine so that the editor properly
| integrates with it.
| whstl wrote:
| As a "potential customer" for such thing:
|
| I would really love something like it.
| msarchet wrote:
| Some of the other commenters have pointed this out. But this
| just doesn't quite work.
|
| I've been doing Game Dev for the better part of 15 years now
| which is almost all of my career. I've been almost solely
| focused on building Tools and almost always building Editor
| internals and the interactions with the engine/assets
| systems.
|
| There's just so so much nuance to how editing works. You also
| want to be as close to how the engine will render so there's
| also the need to either embed or have an api on your game to
| edit content live. People need hot reloading, people need
| things to look and act correct.
|
| Just rendering a model accurately can be a challenge. Don't
| get me started on animations
| runevault wrote:
| To some degree subsets of this exist.
|
| For example for 2d games it is possible to use Tiled as a
| level editor if you build your game (or some tool) to parse
| out tiled's file format and turn it into in-game levels.
|
| A more general purpose editor in line with Unity or Godot's
| that includes the ability to attach functionality to
| everything would be much harder since the specifics of that
| will be much more engine specific.
| agentultra wrote:
| Keep in mind that when writing your own "engine," you don't
| need it to be as general as possible to handle every possible
| kind of game. You just need it to handle your game.
|
| And there are plenty of libraries and frameworks that can be
| pulled in to handle things like UI, compression, etc. The OP
| uses imGUI which is an excellent, small UI library for making
| in-game editors.
|
| When choosing to go down that path you're not making, "an
| engine for all games." So there is a ton of work you're not
| doing.
| lukan wrote:
| It is still a lot of work.
|
| And every external libary you do pull in, to ease some of the
| workload, is just waiting to go abandonend next year. So
| instead of focusing on release by that time, you will now
| focus on reinplementing that needed functionality that just
| stopped working.
| agentultra wrote:
| Definitely, it's a trade off. Pulling in dubious
| dependencies can be a risk. Might be worth writing your own
| library or forking the dependency and vendoring it in your
| source.
|
| There's a spectrum of options here.
| Narishma wrote:
| > So instead of focusing on release by that time, you will
| now focus on reinplementing that needed functionality that
| just stopped working.
|
| That makes no sense. A library being abandoned doesn't mean
| it suddenly stops working.
| Balooga wrote:
| The library would continue to work but may no longer be
| usable if other dependencies require a later version of
| "n" that the abandoned library is incompatible with. Ruby
| or Python runtimes are the classic example.
| johnnyanmac wrote:
| Support for any studio larger than a few people is the
| most important part of 3rd party tools. If (and
| inevitably, when) a tool has a bug or can't do something
| you need, there's reassurance being able to tell someone
| else to fix the problem.
|
| Using abandoned tools either means you're very sure all
| use cases are covered, or that your own engineers are
| willing to hack around should it not be sufficient. And I
| think anyone who works with legacy code knows that
| navigating already written codebases without guidance can
| take just as long as whipping up a custom implementation.
| lukan wrote:
| I wish that would be the case, but on the web stack, it
| happened more than once to me.
|
| The web evolves. Lots of features get deprecated all the
| time and sometimes removed or change behavior in a
| significant way.
| cobalt wrote:
| This is really the case for all engines. Unity is a bit of of
| an outlier, though took a long time to get where it is.
|
| Unreal Engine is really the Unreal Tournament/Gears of War
| engine at its core.
|
| Good engines are those that are focused on what the game
| needs. YAGNI/KISS apply here too
| corysama wrote:
| At the indie studio I used to work at, we had some folks with
| engine experience. So, we rolled our own 3D engine and asset
| pipeline from scratch. But, we didn't have the budget for an
| editor. Instead we set up the asset pipeline to hot-reload
| everything. Meshes, scenes, materials and animations from Maya.
| Textures from Photoshop. Audio as a pile of WAVs. Scripting in
| Lua. UI layout in XML. Changing the asset files would change
| the game live.
|
| Then we added "State machines as Lua exported from Excel". Rows
| are states, columns are events, cells are code to execute given
| a state+event combo. I've done this a few times. It makes huge
| state machines manageable.
|
| Our games were very stats-heavy and our designers liked Excel.
| So, a new thing we added as "Dynamic data sources as grids of
| Lua exported from Excel". So, fill out Excel sheets like
| normal. But, instead of Excel script, every cell is evaluable
| Lua code. Strings, numbers, bools, functions are all values in
| Lua. So, a cell might contain a number. Or, it might contain a
| function checking the contents of two other cells and
| optionally triggering an event on some other object.
|
| We shipped multiple games on a single executable using this
| system. Artists could lay out 3D scenes and 2D UIs with hooks
| for the Lua to control it. And, the designers could populate
| scenes and UIs from Excel dynamically according to the state of
| the game. The programmers mostly worked on game-agnostic
| features in C++, and the heavier side of scripting in Lua for
| game-specific features.
|
| Aside: Lua is being so dynamically typed makes it not great for
| large-scale software engineering. But, https://teal-
| language.org/ might be a good TypeScript-For-Lua. I haven't
| tried it. Also, are there any Lua debuggers newer than the
| ancient https://github.com/unknownworlds/decoda that require
| zero integration? Decoda just need a pdb of your executable and
| it can automatically debug any scripts passing through the Lua
| library.
|
| Eventually, we switched to Unity for corporate reasons. As a
| primary implementer of our custom engine, I think the switch
| was overall a good thing. Our games had started to outgrow what
| our little engine team could deliver. The artists reported they
| felt slightly less productive working in Unity's editor. I
| switched roles to finding and working around the undocumented
| bugs in Unity that we ran into. Then later finding which bugs
| had been fixed without being mentioned in the release notes so
| I could delete my work-arounds. It was a very boring couple of
| years until the company burned to the ground because of the
| same corporate reasons that lead us to switch to Unity :P
| wsc981 wrote:
| There's the Local Lua Debugger [0]. I don't know how it
| compares to decoda, but I experimented a bit with this
| debugger last weekend and it seems nice enough - well
| integrated into VS Code.
|
| ---
|
| [0]: https://github.com/tomblind/local-lua-debugger-vscode
| corysama wrote:
| The magic of Decoda is that you can download the debugger
| and immediately start debugging your existing program with
| no modifications. No libraries. No sockets. No changes at
| all.
|
| Decoda uses your PDB to locate the Lua C library within
| your .exe and the Win32 API CreateRemoteThread to inject
| the code into your process to hook the Lua API.
| lukan wrote:
| I guess the main disadvantage with a custom engine vs Unity,
| is that you must train new people in it all, vs hiring
| experts in the tools.
|
| Your custom engine sounds interesting, though. I can
| recognize some thoughts ..
| munificent wrote:
| _> But, we didn 't have the budget for an editor. Instead we
| set up the asset pipeline to hot-reload everything. Meshes,
| scenes, materials and animations from Maya._
|
| I was the tools lead for "Superman Returns: The Videogame"
| (the PS2/X630 Superman game, no the N64 one). We did the same
| thing. All of Metropolis was essentially "modeled" in Maya
| with plug-ins handling importing and exporting between that
| and the in-game format.
|
| It was an open world streaming game and it would have killed
| an artist's machine to try to load the entire city into Maya,
| so the plug-in would let an artist pick which chunks of the
| city to load, load them in, let them make changes, and save
| the results back out.
|
| It worked out fairly well.
| whstl wrote:
| This is so cool and clever!
|
| Scott Bilas also documents doing something similar for
| Gabriel Knight 3, one of the "grandfathers" of data-driven
| engines and bit of an influence on ECS.
|
| Instead of excel however it was comma-separated text files
| that shipped with the game. During development could edit the
| files locally and reload the data without recompiling.
|
| Since we're in a web heavy forum: An sql database and a web
| editor would also allow for a distributed workflow.
| raincole wrote:
| > Engines are the easy part.
|
| > The real meat & potatoes is all the tooling and content and
| asset pipelines around the engine.
|
| When people talk about engines they often include the asset
| pipelines and editors by default. Engines today are not just a
| main loop + 3D API calls. Very few devs will say we're going to
| use Unity but only for its rendering code.
|
| (Of course I'm not implying as long as you use Unity/Unreal
| you'll never need to write your own asset tools.)
| nico wrote:
| Vibecoding is probably going to take this whole industry by
| storm
|
| Already the biggest market is small games on tablets/phones
|
| Now making those games is becoming exponentially faster and
| easier
|
| Roblox, allowing people to quickly create their own games, was
| already a huge hit. Now that experience is getting supercharged
| with AI
| raincole wrote:
| You see? This is why people hate ai bros. They never stop at
| leaving their own comments promoting AI. They have to hijack
| the top comment (which is unrelated to AI) and force their
| self-injection there.
| nico wrote:
| Such a hostile comment. Just trying to open up the
| conversation. No need for snark or aggressive name calling
|
| The article is about creating video games without an
| engine, and the top comment is about what is hard about
| making video games
|
| My comment is about how all of that is changing right now
| and how the public is reacting to it
| yua_mikami wrote:
| Nah he's right, people are fed up of hearing about AI all
| the time, it's off topic here.
| iFire wrote:
| Even if you vibe code a game engine your best llm will
| need to do the work of world class technical team of like
| 12 people, you'll need to get 10-20 teams to be able to
| find that dataset. Each run costing a few million usd.
| nico wrote:
| Not sure what that use case is. Why would you need all of
| that? As an individual, if you are just trying to build a
| basic game with your kids you don't need to build a whole
| engine nor a world class technical team or a huge dataset
|
| You can either use chatgpt or something more basic like
| openjam.ai or something specialized like rosebud.ai
|
| Maybe the people at rosebud.ai have been doing what you
| are suggesting to build their platform
| iFire wrote:
| Not everyone wants the biggest technology companies to
| own the process.
| johnnyanmac wrote:
| Until AI can actually generate proper topology for meshes,
| I'm negatively worried about any Vibe coders flooding the
| market anymore than the market already is. The code is the
| least valuable part of a game in the eyes of a consumer.
|
| And topology isn't even the hard part of asset production.
| Animating is the next big hurdle after that.
| glouwbug wrote:
| The engine is the fun part. Assets and game design are near
| impossible as a solo dev
| johnnyanmac wrote:
| Impossible but necessary. It's the big difference between an
| engine programmer and an indie dev. The latter needs to wear
| multiple hats to get something out while the former can
| specialize and work within a team of other specialists.
| qingcharles wrote:
| When I was a game dev I spent way more time on tools than on
| the engine. Those days of small teams are gone now, so at least
| in a professional setting you are likely to be able to
| concentrate on the engine while some other person has to build
| the editors.
| cypherpunk666 wrote:
| Word! i've done some ground-up 2D games with no engine library.
| So i hand-rolled resources, frame rate, collision, simple
| physics, etc. One has no graphics assets. Another other does.
|
| https://github.com/raould/pn0gstr0m
| https://github.com/raould/sheepgate
| Protostome wrote:
| 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 wrote:
| Not OP, but this is Noel Berry, one of the creators of Celeste,
| a very successful and incredible indie game.
| Protostome wrote:
| 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 wrote:
| The secret extra sauce is called marketing :)
| slowhadoken wrote:
| I agree with making games from scratch. That being said I thought
| Celeste was wildly overrated. Keep up he hard work though.
| HelloUsername wrote:
| In the end of the post Noel mentions Aseprite, but he might be
| interested in Libresprite as well? https://libresprite.github.io/
| 3036e4 wrote:
| Does it add much on top of the old GPL aseprite it forked from?
| interludead wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| sambeau wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| For simpler games, libraries such as raylib or lightweight
| opensource game engines such as Amulet (https://www.amulet.xyz/)
| / Love 2D are good fit.
| yugoslavia4ever wrote:
| +1 for raylib, probably the best C library ever written.
| dakom wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| archagon wrote:
| Games are "dead" in the same way that music is "dead."
| z3t4 wrote:
| 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 wrote:
| 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 wrote:
| Just to note that the author wrote this game, >3 million copies
| sold: https://en.wikipedia.org/wiki/Celeste_(video_game)
| throwawayffffas wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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/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_Simu...
|
| https://store.steampowered.com/app/2073910/A_Webbing_Journey...
|
| https://store.steampowered.com/app/3498270/Better_Mart/
|
| https://store.steampowered.com/app/2625420/Drive_Beyond_Hori...
|
| https://store.steampowered.com/app/3163790/Toy_Shop_Simulato...
|
| https://store.steampowered.com/app/3023600/Horse_Farm_Simula...
|
| https://store.steampowered.com/app/3124550/Liquor_Store_Simu...
| iFire wrote:
| Ha, if I remember correctly the squad military sim was a
| reskinned first person demo from epic games.
| russellbeattie wrote:
| 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 wrote:
| 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 wrote:
| > 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
| varbhat wrote:
| 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 wrote:
| 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
| 3036e4 wrote:
| 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 wrote:
| 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 wrote:
| Modern .NET/C# is cross-platform by default (CoreCLR runtime).
| You don't need Mono anymore.
| OnACoffeeBreak wrote:
| 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/nati...
| tiniuclx wrote:
| 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/
| deepfriedrice wrote:
| Oh wow - I wanted to build a game just like this not too long
| ago but never found the time. Wishlisted!
| kkukshtel wrote:
| 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/
|
| 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/Typ...
| w4rh4wk5 wrote:
| 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 wrote:
| 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 wrote:
| 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-fo...
|
| Long discussion thread with many graphs with measurements:
| https://github.com/dotnet/runtime/discussions/115627
|
| I don't yet have hands-on experience with that Satori GC,
| though.
| jayd16 wrote:
| In a game like the author's where you just init/pool everything
| on load you can simply disable the garbage collector during
| gameplay.
| JKCalhoun wrote:
| 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/
| symfoniq wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| To be fair, "compiled to bytecode which is JITted af runtime"
| is pretty common of lnaguage implementations described as
| "interpreted", like CRuby.
| nico wrote:
| 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://openjam.ai/lonely_ant_702/v3nyt4if54
|
| https://rosebud.ai
|
| https://openjam.ai/
| jagger27 wrote:
| Why should less thought be put into things made for children?
| nico wrote:
| 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 wrote:
| 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
| hbn wrote:
| 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
|
| 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 wrote:
| Congratulations man, great work.
| VikingCoder wrote:
| 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 wrote:
| 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
| LOVE / LOVR 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 wrote:
| Monorepo?
| VikingCoder wrote:
| 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.
| iFire wrote:
| You can also see my workflow for patching godot engine so
| it's mergable on a rebased master or stable release.
|
| > This project uses git-assembler to simplify merging
| patches on top of the latest stable release by allowing
| each patch to be in a separate branch, so they can all be
| merged into a fresh branch without complicating the
| revision history.
|
| https://github.com/KeyboardDanni/godot-for-sidescrollers
|
| I'm https://github.com/fire
| jbjbjbjb wrote:
| Make your own packages for your extensions and pull that
| packages into your projects that need to reference those
| extensions.
| VikingCoder wrote:
| And set up my own nuget repo?
|
| I want my code to be private...?
| jbjbjbjb wrote:
| Yes you would set up your own nuget feed and publish as
| part of your build. You can set up the nuget feed on your
| own machine, use something like Teamcity or GitHub
| packages.
| unclad5968 wrote:
| How does any other language do this? I bounce between
| submodules and monorepo for hobby projects and both approaches
| have some issues. I'm not a git expert so working with
| monorepos are a little easier to work with for me.
| iFire wrote:
| I use git subrepo to make a monorepo.
| orthoxerox wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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-updat...
| hbn wrote:
| 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 wrote:
| Of course it was relevant. If they had a better game engine
| it would have been further along.
| hbn wrote:
| 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 wrote:
| 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.
| archagon wrote:
| 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.
___________________________________________________________________
(page generated 2025-05-20 23:01 UTC)