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

191–200 of 224 posts

Re: Core: an experimental new way to write videogames

#191

Post by filoeleven »

bluGill wrote: post #132
deisteve wrote: post #81

Earlier quoted context omitted.

Coming from clojure I'm very wary of any non-mainstream languages like Elixir, Rust, Clojure etc. It's a costly business mistake to build your tech stack using any of the above languages. The trade off simply is not significant enough to matter vs using mainstream languages with 10,000x the number of mindshare.

The cost is not paid today, but in the future when whatever you choose is no longer supported. If you write in something like C++ or Java running on Linux or Windows I'm confident that in 20 years you will find a tool that can build your code for the latest computers (not just the compiler, but the other tools as well). Of course Python 2 is a perfect example of why even the highest confidence choices may be wrong. R…

The other two languages GP mentioned, Elixir and Clojure, run on the BEAM and Java virtual machines respectively. I can’t speak to BEAM/Erlang, but your confidence that the JVM isn’t going away should remove any concerns about Clojure being supported in 20 years. It’s just a Java library, and has the same conservative approach as Java of ensuring backwards compatibility.

Clojure won’t necessarily live as long as the JVM does, in that the language could someday be abandoned, but support for its hypothetical last language version won’t be somehow removed from the JVM.

Re: Core: an experimental new way to write videogames

#192

Post by bluGill »

filoeleven wrote: post #191
bluGill wrote: post #132

Earlier quoted context omitted.

The cost is not paid today, but in the future when whatever you choose is no longer supported. If you write in something like C++ or Java running on Linux or Windows I'm confident that in 20 years you will find a tool that can build your code for the latest computers (not just the compiler, but the other tools as well). Of course Python 2 is a perfect example of why even the highest confidence choices may be wrong. R…

The other two languages GP mentioned, Elixir and Clojure, run on the BEAM and Java virtual machines respectively. I can’t speak to BEAM/Erlang, but your confidence that the JVM isn’t going away should remove any concerns about Clojure being supported in 20 years. It’s just a Java library, and has the same conservative approach as Java of ensuring backwards compatibility. Clojure won’t necessarily live as long as the…

> support for its hypothetical last language version won’t be somehow removed from the JVM.

Why not? Python2 is a good example - if they make a JVM2 without the cruft and then a transition they will leave behind those that don't transition. Of course that is the worst case and I'll admit unlikely.

