Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Core: an experimental new way to write videogames

github.com

Post reply on HN
Print view View original

211–220 of 224 posts

Re: Core: an experimental new way to write videogames

#211

Post by CaptainOfCoit »

noelwelsh wrote: post #165
spoiler wrote: post #27

Earlier quoted context omitted.

> - Bevy (Rust ECS engine), which is nice at first but has a lot of problems with its implementation and can become rather messy. Can you expand a bit about why this was messy or comolicated? I found the paradigm leads to pretty well organised code (sometimes you get the odd large system, but it can be broken down into smaller systems, sub systems or composed out of smaller functions).

I started using Bevy for a small game and abandoned it after a little while. There are two issues: 1. The fundamental issue is that the ECS model has independent subsystems communicating via a relational database. This breaks the connection between function callers and callees, makes control flow incredibly hard to trace, and means the type system can give you very little assistance. 2. Bevy also does not leverage Ru…

> 2. Bevy also does not leverage Rust's type system in other ways. E.g. you can use resources that you forget to create and it will only crash at runtime instead of giving a compile time error.

Would something else even be possible in Rust? My understanding is that you cannot really add type safety in the way of "This should be a i64 and between 32 and 128, otherwise fail to compile", so not sure how it could be addressed by the language.

Or taken to the extreme "Fail to compile if the user creates an instance of this but doesn't call function F with that newly created instance"

Re: Core: an experimental new way to write videogames

#212

Post by mdaniel »

vyrotek wrote: post #91
Alex-Programs wrote: post #23

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 recently learned that the popular game Balatro was made in LÖVE. I had never heard of it until then. But looks interesting. https://love2d.org

LÖVR (MIT) was posted last week: https://news.ycombinator.com/item?id=41446248

Re: Core: an experimental new way to write videogames

#213

Post by mdaniel »

nkrisc wrote: post #100
kasztelan_ wrote: post #85

Earlier quoted context omitted.

I wish that was true. I just started rewriting my project from C# to GDScript today so it can run on 32 bit ARM android devices. Let's say I'm not a big fan of the language. Why the hell they decided to not implement normal for loops, was just googling how to iterate an array backwards and most people were like "just invert the array and iterate over it, bro" They should have just used Typescript, it's a sweet spot b…

The docs have an example of iterating an array backwards: https://docs.godotengine.org/en/stable/classes/class_@gdscri... var array = [3, 6, 9] for i in range(array.size() - 1, -1, -1): print(array[i]) Admittedly not very pretty but it certainly works.

I had high hopes when I saw the yield keyword in the reference, but then saw it's basically just a reserved keyword as they don't seem to actually support generators. I would guess the less eye-bleeding version of all those 1, -1 things is just making a ReversedIter and using that: https://docs.godotengine.org/en/stable/tutorials/scripting/g...

Re: Core: an experimental new way to write videogames

#214

Post by nightowl_games »

ertian wrote: post #125
nightowl_games wrote: post #45

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…

> I don't understand the hostility.

Saying this while telling me this is the wrong site for me. Nice.

My comment isn't hostile. My opinion on this github has value and I am not alone. I could have worded it 'nicely' but if you find every brutally honest comment to be hostile, then maybe this site isnt for you.

Re: Core: an experimental new way to write videogames

#215

Post by nightowl_games »

Capricorn2481 wrote: post #188
hungie wrote: 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.

It does have hot reloading at some level. I use GDSCript for a lot of stuff and it hot reloads. And you can use live++ with it to have true top level hot reloading. We implemented a hacky live reloading for native code in shared libraries which works as well.

Re: Core: an experimental new way to write videogames

#216

Post by nightowl_games »

mirashii wrote: post #141
SoothingSorbet wrote: post #136

Earlier quoted context omitted.

What "sucks" about it? Since they added type checking it's been perfectly fine, besides the notable omission of nullable types (which is... a strange omission, to be sure).

No tuples. No structs. No real debugger. Extremely limited profiling tools. Autoformatting breaks code more often than not. No interfaces. Extremely weak async story. No refactoring tools, external IDE features like jump to definition. Built in editor is slow and buggy. No destructuring assignment, no enumerate for loops, no looping over key and value together from a dict. GDScript is, in my opinion, unsuitable for a…

Your comments are accurate, but they aren't the whole story.

> unsuitable for anything more than a couple hundred lines at most.

I work profesionally in ~5 code bases with ~10,000 lines of GDScript each. I think GDScript is great for UI widgets. I dont think you can say it has a 'line number' limit. It has a 'complexity' limit.

