Comment by MindSpunk | Hacker News Reader

Comment by MindSpunk | Hacker News Reader

Seems like a cool project.

I don't understand why they're calling out the FPS of an empty scene as a useful number compared to Unity though. Ignoring that this engine will have a fraction of the features of Unity (the likely reason for the FPS number in the first place), it's just a useless benchmark because it's an empty scene. `while (true) {}` will get you the same thing.

I'd wish they'd highlight how the engine helps you make a game rather than arbitrary performance numbers on microbenchmarks that don't generalize to a real game project. You can absolutely be faster than Unity, but "9 times faster than Unity out of the box" is not a number people should take seriously without the context of where the number comes from.

I wish them well though. I'm always interested to see more work in implementing engines in GC languages. I'm personally quite interested to see what can be done in modern GC languages like Go or (modern) C# which provide lots of tools to limit GC pressure. Being able to write C-like code where needed in an otherwise managed runtime is a really powerful tool that can provide a best-of-both-worlds environment.

Agreed. Unity has a ton of features that even Godot lacks. (Unreal also has a ton of features they all lack).

I know a lot of different languages and frameworks, from C/C++ up, so I say this: The language is never the issue. Language is just syntax. ease of use is everything.

I've been wanting to make a game for a long time. I toyed with OpenGL/DirectX at multiple points since the 90s, even going so far as to creating a really cool tech demo/engine that scales with CPU core count. However, those days are in the past. I really want to focus on not writing a ton of graphics and sound code. I really want to focus on the game logic and the game itself.

The above is one of the reasons I'm finding it hard to get into Godot, even though I *really* like the project (and wish I could fund it, alas, I'm unemployed, permanently). Unity just happens to be robust enough that I might be able to scrap together a prototype. It has built in things like a terrain editor, tons of educational material, an asset store to get some placeholder assets, etc.

I saw a comment mentioning how Warcraft 2 was so awesome because it had a great editor. I saw that and also Starcraft had an amazing editor. Neverwinter Nights also had an amazing editor. We need something like that with a good license to build games. Every engine that even somewhat approaches that area blows up in complexity, has a super restrictive license, or doesn't allow you to build your own executables.

RPGMaker actually is pretty decent for 2D games, however the fixed resolution and constant dramatic shifts between versions, previous licensing issues (I haven't looked at their current license), and more make it a no go for a serious commercial game...and it doesn't do 3D.

Sorry for the rant. Don't even get me started on how much more complicated the transitions from DX8-DX12 or OpenGL 1.x/2.x -> Anything else have been. ;)

There's a cruel truth to electing to use any dependency for a game, in that all of it may or may not be a placeholder for the final design. If the code that's there aligns with the design you have, maybe you speed along to shipping something, but all the large productions end up doing things custom somewhere, somehow, whether that's in the binary or through scripts.

But none of the code is necessary to do game design either, because that just reflects the symbolic complexity you're trying to put into it. You can run a simpler scene, with less graphics, and it will still be a game. That's why we have "10-line BASIC" game jams and they produce interesting and playable results. The aspect of making it commercial quality is more tied to getting the necessary kinds and quantities of feedback to find the audience and meet them at their expectations, and sometimes that means using a big-boy engine to get a pile of oft-requested features, but I've also seen it be completely unimportant. It just depends a lot on what you're making.

> "Unity has a ton of features that even Godot lacks. (Unreal also has a ton of features they all lack)."

Hard to interpret w/out more detailed comparison but stack-ranking their featurefulness, is it Unreal, Unity, Godot?

Unity can't really be said to have less or more features than Unreal IMO. Each has features lacked by the other, and neither lacks anything really major. But if I had to pick one for being the most featureful, I'd pick Unreal. Unreal has a built-in visual programming language* and some very advanced rendering tech you might have heard about. Unity has tons of features for 2D games lacking in Unreal and supports WebGL as a build target.

(Though imo unity is the better engine. Unreal has so many bugs and so much jank that to make a real game with it you basically need a large enough team that you can have a dedicated unreal-bug-fixer employee.)

*Technically Unity has a visual scripting language too but IIUC it's tacked on and I've never heard of anyone actually using it.

Speaking of bugs, I remember the last time I thought maybe I'd try making a simple game in Unity I gave up when I couldn't stop clipping through walls.

The collision was clearly working, just some n% of the time you'd end up on the wrong side of the clean flat rectangle you were walking into.

I lost interest pretty soon after that.

That's not a bug just an inherent problem with using very thin colliders with a discrete collision detection system. It's not a Unity problem and Unity allows you to configure continuous collision detection to prevent tunneling https://docs.unity3d.com/6000.3/Documentation/Manual/Continu...

Game development is full of domain knowledge like this because games need to make compromises ensure completing simulation updates at no lower than 30Hz.

That's fair. I just remember being very frustrated that felt like a basic feature I was implementing per the tutorial broke immediately in such a fundamental way in such a simple situation, and not being able to find any sort of explanation or solution at the time. Possibly it was fully my fault and the info was readily available!

I think its really just the trappings of game development being full of tribal knowledge.

The tutorial probably should have instructed you create box colliders for walls (giving a greater area for the physics engine to catch collisions) rather than a simple plane/quad which would lead to the exact issues you had, or at least explained why a box works better than a plane.

I guess you have to balance the necessary information with overload in your tutorial or at least have an aside or additional reading that really helps understand many of these internalized understandings.

I'd say Unreal > Unity > Godot for feature space.

For performance/practicality, it's Unity > Godot > Unreal. Building something in Unreal that simply runs with ultra low frame latency is possible, but the way the ecosystem is structured you will be permanently burdened by things like temporal anti-aliasing way before you find your bearings. Unreal and Unity are at odds on MSAA support (Unity has it, Unreal doesn't). MSAA can be king if you have an art team with game dev knowledge from 10+ years ago. Unreal is basically TAA or bust.

> I know a lot of different languages and frameworks, from C/C++ up, so I say this: The language is never the issue. Language is just syntax. ease of use is everything.

TBH the weird C# version Unity uses has been an issue multiple times =)

"I'm authoring a new Golang based firmware for a retrocomputer I literally pulled out of the trash that nobody will use"

HN: "Ah you're sweet"

"I'm authoring a new Golang based game engine that doesn't have the featureset of things with $100 million to $3 billion of product development"

HN: "Hello, human resources?"

This would be a much better comment if it weren't for the snark and fake quotes.

I see it as overhead for the base engine. Though yes, even unity has some post processing built in that would affect performance.

But, I will always correct the cardinal sin of "using FPS to measure performance". Especially for an empty scene, this is pretty much snake oil. 200 fps is 5 milliseconds 1800 fps is a little pver half a millisecond. Giving back 4.5 milliseconds doesn't means much if any sense of real work will add it back.

Still not "9 times faster", and still seems disingenuous, but here is one comparison that is at least given with some more context: https://x.com/ShieldCrush/status/1943516032674537958

Ppth(//news.ycombinator.com/-+).us

Reply on news.ycombinator.com