(also the JVM isn't very relevant to me because I work in embedded systems without a JVM)

Re: Core: an experimental new way to write videogames

#193

Post by IX-103 »

SteveSmith16384 wrote: post #172
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 not sure why you were using Inheritance in Godot? Just use the "gameobjects" paradigm as you did with Unity.

If you need to customize the behavior of certain interactions (such as modifying physics with a specific type of object), you need to subclass since some behaviors are only available as overrideable functions, not as signals. Also the documentation tends to push this approach.

Re: Core: an experimental new way to write videogames

#194

Post by filoeleven »

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…

> you basically only care about where they are now.

You care about what they are doing now, and what they should do on next render based on the rules of the game and the player’s input. To me, that looks a lot like (state, actions) => newState.

I’m not sure how much of a difference there really is between having objects track their own state vs having them pull their state from somewhere in a single State tree. The advantage to the latter approach IMO is that it simplifies cross-cutting concerns (“player deals bonus damage when all enemies are affected by poison”), and it helps immensely with debugging to be able to query the exact, full game state whenever it’s needed.

My brain has been rewired to find FP easier to reason about than OOP. This won’t be true for everyone, and it isn’t always the right tool. I think it works well for game dev but can be held back by performance concerns.

Re: Core: an experimental new way to write videogames

#195

Post by CyberDildonics »

kleiba wrote: post #24
virtue3 wrote: post #22

Earlier quoted context omitted.

the issue with JVM/java was always that when that GC triggers you are just absolutely hosed. C# tends to be a bit more forgiving about when it triggers GC and how. The generational garbage collector in C# will tend to be more reliable or at least I never ran into super huge issues with the places I've used C# for game dev. The JVM GC has this unfortunate effect of having very bad pauses occasionally. And appears to d…

Minecraft is written in Java, it doesn't look like the choice of platform kept it from becoming a success.

Minecraft was known for allocating and freeing hundreds of megs of memory every frame. It was able to be written in java and have huge performance problems because it was so simple and low res.

Re: Core: an experimental new way to write videogames

#196

Post by galkk »

nkrisc wrote: post #166
galkk wrote: post #158

Earlier quoted context omitted.

I disagree. The doc states that range function returns an Array, so it looks like to iterate backwards you basically allocate array of indices and use those indices to get values from an original array. Not much better than reverting original array, if you will ask me. Maybe there is some optimization for trivial scenarios, but the referred doc doesn’t mention it. It really looks like python 2 case when you needed to…

This is one of GDScript’s right spots for sure. But if this is the performance bottleneck (in a dynamic scripting language) you’re facing, then maybe that bit of code should just be a GDExtension, written in C++. I would imagine for most games the performance impact from this won’t matter much.

The problem in this case is not the potential performance bottleneck, but the bad ergonomics for a dev, that leads to the complain. The rest is consequence.

And to me it looks like pure language/stdlib problem. Like for me, the proposed solution looks ugly both from syntax and what is going on behind curtains perspective.

I would rather not to code in a language that makes/tolerates decisions like that.

Re: Core: an experimental new way to write videogames

#197

Post by PcChip »

osense wrote: post #154
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…

I recommend trying Zenject in Unity! It provides a pretty good dependency injection framework, but more importantly in reply to your comment it has a very easy to use signal bus implementation! Now I have not tried Godot so I don't know how the two compare, but for where I work Zenject was basically the a-ha moment that made it possible to develop Unity apps/games that don't devolve into a huge unmaintanable mess.

I thought everyone was abandoning unity after their fiasco

Re: Core: an experimental new way to write videogames

#198

Post by filoeleven »

bluGill wrote: post #192
filoeleven wrote: post #191

Earlier quoted context omitted.

The other two languages GP mentioned, Elixir and Clojure, run on the BEAM and Java virtual machines respectively. I can’t speak to BEAM/Erlang, but your confidence that the JVM isn’t going away should remove any concerns about Clojure being supported in 20 years. It’s just a Java library, and has the same conservative approach as Java of ensuring backwards compatibility. Clojure won’t necessarily live as long as the…

> support for its hypothetical last language version won’t be somehow removed from the JVM. Why not? Python2 is a good example - if they make a JVM2 without the cruft and then a transition they will leave behind those that don't transition. Of course that is the worst case and I'll admit unlikely. (also the JVM isn't very relevant to me because I work in embedded systems without a JVM)

You wrote above:

> If you write in something like C++ or Java running on Linux or Windows I'm confident that in 20 years you will find a tool that can build your code for the latest computers

What I wrote was based on your confidence in Java (the language) being around in 20 years. One of Java’s core features is backwards compatibility. Clojure’s implementation will continue to work as long as Java (the language) itself exists. There’s too much business depending on old Java software for the language to break like Python3 did.

Clojure is also a hosted language by design, and has been ported to JS, .NET, and BEAM (though maybe not completely on that one). If JVM2 were to come out, and if it supported garbage collection, it’s likely that porting it will be easy enough for someone to handle the task of transitioning the JVM1 build to JVM2. Implementing a lisp is not a rare hobby, and IMO Clojure’s language design makes it a particularly tasty flavor of lisp.

Re: Core: an experimental new way to write videogames

#200

Post by ertian »

NohatCoder wrote: post #184
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…

To me at least, the great value of this site is that people can and do write their honest opinion. Maybe the style of the parent comment wasn't that good, but I agree with the take that there does not seem to be much of value in the project, it enables a style of game that has been done to death by amateurs and indies, and there are probably better tools out there for making that kind of game as well. Braid features…

> it enables a style of game that has been done to death by amateurs and indies

What style of game is that? I guess RPG? I think that's just because it was a convenient way to demo the concept.

The two interesting things about this, AFAICT, are that it enables mutable state during development in an interesting way, possibly allowing for repl-driven development of running games. That's neat. Like, play the game, get to a point where (for example) the game balance isn't right, and pop into a REPL to make adjustments. And possibly, rewind and replay the scenario in the process to try alternatives, which is related to point 2:

If this is using a datomic-style model, it's presumably keeping an immutable history, allowing for both an interesting development environment (where you can play, rewind, adjust, replay, etc) and interesting new gameplay possibilities.

I don't think anybody is suggesting that game devs should immediately jump on board and start developing on this platform. Again: I don't get the hostility. "Hey, here's a neat little game engine based on unfamiliar concepts." "That's dumb, nobody could develop a AAA game on that today, you should be ashamed for posting it!!" Just...chill out a smidge.

Post reply on HN