If your writing a ton of tiny little classes that do one thing (like play a sound when a button is pressed), then GDScript is probably the best language for that. Certainly c++ is not the best, and C# is perhaps worse as well. Note: GDScript doesnt need to be compiled _at all_. In unity, its common to have an annoying 'hang' every time you alt-tab from vscode back to unity, as the c# is compiled. In Godot, I can write a new UI widget directly in the editor, with no compilation hang, with hot reloading. It's simply a smoother experience for writing the mountain of basic plumbing that you write when making a commercial game. It's not all complex algorithms here, it's just a crapload of boring ass code. And GDScript is great for that.

Most of the code in games is tiny little things that manage sequences of animations. There is seriously so much small code to make a UI look and feel nice. Writing this code in GDScript is way faster and ergonomic than any other language I've used.

I agree, GDScript has many flaws, but from where I'm sitting (small studio, been in the industry for 10 years), GDScript is a massive boost for my productivity.

For complex stuff, I like to figure out the algoirithm in GDScript then rewrite it in C++ if it needs it. Works great. Again, massive increase in productivity.

Re: Core: an experimental new way to write videogames

#217

Post by noelwelsh »

CaptainOfCoit wrote: post #211
noelwelsh wrote: post #165

Earlier quoted context omitted.

I started using Bevy for a small game and abandoned it after a little while. There are two issues: 1. The fundamental issue is that the ECS model has independent subsystems communicating via a relational database. This breaks the connection between function callers and callees, makes control flow incredibly hard to trace, and means the type system can give you very little assistance. 2. Bevy also does not leverage Ru…

> 2. Bevy also does not leverage Rust's type system in other ways. E.g. you can use resources that you forget to create and it will only crash at runtime instead of giving a compile time error. Would something else even be possible in Rust? My understanding is that you cannot really add type safety in the way of "This should be a i64 and between 32 and 128, otherwise fail to compile", so not sure how it could be addr…

Let me explain a bit more about "you can use resources that you forget to create and it will only crash at runtime instead of giving a compile time error".

Plugins are the main abstraction in Bevy. A plugin has two parts: build and run. Build creates stuff, and run uses stuff created by build and created by the build of other plugins running at the same time.

Build is pure side-effects, so the result type of build tells you nothing about what it builds. Therefore there are no types that can constrain what resources run uses, and therefore failing to create a resource that is used in run is a run-time, not compile-time error.

The alternative is the build returns a type representing the collection of resources it creates, and run's type is a collection of resources it uses. This requires some type level programming (a type level heterogeneous set). This is some of the simplest type level programming, but type level programming itself is quite foreign to most programmers. I assume this is why the Bevy developers went for the easier to write solution that doesn't enforce constraints at compile-time.

More generally, just like in regular programming some things are easier and some are harder to do in common type systems.

Your first example (integer constrained to a range) is harder because you need to solve linear inequations at compile-time, which is not a feature of most type systems (though see refined types).

You second example (must call a method) is relatively easy with linear types, as they express "must do something with this value".

Re: Core: an experimental new way to write videogames

#218

Post by sn9 »

smellybigbelly wrote: post #46
sph wrote: 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?

C is basically portable assembly so handwritten C can be as fast as the hardware can allow.

High-level languages like Haskell can and do approach the performance of handwritten C if you encode enough information to get the optimizations for free:

https://stackoverflow.com/questions/35027952/why-is-haskell-...

Re: Core: an experimental new way to write videogames

#219

Post by ertian »

nightowl_games wrote: post #214
ertian wrote: post #125

Earlier quoted context omitted.

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…

> I don't understand the hostility. Saying this while telling me this is the wrong site for me. Nice. My comment isn't hostile. My opinion on this github has value and I am not alone. I could have worded it 'nicely' but if you find every brutally honest comment to be hostile, then maybe this site isnt for you.

I'm not telling you this is the wrong site. I'm suggesting that maybe if you're looking for news on mature, production-ready game development software, with no hobby project tangents, there's probably better places to find it.

And I'm not offended by your 'brutal honestly'. I'm just mystified. You could comment "this is neither production-ready nor industry standard!" on half the posts on this site. Personally, I like being exposed to quirky new ideas, even if they don't always pay off. If I found them actively offensive, I'd have to question why I was wasting my time here.

Re: Core: an experimental new way to write videogames

#220

Post by nightowl_games »

hungie wrote: post #190
Capricorn2481 wrote: post #188

Earlier quoted context omitted.

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.

I'm a Godot contributor.

The 3d renderer is okay, but I'm hesitant to call it good. It's not as good as Unity nor Unreal, imo.

The internal profiler really sucks.

Everything is possible if "some work". Porting to PlayStation 5 is probably a lot of work.

I'm a Godot fan boy, but we gotta be honest about its flaws.

If your targeting 3D on console, definitely go with Unity or Unreal imo.

Post reply on HN