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

71–80 of 224 posts

Re: Core: an experimental new way to write videogames

#71

Post by [deleted] »

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…

[deleted]

Re: Core: an experimental new way to write videogames

#73

Post by CyberDildonics »

resatori wrote: post #41
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?

A clojure vector is an inbuilt data structure of the language and looks like this: [1 2 3] I am using them to construct side effects which I call 'transactions' (similar to datomic) [:tx/foo 3] where :tx/foo is a keyword and uniquely identifies the component behaviour.

> inbuilt data structure of the language and looks like this: [1 2 3]

array / vector

> construct side effects which I call 'transactions'

setting a variable

> where :tx/foo is a keyword

variable or hashmap

> uniquely identifies the component behaviour

running a function

Re: Core: an experimental new way to write videogames

#74

Post by kitd »

stavros wrote: post #40
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?

To be fair, it asks whether game development can be simple. It just so happens that the answer is probably "no".

Betteridge's law of repo descriptions, or something

Re: Core: an experimental new way to write videogames

#77

Post by deisteve »

thesuperbigfrog wrote: post #21
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 is completely possible and has interesting trade-offs. Here are some of my favorite blog entries related to functional game development: https://prog21.dadgum.com/228.html https://prog21.dadgum.com/23.html https://prog21.dadgum.com/24.html https://prog21.dadgum.com/25.html https://prog21.dadgum.com/26.html

the biggest tradeoff is talent pool

you won't be able to find them in enough numbers and it would be tough to gauge their proficiency too

unless you are purely interested in it for academic purposes, its best to avoid clojure and any sort of esoteric languages. Even Rust development is riddled with false roads and mirages.

i just want to save anyone reading this 5 years of their time. You don't get better when you are constantly having to re-invent the wheel for essentially shaving off roughly 20~30% lines of code you'd write in python, php, ts. It's hardly a fair trade off

Re: Core: an experimental new way to write videogames

#78

Post by Thaxll »

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…

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

Re: Core: an experimental new way to write videogames

#79

Post by raytopia »

lairv wrote: post #49
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…

Isn't pygame closer to SDL or raylib than a game engine ?

Pygame is a wrapper around SDL.

Re: Core: an experimental new way to write videogames

#80

Post by Barrin92 »

sph wrote: post #26
thesuperbigfrog wrote: post #21

Earlier quoted context omitted.

It is completely possible and has interesting trade-offs. Here are some of my favorite blog entries related to functional game development: https://prog21.dadgum.com/228.html https://prog21.dadgum.com/23.html https://prog21.dadgum.com/24.html https://prog21.dadgum.com/25.html https://prog21.dadgum.com/26.html

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…

>a game is nothing more than a function that takes {state, mouse, keyboard} as input and returns {new_state, output}

but that's a completely convoluted approach to identity in a model for a videogame. The reason Rich Hickey took that approach in Clojure to state and identity is because in the domains he cared about he wanted to prevent the destruction of past state. (he wanted to avoid what he called "place based programming" IIRC).

If you want to implement a git like versioning history say, you really care about any change to state as a collection of individually immutable snapshots. But in a videogame that's completely artificial. Nobody thinks about a persistent entity in a game as a collection of states at a million points in time. It's much more natural and performant to think of your entities as persistent and mutable and you basically only care about where they are now.

Post reply on HN