Live data from Hacker News

Core: an experimental new way to write videogames

github.com

181–190 of 224 posts

Re: Core: an experimental new way to write videogames

#181
post #26

Earlier quoted context omitted.

After doing functional programming for a while now (6 years of Elixir) it seems obvious to me that it is possible and no more complex than using imperative logic. In fact I would go so far as to say that managing complexity (i.e. state) is much easier to do in a functional style than imperative. Functional is all about transformation of data structures, and a game is nothing more than a function that takes {state, mo…

Could an expert strong man the argument that functional programming languages like Haskell could in theory be more performant than C because of the nice properties of pure functional languages?

GHC is effectively an attempt to strong-man that argument over a couple of decades, and in short, it failed. It has pretty good performance for what all Haskell is doing, but if you want to write C-speed Haskell you are restricted to a tiny portion of Haskell that you can only understand with deep knowledge of GHC, and based on what I've seen of it, it is completely unrealistic to call it "Haskell" anymore. It's more a language that happens to be embedded inside of Haskell, but unspecified. (Sort of like "the performant subset of Javascript if you want the JIT to do its best"... it exists, but it's undocumented, it isn't the same between engines, and it's very hard to write it without an intense knowledge of the innards.)

The "sufficiently smart compilers" turn out to either not exist, or be beyond the ability of even the smartest humans.

This is not celebration of that, or condemnation that anyone tried. It's a major bummer, actually, and I am suitably bummed. I'd love to have the Sufficiently Smart Compiler. But wanting doesn't count for much. At this point if someone wants to argue that something at a Haskell level of "functional programming" can run at C speed routinely, they need to produce the compiler; we ran the gamut on mere theories.

(I have to qualify it that way because we do have a lot of evidence that you can have "functional flavored" languages that run much more quickly, like O'Caml (at least in single thread) and Rust, if you consider that "functional flavored". But straight-up Haskell does not appear to be able to "just" get transformed to C-speed code reliably.)

Re: Core: an experimental new way to write videogames

#183

Oooh, this is cool. I always like to see different approaches to game dev (despite never having published a game!). So far I've tried - Bevy (Rust ECS engine), which is nice at first but has a lot of problems with its implementation and can become rather messy. I think it's heavily dependent on the game. Part of it will be my own incompetence. - Unity. IMO the system of gameobjects with composed modular components is…

I've been a game dev (and services dev) for a two decades and I could not disagree with you regarding Unity and Godot more strongly.

Having gotten into Godot with v4, it was a huge breath of fresh air coming from Unity and Unreal (which isn't really hobby friendly).

Composition of nodes is quick, easy to compartmentalize, and having signals as an interface makes building them very, very quick. Yes, the debugging story on Godot isn't quite there yet, but I genuinely doubt I'll ever touch Unity again unless I have to for a job.

Re: Core: an experimental new way to write videogames

#184
post #125

As a game dev, this GitHub is comical to me. Bordering on parody of the kind of academic navel gazing that game devs stick their nose up at. Cherry on top is the ugly screenshot.

This seems like the wrong site for you, then? Hacker news generally has stories about interesting new ideas. It's not really the place to discuss incremental improvements to C++ and Unity. I can think of a couple games that sprang from odd academic navel gazing like this. A sibling comment mentioned Jonathan Blow; when I read about this project, it immediately reminded me of Braid. I remember when procedural generati…

To me at least, the great value of this site is that people can and do write their honest opinion. Maybe the style of the parent comment wasn't that good, but I agree with the take that there does not seem to be much of value in the project, it enables a style of game that has been done to death by amateurs and indies, and there are probably better tools out there for making that kind of game as well.

Braid features actual novelty in game design, enabled exactly by not using an engine with a fixed view on how a game works. I don't see how this compares.

Re: Core: an experimental new way to write videogames

#185
post #174

Earlier quoted context omitted.

I think the original commenter just really likes "plug and play" solutions with a lot of hand holding which is what Unity is excellent at. The problems come down the line. Godot is objectively a way way better tool

It's definitely not a "way way better tool" and no serious game developer would say that. Everyone agrees that Godot has a lot of catching up to do but we're still using it because we believe in the foundation and what it will eventually become.

I'm a serious game developer, been in the industry for decades.

I would say that. Godot is a way way better tool.

There, I've falsified your claim.

But more seriously, it's a faster dev experience, it's more ergonomic, it's not cluttered with half baked "new" ways of doing things that don't do everything the old ways do. There's no reason to pick up Unity unless you are being paid to, IMO.

Re: Core: an experimental new way to write videogames

#186

Oooh, this is cool. I always like to see different approaches to game dev (despite never having published a game!). So far I've tried - Bevy (Rust ECS engine), which is nice at first but has a lot of problems with its implementation and can become rather messy. I think it's heavily dependent on the game. Part of it will be my own incompetence. - Unity. IMO the system of gameobjects with composed modular components is…

I totally agree for Godot. All the worst mistakes of OOP which I thought we got rid of years ago. Bizarre situation

Godot much prefers composition over inheritance. It's possible to use inheritance in Godot, but no-one recommends it, except maybe for a data structure.

Re: Core: an experimental new way to write videogames

#187

Oooh, this is cool. I always like to see different approaches to game dev (despite never having published a game!). So far I've tried - Bevy (Rust ECS engine), which is nice at first but has a lot of problems with its implementation and can become rather messy. I think it's heavily dependent on the game. Part of it will be my own incompetence. - Unity. IMO the system of gameobjects with composed modular components is…

I'm not that familiar with Godot but the built in language always felt like a misstep. Maybe someone more familiar with it can make a defense. I view 3 users 1. Complete Novice 2. Engineer dabbling in games 3. Professional game designer. For #2, they are more likely to prefer C# as they probably already have experience with it, or otherwise will be familiar with the similar Java language. Also it's a nice resume boos…

GDScript is closely tied to the engine, making it incredibly easy to affect any part of your project. It's also very terse and simple to use, and anyone with a passing knowledge of Python should be able to pick it up in minutes.

I've used C# for my day job for years, but never felt the need to stop using GDScript for any of my projects.

Re: Core: an experimental new way to write videogames

#188
post #185
post #174

Earlier quoted context omitted.

It's definitely not a "way way better tool" and no serious game developer would say that. Everyone agrees that Godot has a lot of catching up to do but we're still using it because we believe in the foundation and what it will eventually become.

I'm a serious game developer, been in the industry for decades. I would say that. Godot is a way way better tool. There, I've falsified your claim. But more seriously, it's a faster dev experience, it's more ergonomic, it's not cluttered with half baked "new" ways of doing things that don't do everything the old ways do. There's no reason to pick up Unity unless you are being paid to, IMO.

Or any of these

> Unity's advantage over Godot is it's 3D renderer, built in physX, il2cpp backend for C#, profiler, general runtime performance and console support.

And correct me if I'm wrong, but Godot doesn't have hot code reloading where you don't have to restart your game.

Re: Core: an experimental new way to write videogames

#190
post #185

Earlier quoted context omitted.

I'm a serious game developer, been in the industry for decades. I would say that. Godot is a way way better tool. There, I've falsified your claim. But more seriously, it's a faster dev experience, it's more ergonomic, it's not cluttered with half baked "new" ways of doing things that don't do everything the old ways do. There's no reason to pick up Unity unless you are being paid to, IMO.

Or any of these > Unity's advantage over Godot is it's 3D renderer, built in physX, il2cpp backend for C#, profiler, general runtime performance and console support. And correct me if I'm wrong, but Godot doesn't have hot code reloading where you don't have to restart your game.

Godot has a good 3D renderer. It has a built in physics system and an off the shelf upgrade to Jolt (which was used in horizon forbidden west). There's absolutely a profiler (https://docs.godotengine.org/en/stable/tutorials/scripting/d...).

Hot reloading is supported.

Console support is some work. Possible, but work.

Post reply on HN