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

161–170 of 224 posts

Re: Core: an experimental new way to write videogames

#161

Post by bowsamic »

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 totally agree for Godot. All the worst mistakes of OOP which I thought we got rid of years ago. Bizarre situation

Re: Core: an experimental new way to write videogames

#162

Post by refset »

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.

Reminds me a little of this Flappy Bird demo which makes use of DataScript's Datalog rules https://frankiesardo.github.io/minikusari/#!/minikusari.tuto...

Re: Core: an experimental new way to write videogames

#163

Post by d13 »

zen928 wrote: post #140
nkrisc wrote: post #100

Earlier quoted context omitted.

The docs have an example of iterating an array backwards: https://docs.godotengine.org/en/stable/classes/class_@gdscri... var array = [3, 6, 9] for i in range(array.size() - 1, -1, -1): print(array[i]) Admittedly not very pretty but it certainly works.

After reading several posts above yours describing the level of effort and pain trying to use this scripting language and how multiple people in this thread avoid trying to use it as much as they can, then reading your small code sample, it's hard to not describe as a level of perception whiplash. "why god why can't they just have for loops!?!?" and the problem was just ... knowing how to foreach over a range correct…

I agree! I use both GDScript and C# with Godot, and GDScript is excellent. But, I’ve been programming for 40 years, and my baseline is “all programming languages are bad” :) All I need is a Turing machine with nice ergonomics and I’m happy. I’m very easy to please.

Re: Core: an experimental new way to write videogames

#164

Post by d13 »

HideousKojima wrote: post #39
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…

>and "signals", which are meant to decrease spaghetti but only increased it for me. Signals are basically just event subscriptions. In fact, if you use C# with Godot you can actually just use C# native delegates/events.

And you don’t need to use signals in Godot at all.

Re: Core: an experimental new way to write videogames

#165

Post by noelwelsh »

spoiler wrote: post #27
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…

> - Bevy (Rust ECS engine), which is nice at first but has a lot of problems with its implementation and can become rather messy. Can you expand a bit about why this was messy or comolicated? I found the paradigm leads to pretty well organised code (sometimes you get the odd large system, but it can be broken down into smaller systems, sub systems or composed out of smaller functions).

I started using Bevy for a small game and abandoned it after a little while.

There are two issues:

1. The fundamental issue is that the ECS model has independent subsystems communicating via a relational database. This breaks the connection between function callers and callees, makes control flow incredibly hard to trace, and means the type system can give you very little assistance.

2. Bevy also does not leverage Rust's type system in other ways. E.g. you can use resources that you forget to create and it will only crash at runtime instead of giving a compile time error.

I think you can create a good game in Bevy, and if you come from a C/C++ world you probably won't notice the lack of type safety. It didn't meet my goals, however.

Re: Core: an experimental new way to write videogames

#166

Post by nkrisc »

galkk wrote: post #158
zen928 wrote: post #140

Earlier quoted context omitted.

After reading several posts above yours describing the level of effort and pain trying to use this scripting language and how multiple people in this thread avoid trying to use it as much as they can, then reading your small code sample, it's hard to not describe as a level of perception whiplash. "why god why can't they just have for loops!?!?" and the problem was just ... knowing how to foreach over a range correct…

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.

Re: Core: an experimental new way to write videogames

#167

Post by kragen »

Buttons840 wrote: post #142
frompdx wrote: post #127

Earlier quoted context omitted.

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

When using the optional typing in GDScript, I'm surprised at how many errors are caught before runtime. The optional type syntax is nicer than Python's and the auto complete is good. Godot could have built on Python, but they would have had to also include a language server (and maybe ipython or jupyter or something) to get the full seamless experience that GDScript gives. Including all that seems a bit much. So, lik…

early versions of godot were actually python modules; they added gdscript because embedding python was taking too much work

Re: Core: an experimental new way to write videogames

#168

Post by kragen »

panza wrote: post #129
cpeterso wrote: post #121

Earlier quoted context omitted.

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.

i haven't tried c# with it, but gdscript is slow, comparable to cpython. intuitively i'd expect c# to be an order of magnitude faster

Re: Core: an experimental new way to write videogames

#169

Post by kragen »

galkk wrote: post #158
zen928 wrote: post #140

Earlier quoted context omitted.

After reading several posts above yours describing the level of effort and pain trying to use this scripting language and how multiple people in this thread avoid trying to use it as much as they can, then reading your small code sample, it's hard to not describe as a level of perception whiplash. "why god why can't they just have for loops!?!?" and the problem was just ... knowing how to foreach over a range correct…

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…

cpython is slow enough that copying the list of keys was rarely a significant bottleneck

Re: Core: an experimental new way to write videogames

#170

Post by seanthemon »

bentt wrote: post #144
seanthemon wrote: post #52

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

That doesn't make any sense. Unity may have a pedigree of being for beginners, but in recent years they can barely keep current documentation on their new systems. This smells like a comment from someone who has never used it.

I haven't used it in the past 3 or so years, but I used to use it quite extensively before that.
Post reply on HN