Live data from Hacker News

Core: an experimental new way to write videogames

github.com

111–120 of 224 posts

Re: Core: an experimental new way to write videogames

#111

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 gave Godot a good shot. There's reasons not to like it, but IMO GDScript is not it. It's basically python with slot/emit semantics to integrate with the editor, which is actually rather nice, compared to other more complex ways of achieving such integration - via build systems, or some metadata or external configuration files. In Godot it's integrated into the language.

Re: Core: an experimental new way to write videogames

#112
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?

This is common among programmers. They come up with some insane, convoluted set of rules that they happen to like and then declare it simple and elegant. To anyone on the outside it looks schizophrenic in nature. Of course it has a component system. I just hope no one sees this mess and thinks that if THIS is considered simple, videogame development isn't for them.

It looks simple and elegant to me, and I've only used Clojure a little before. Perhaps you're just not very experienced as a programmer in anything except mainstream languages.

Re: Core: an experimental new way to write videogames

#113
> The whole game state is stored in one atom: app/state and entities are again atoms inside the main atom (like in our universe).

I don’t know clojure. Is this normal terminology, ie to use “atom” this way? Seems like a bad name for the concept since the whole idea of “atoms” is that they’re indivisible (back when physics thought they were indivisible).

Re: Core: an experimental new way to write videogames

#114

> The whole game state is stored in one atom: app/state and entities are again atoms inside the main atom (like in our universe). I don’t know clojure. Is this normal terminology, ie to use “atom” this way? Seems like a bad name for the concept since the whole idea of “atoms” is that they’re indivisible (back when physics thought they were indivisible).

They're called atoms because operations on them are atomic, I think.

Re: Core: an experimental new way to write videogames

#115

> The whole game state is stored in one atom: app/state and entities are again atoms inside the main atom (like in our universe). I don’t know clojure. Is this normal terminology, ie to use “atom” this way? Seems like a bad name for the concept since the whole idea of “atoms” is that they’re indivisible (back when physics thought they were indivisible).

Atomic types appear in Java as well, this looks very much like an AtomicReference from a distance: https://clojure.org/reference/atoms

Re: Core: an experimental new way to write videogames

#116

Earlier quoted context omitted.

This is common among programmers. They come up with some insane, convoluted set of rules that they happen to like and then declare it simple and elegant. To anyone on the outside it looks schizophrenic in nature. Of course it has a component system. I just hope no one sees this mess and thinks that if THIS is considered simple, videogame development isn't for them.

It looks simple and elegant to me, and I've only used Clojure a little before. Perhaps you're just not very experienced as a programmer in anything except mainstream languages.

[flagged]

Re: Core: an experimental new way to write videogames

#117
post #91

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

Also Moonring. Not as huge as Balatro, but fairly well-known too.

Re: Core: an experimental new way to write videogames

#118
post #17

Earlier quoted context omitted.

I find it very natural to work with because clojure is based on the JVM so the project uses libgdx under the hood (deploys to all platforms, huge library) and I can use lisp for everything else to do basically anything. Combined with clojures way of handling immutable datastructures so well & the excellent protocol system ( https://www.freshcodeit.com/blog/clojure-protocols-and-the-e... ) I could separate the whole g…

Sorry, but I feel like your comment does not actually address my concern of whether having to deal with immutable data structures in a functional way would lend itself especially well to video games. Of course, the Clojure approach is great for a lot of use cases, but video games traditionally do a lot of mutable changes to components. That doesn't mean, of course, that it cannot be done any other way, but it would c…

It's important to keep in mind that Clojure uses persistent data structures. It's easy for folks with a background in other languages to assume that immutable data structures require a deep copy to modify when in fact they don't.

In my experience, it slightly favors wide rather than deep game state because wide game state implies fewer nodes that need to be re-created when creating a new state. Since the author is using ECS, it's probably wide enough already.

A bit more in the weeds and if one was using a deep game state, careful structuring of assoc-in and update-in calls might be warranted. Ideally each node would only be copied once to arrive at the next game state. Sometimes it can be more efficient to build a list of changes and then property sequence the application of the changes to the state.

At the end of the day, people don't have to use a single atom like the author either. A game state can consist of multiple mutable data structures. It's not like the Clojure-police are going to arrest anyone for it.

Re: Core: an experimental new way to write videogames

#119

To be honest I think this project actually failed. It is an overengineered mess and lacks any kind of clear structure. The main problem is total lack of specification - because I didn't come up with a story for the game or I think games maybe don't need stories. So I just coded like a maniac because it's just fun to code in clojure

To be fair, a lot of successful projects are an overengineered mess and lack any sort of clear structure.

Kudos for trying something cool, this is a space a lot of people are interested in. Thanks for sharing it.

Re: Core: an experimental new way to write videogames

#120

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

> Godot is objectively a way way better tool If you like things like Godot, Godot is the type of thing you will like. Seriously though, Godot works way better for me using C# than it does with GDScript and the OOP structure means I can refer to classes by their identity.

[deleted]
Post reply on HN