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

171–180 of 224 posts

Re: Core: an experimental new way to write videogames

#171

Post by andybak »

kasztelan_ wrote: post #85
steeleduncan wrote: post #60

Earlier quoted context omitted.

Godot has supported C# for a while now. There is no need to use GDScript

I wish that was true. I just started rewriting my project from C# to GDScript today so it can run on 32 bit ARM android devices. Let's say I'm not a big fan of the language. Why the hell they decided to not implement normal for loops, was just googling how to iterate an array backwards and most people were like "just invert the array and iterate over it, bro" They should have just used Typescript, it's a sweet spot b…

I presume they do for loops the same way Python does? Which takes a couple of minutes to get used to and is perfectly fine. I wish C# did this more like Python to be honest.

Re: Core: an experimental new way to write videogames

#172

Post by SteveSmith16384 »

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.

Re: Core: an experimental new way to write videogames

#174

Post by Kiro »

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

It's definitely not a "way way better tool" and no serious game developer would say that. Everyone agrees that Godot has a lot of catching up to do but we're still using it because we believe in the foundation and what it will eventually become.

Re: Core: an experimental new way to write videogames

#175

Post by ertucetin »

Kudos to you! I’m happy to see another Clojure developer like me using the language for game development, even though we sometimes make things harder for ourselves :) Currently, I’m developing a 3D multiplayer TPS shooter using Clojure. For anyone interested, here’s a demo link: https://prototype-game.pages.dev

I’ll also be posting a blog post about the journey soon!

Re: Core: an experimental new way to write videogames

#176

Post by bluGill »

sesm wrote: post #134
bluGill wrote: post #128

Earlier quoted context omitted.

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

The key idea behind Clojure data structures is that they are immutable, but don't require a full copy on update, because an updated version partly reuses the initial version. The data structure that enables this is called HAMT (hash array mapped trie). Clojure's implementation modified the initial Phil Bagwell's implementation of HAMT in a subtle way in order to make performance characteristics not degrade over time.

Interesting, it makes more sense now. Though I'm not clear if you want/need that in a video game. In general you want two data structures, one current state of the world and one next state - since they have a lot of similarity it at first makes sense to do what you say, except the you lose the advantage of vector: it is very cache friendly to iterate on a vector, or even two vectors, while it appears (without knowing internal details) that your HAMT is less cache friendly as the next element is not in the next memory location.

Of course I'd need benchmarks to make a real judgement. The above is my gut reaction.

Re: Core: an experimental new way to write videogames

#177

Post by cnity »

ertucetin wrote: post #175

Kudos to you! I’m happy to see another Clojure developer like me using the language for game development, even though we sometimes make things harder for ourselves :) Currently, I’m developing a 3D multiplayer TPS shooter using Clojure. For anyone interested, here’s a demo link: https://prototype-game.pages.dev I’ll also be posting a blog post about the journey soon!

It is one of my favourite things on the internet when a bunch of people can go to a virtual space and hop around and use an in game chat impromptu like this. Thanks for sharing.

Re: Core: an experimental new way to write videogames

#178

Post by makotech221 »

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…

Try out Stride3d. Sorta like Unity, but pure c# engine and much better architecture.

Re: Core: an experimental new way to write videogames

#179

Post by indigo945 »

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…

While that's true, the caveat here is that unlike Python, GDScript does not have a garbage collector. The main performance problem with creating an array copy in a soft-real-time application like a video game is usually not the allocation, but the additional GC pressure, which could cause frame jitter. GDScript does not suffer from that latter problem.

Re: Core: an experimental new way to write videogames

#180

Post by ingenieros »

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…

> Where Unity beats Godot is in the "Triple I" and "Double A" categories, as it has better 3D/performance features, tooling and add-ons

While this is true it does come with a big caveat. Every single AA developer has had access not only to the Unity source code, but in some instances also to Unity employees who became directly embedded in the production cycle. There’s a GDC presentation from the team behind Ori and The Blind Forest where they talk about how some Unity devs were flown to Austria to help out with custom tooling. Playdead also has a really nice blog where they talk about all the changes they had to make to the engine in order to achieve good lighting performance/fps for Inside. https://blog.playdead.com/articles/inside_presentations/insi...

I’m sure that if the Godot foundation had enough resources at hand then you would also see more games like Cuphead and the ones previously mentioned above.

Post reply on HN