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

101–110 of 224 posts

Re: Core: an experimental new way to write videogames

#101

Post by panza »

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'm a commercial dev, previously used Unity, now using Godot. This comment rings true of GD Script and signals. I get around this by using C# and its event handling.

Working with nodes and editor bugs (or features? Hard to know really) is probably the most frustrating - you can really feel that this was initially built for 'smaller' projects.

For this reason, I rarely use the editor outside of setting up the scenes and a general hierarchy.

Daily tools: Emacs (with C# LSP) most of the time. VS Code for debugging. Godot editor for tweaking the scene tree.

Perhaps this perspective is useful for other devs thinking about Godot.

Re: Core: an experimental new way to write videogames

#102

Post by breck »

Interesting! I worked on something similar once. I would recommend you go further and try to do this for 3D/4D. Orders of magnitude more interesting! In my efforts, I hit a wall where it wasn't very interesting anymore.

Also, how about clojurescript so you could run this in browsers?

My user test: https://www.youtube.com/watch?v=gcMBaQI7d-c

Re: Core: an experimental new way to write videogames

#103

Post by neonsunset »

sph wrote: post #51
smellybigbelly wrote: post #46

Earlier quoted context omitted.

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?

CPUs are imperative and pervasively mutable. Languages like Rust are able to have so called zero-cost abstractions that are reminiscent of functional programming (iterators for example) but the thing is abstractions are by nature always slower than the real thing. But not all games are AAA FPS that require ingenious optimized codepaths to perform well, not in this day and age, so this is why you see commercial games…

"Cost" in C# comes from the (ab)use of classes for transient data, virtual/interface calls and automatic memory management. Another source of difference is in compiler capability of Unity's own flavours: IL2CPP, Mono and Burst, versus .NET's CoreCLR JIT and NAOT versus GCC/Clang. However, the latter has much less impact on "application code" and more impact w.r.t loop autovectorization, for which in C# you're supposed to use bespoke portable SIMD API which is fairly user-friendly. For the former, you are not "locked" into a particular paradigm like with Java or Rust and can mix and match depending on how hot a particular path is (for example - construct buffer slices with LINQ because there are only 16 of them, but each one is 512MiB large, so do the actual work with Vector).

JVM languages have a huge gap* in low-level capabilities where-as C# sits next to C and Rust in many of the features that it offers, even if the syntax is different. JVM implementations also come with significantly higher FFI cost. This makes them an overall poor choice for game development. Your experience of writing a game engine in pure C#, calling out to rendering and other device APIs will be massively better than doing so in Java/Kotlin/Clojure/etc, because of both runtime capabilities and ecosystem of interop libraries.

Also, C# has zero-cost abstractions in the form of struct generics which are monomorphized like in Rust, and performance-sensitive code relies on this where applicable in "modern" codebases.

* Projects like https://github.com/bepu/bepuphysics2 are impossible to implement on top of JVM without calling out to native components. This might change once the incubating Panama vectors improve upon their API and what they compile to.

Re: Core: an experimental new way to write videogames

#104

Post by Jare »

runeblaze wrote: post #15
kleiba wrote: post #11

I love Clojure, but isn't a functional language with immutable data structures an odd choice for developing a video game?

It's not that weird -- your next AA game or AAA game will probably not use it, but in React (reducer, or Redux), very interactive stuff, immutability is often seen. Also Clojure has better performance prospects than Ruby and Python, both have seen "real" usage in commercial indie games.

It's a lot easier to embed Python than Clojure. Oldest examples I recall are Severance: Blade of Darkness by Rebel Act Studios, and (coincidence, nothing to do with the previous) Blade 2 by Mucky Foot, about 25 and 22 years ago.

Re: Core: an experimental new way to write videogames

#105

Post by jayd16 »

nightowl_games wrote: post #42
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…

As a professional game dev who has years of experience producing real products in both Unity and Godot, I am totally not with you about your thoughts on Godot vs unity. Godots signals are such a huge step up over Unity's built in classes having a lack of modularity. How do you even make sense of that? Godot vs Unity basically have the same scene/node/component model except Godot does it better imo. Eg) What is the di…

Unity is a bit of a mess but to compare apples to apples when Unity has more features seems not quite fair.

Are signals significantly better than Unity events or is it more that the API uses them heavily?

Honestly, why doesn't Unity retool SendMessage() and public API callbacks to be an exposed Unity event? Unlike merging prefabs and scenes, that's not even a breaking change.

Re: Core: an experimental new way to write videogames

#107

Post by TillE »

Thaxll wrote: post #78
nightowl_games wrote: post #42

Earlier quoted context omitted.

As a professional game dev who has years of experience producing real products in both Unity and Godot, I am totally not with you about your thoughts on Godot vs unity. Godots signals are such a huge step up over Unity's built in classes having a lack of modularity. How do you even make sense of that? Godot vs Unity basically have the same scene/node/component model except Godot does it better imo. Eg) What is the di…

GDScript sucks big time, it's not even close to C#. They should drop that Python like language and go full in C# integration.

The core developers are too enamored with GDScript, but that's fine, C# and C++ (GDExtension) support is excellent. There are only a handful of API functions which are hampered by their need to support GDScript, so it's something you can basically just ignore.

You don't even have to use Nodes much, though they're great for lots of stuff. For real performance, you can drop all the way down to their thin wrapper over Vulkan and do whatever you want.

Re: Core: an experimental new way to write videogames

#108

Post by glimshe »

Thaxll wrote: post #78
nightowl_games wrote: post #42

Earlier quoted context omitted.

As a professional game dev who has years of experience producing real products in both Unity and Godot, I am totally not with you about your thoughts on Godot vs unity. Godots signals are such a huge step up over Unity's built in classes having a lack of modularity. How do you even make sense of that? Godot vs Unity basically have the same scene/node/component model except Godot does it better imo. Eg) What is the di…

GDScript sucks big time, it's not even close to C#. They should drop that Python like language and go full in C# integration.

GDScript makes simple things simple and complicated things complicated. It's pretty good for the simple parts of your game. You can still use C# for its complicated parts as they integrate well.

Re: Core: an experimental new way to write videogames

#109

Post by ants_everywhere »

kgeist wrote: post #29

It says game development can be made simple and then throws a whole of jargon at you: clojure vectors, datomics, atoms, transactions, malli schemas... Can someone explain?

Clojure the JVM Lisp language, not closure the concept I think.

A clojure vector is just a vector. Like a Java vector or C++ vector.

The rest seem to be Clojure concepts or libraries. It's a bit disorienting because the language isn't capitalized in the link.

Re: Core: an experimental new way to write videogames

#110

Post by gxd »

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…

Godot is excellent, and I believe it will be the "Blender of game making" in 5 years or so. Version 4 is ready for prime time and is able to tackle most indie projects. Where Unity beats Godot is in the "Triple I" and "Double A" categories, as it has better 3D/performance features, tooling and add-ons. Neither engine is the best choice for AAA projects.

For 2D and simple 3D games, I see no reason to use Unity anymore; I predict a steady decline in Unity's market share as Godot slowly overtakes it.

Post reply on HN