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

141–150 of 224 posts

Re: Core: an experimental new way to write videogames

#141

Post by mirashii »

SoothingSorbet wrote: post #136
Thaxll wrote: post #78

Earlier quoted context omitted.

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

What "sucks" about it? Since they added type checking it's been perfectly fine, besides the notable omission of nullable types (which is... a strange omission, to be sure).

No tuples. No structs. No real debugger. Extremely limited profiling tools. Autoformatting breaks code more often than not. No interfaces. Extremely weak async story. No refactoring tools, external IDE features like jump to definition. Built in editor is slow and buggy. No destructuring assignment, no enumerate for loops, no looping over key and value together from a dict.

GDScript is, in my opinion, unsuitable for anything more than a couple hundred lines at most.

Re: Core: an experimental new way to write videogames

#142

Post by Buttons840 »

frompdx wrote: post #127
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 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, like you, I appreciate GDScript and have sympathy for why it was created.

Also, GDScript hasn't done anything like implicit type coercions (see JavaScript) and so GDScript can improve without breaking backward compatibility. If needed, breaking backwards compatibility in GDScript won't be as bad as breaking backward compatibility in a real programming language, so they can steer it where it needs to go for the benefit of Godot.

Re: Core: an experimental new way to write videogames

#144

Post by bentt »

seanthemon wrote: post #52
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 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.

Re: Core: an experimental new way to write videogames

#145

Post by the_gorilla »

Supermancho wrote: post #64
r-w wrote: post #54

Earlier quoted context omitted.

Godot lets you use whatever language you want. C# included.

https://github.com/Godot-Languages-Support/godot-lang-suppor...

I don't use godot and know more about its limitations than its advocates in this thread. Are they being disingenuous? Do they just not know basic information about their own tools?

Re: Core: an experimental new way to write videogames

#146

Post by panza »

mirashii wrote: post #141
SoothingSorbet wrote: post #136

Earlier quoted context omitted.

What "sucks" about it? Since they added type checking it's been perfectly fine, besides the notable omission of nullable types (which is... a strange omission, to be sure).

No tuples. No structs. No real debugger. Extremely limited profiling tools. Autoformatting breaks code more often than not. No interfaces. Extremely weak async story. No refactoring tools, external IDE features like jump to definition. Built in editor is slow and buggy. No destructuring assignment, no enumerate for loops, no looping over key and value together from a dict. GDScript is, in my opinion, unsuitable for a…

I agree with this. I suspect it's part of a more general Godot philosophy that involves full in-editor workflows with highly detailed scenes, many nodes, and with small scripts attached to all of them.

Re: Core: an experimental new way to write videogames

#147

Post by sigseg1v »

boredtofears wrote: post #138
vyrotek wrote: post #91

Earlier quoted context omitted.

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

Loved that I could open up balatros game files and examine the source. Pretty cool how far the author took the framework.

I had similar fun with Don't Starve when I opened up some files in the game directory and noticed they were all Lua, all using an ECS system, and easily extensible. Having never used Lua before, I made a rudimentary multiplayer server for it by opening a socket and sending game events to another instance of the game on another machine. I planned to actually start making it into a multiplayer mod but then they announced Don't Starve Together and I scrapped my implementation for obvious reasons.

Re: Core: an experimental new way to write videogames

#148

Post by yumaikas »

gxd wrote: post #110
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…

Godot is excellent, and I believe it will be the "Blender of game making" in 5 years or so. Version 4 is ready for prime time and is able to tackle most indie projects. Where Unity beats Godot is in the "Triple I" and "Double A" categories, as it has better 3D/performance features, tooling and add-ons. Neither engine is the best choice for AAA projects. For 2D and simple 3D games, I see no reason to use Unity anymore…

In the GMTK game jam, there was a -dramatic- shift usage towards Godot from Unity this year

Re: Core: an experimental new way to write videogames

#149

Post by pjmlp »

jsheard wrote: post #38
pjmlp wrote: post #31

Earlier quoted context omitted.

A side effect from specific platforms not allowing Java, and Microsoft buying Mojang. Notch surely isn't sorry for having coded it in Java.

It worked out for Notch, sure, but most indie devs don't get the luxury of only considering console ports after they're already set for life from initially only releasing on PC. Planning for cross-platform from the start is table stakes, especially now the Switch has become just as if not more of a popular platform for indie games than PC is.

Most indie devs already strike gold if they manage one platform at all.

Too much is wasted on what language, or engine to use, instead of what actually make as a game.

And even when everything is done right, it is a drop in the ocean of daily released titles.

Re: Core: an experimental new way to write videogames

#150

Post by johnnyanmac »

sesm wrote: post #137
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?

Clojure the language has a built-in state management model, which this project attempts to apply to game development. The best way to learn about this model IMO is to watch the talk 'Are we there yet' by Rich Hickey (author of Clojure).

Well Balatro didn't so it's not hopeless.

I don't think gamedev was ever simple, but I do believe the process can be streamlined. From my experience the biggest choke point (outside of keeping everyone aligned properly) is asset production. Arguably the most important aspect to make games sell, but the 3d asset pipeline has only gotten more complex.

If you can streamline on that (and stay lean as a team) I imagine you can dramatically shorten development.

Post reply on HN