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

121–130 of 224 posts

Re: Core: an experimental new way to write videogames

#121

Post by cpeterso »

panza wrote: post #101
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 a…

How does Godot performance compare using C# versus GDScript?

Re: Core: an experimental new way to write videogames

#122

Post by [deleted] »

breck wrote: post #102

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

[deleted]

Re: Core: an experimental new way to write videogames

#123

Post by ertian »

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?

Mandatory "simple is not the same as easy": https://www.youtube.com/watch?v=SxdOUGdseq4

Clojure vectors are just lists, basically.

"Atoms" are mutable references to immutable datastructures (Clojure is immutable-by-default). You can kinda think of them as pointers, but with specific update semantics.

Transactions are similar to database transactions: mutate several datastructures simultaneously, but only 'commit' the changes if all operations succeed. Roll back and (optionally) retry if any part fails.

Malli schemas are just a way of doing typechecking in a dynamically-typed language.

Datomic is a bigger topic. It's an implementation of a non-SQL database system based on immutable datastructures, in which all changes are appends rather than being destructive, allowing you to 'rewind' the database and view it at any point in the past.

Re: Core: an experimental new way to write videogames

#124

Post by AlotOfReading »

Barrin92 wrote: post #80
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…

>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 pro…

It's not that artificial, it's basically a traditional game loop where mutation happens in the background between iterations. It has many of the same challenges too.

Re: Core: an experimental new way to write videogames

#125

Post by ertian »

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 generation was an ivory tower topic. Hell, every development in 3d graphics started life as a totally impractical paper at a conference. There's a lot of things that are mainstream in games now that were once niche academic notions.

I don't understand the hostility.

Re: Core: an experimental new way to write videogames

#126

Post by bluGill »

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".

Game development can be simple, but the game with either be boring (games with thousands of identical rooms are simple to make), or trivial to finish with no replay value (because there isn't much you can do). In the real world games are all complex as making an immersive world requires complexity.

There are a few games like suduko that are about that are simple and yet have high replay ability. If you can come up with another game on these lines great, but such games tend to be very different from the things. Good luck in making an exception.

Re: Core: an experimental new way to write videogames

#127

Post by frompdx »

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 disagree that GDScript is a poor builtin language. It is somewhere between Python and JavaScript. It gets the job done and there is a lot you can do with it. Signals are great for things like state management. I'm not really sure what you mean by spaghetti code and how signals are supposed to help. I do agree that there are some annoying OOP aspects like providing a path to a scene (module). It's verbose but not unlike library imports in other languages.

Re: Core: an experimental new way to write videogames

#128

Post by bluGill »

vasco wrote: post #53
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?

Have you considered googling "clojure X", where X is each of those things in commas? Other than datomics which has some result pollution everything else has great first page results.

I did, found the clojure docs. Now I'm even more confused. What is so special about clojure vectors - as opposed to a python list, or C array? Some uses in the example seem like a better match to python dict, a C array of structs (linked list of structs?), perhaps a C++ std::map. Depending on what your goal is I know of dozens of different data structures and algorithms (they are part of the basic things a CS major covers) However clojure was called out specifically as if there is something more that is both important to this discussion and non-trival in some way with the way arrays/lists/vectors are implemented in other languages.

Re: Core: an experimental new way to write videogames

#129

Post by panza »

cpeterso wrote: post #121
panza wrote: post #101

Earlier quoted context omitted.

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 a…

How does Godot performance compare using C# versus GDScript?

Not sure. I hear C# is at least as fast if not faster, though there may be situations where GDScript is more performant.

Re: Core: an experimental new way to write videogames

#130

Post by myrryr »

moomin wrote: post #92
NotAnOtter wrote: post #44

Earlier quoted context omitted.

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…

Now I’ve never used it, but there’s always a case with an engine with its own objects to have a language that understands those objects natively. Unreal Engine started out that way.

UE is going to be amazing (It mean it already is, but WAY more so) once verse is integrated into it.

The "so, you have a choice of c++ or drawing lines between boxes" is missing a lot of middle ground :)

Post reply on HN