Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Godot Engine – A decade in retrospective and future

godotengine.org

Post reply on HN
Print view View original

141–150 of 168 posts

Re: Godot Engine – A decade in retrospective and future

#141

Post by wastedhours »

lwb wrote: post #95
Sindisil wrote: post #88

Earlier quoted context omitted.

> that it'll be around for the next few years. How is continuing development not "support"?

Continuing development is continuing development ... support is answering questions on forums, responding to issues on github, community management, that sort of thing.

I could be wrong, but I believe that's what they mean when they say they hired a "generalist" this year to help cover off those things. It's not a direct 1:1 of "I pay, I get support", but donating will be intrinsically linked to it and seems part of their overall plan for the future.

Re: Godot Engine – A decade in retrospective and future

#143

Post by vanderZwan »

MH15 wrote: post #124
ljm wrote: post #53

Earlier quoted context omitted.

A real draw for me is working with C++ in it, since both Unity and Unreal appear to favour managed languages (C#, some JS variant, some weird Python style thing, etc.) No real reason for preferring C++ except I want to learn it, and my pet project is a little game rather than yet another web app/thing that renders DB records to HTML/thing that takes one JSON blob and turns it to another. I never did computer science…

> yet another web app/thing that renders DB records to HTML/thing that takes one JSON blob and turns it to another Ouch, this is currently my "pet" project. I totally get what you mean though. I'm honestly not sure if it can even considered a pet project anymore, as it works way better than I expected.

I think it's a rehash (conscious or not) of Thomas Figg's famous "Webapps, or as I like to call them: Skins around databases."-joke that he used in his "Programming is terrible—Lessons learned from a life wasted" talk from many years ago.

It's no longer completely true, but honestly it's still kind of true. And I've been making my living writing them for years now ;)

[0] https://www.youtube.com/watch?v=csyL9EC0S0c

Re: Godot Engine – A decade in retrospective and future

#144

Post by shmerl »

pjmlp wrote: post #127
shmerl wrote: post #99

> The new rendering architecture will also allow companies working on console ports to more efficiently port the engine and offer our users the possibility of running their games on the most popular game consoles (something we will, unfortunately, never be able to offer officially due to legal reasons, thus forcing us to cooperate with companies porting it on their own). I didn't quite understand that part. What lega…

Their console APIs already offer the lowlevel control from Vulkan and are much older than Vulkan, so no, it is not from the begining.

It's not lower than Vulkan (Vulkan pretty much matches GPU functionality already). Lower would be GPU assembly or machine code.

And older isn't the reason not to offer Vulkan for developers. Nintendo managed to figure that out. So it's not "no", unless they are dumb and stuck in extreme lock-in mentality.

Re: Godot Engine – A decade in retrospective and future

#145

Post by arminiusreturns »

arminiusreturns wrote: post #14

I've been using godot for about a year now, and really like it. I am really excited about the upcoming vulkan renderer which should help with my main gripe which is no ambient occlusion. Some people have found some novel ways around it but I am choosing to just focus on my gltf assets and work on my blender skills in the meantime. Linux native gamedev is possible!

*occlusion culling not ambient occlusion

Re: Godot Engine – A decade in retrospective and future

#146

Post by pjmlp »

shmerl wrote: post #144
pjmlp wrote: post #127

Earlier quoted context omitted.

Their console APIs already offer the lowlevel control from Vulkan and are much older than Vulkan, so no, it is not from the begining.

It's not lower than Vulkan (Vulkan pretty much matches GPU functionality already). Lower would be GPU assembly or machine code. And older isn't the reason not to offer Vulkan for developers. Nintendo managed to figure that out. So it's not "no", unless they are dumb and stuck in extreme lock-in mentality.

Over 50% of games on the Switch use Unity, with the remaining ones using Unreal or in-house middleware built on top of NVN.

Very few Switch titles actually use Vulkan.

Just like GL ES 1.0 on the PS 1, it is more a box to tick than anything else.

Re: Godot Engine – A decade in retrospective and future

#147

Post by shmerl »

pjmlp wrote: post #146
shmerl wrote: post #144

Earlier quoted context omitted.

It's not lower than Vulkan (Vulkan pretty much matches GPU functionality already). Lower would be GPU assembly or machine code. And older isn't the reason not to offer Vulkan for developers. Nintendo managed to figure that out. So it's not "no", unless they are dumb and stuck in extreme lock-in mentality.

Over 50% of games on the Switch use Unity, with the remaining ones using Unreal or in-house middleware built on top of NVN. Very few Switch titles actually use Vulkan. Just like GL ES 1.0 on the PS 1, it is more a box to tick than anything else.

It doesn't matter what they use. We are talking about engines themselves here, like Godot. And they shouldn't be wasting time and resources working around lock-in stupidity. Offering Vulkan for developers is the right thing to do for every platform.

I.e. targeting Switch for them aligns well with their current Vulkan work. Targeting PS or Xbox - not really, they'll need to rely on translation (like gfx-rs), if one even exists. I'm not sure if anyone implemented Vulkan → GNM translation yet.

Re: Godot Engine – A decade in retrospective and future

#148

Post by pjmlp »

shmerl wrote: post #147
pjmlp wrote: post #146

Earlier quoted context omitted.

Over 50% of games on the Switch use Unity, with the remaining ones using Unreal or in-house middleware built on top of NVN. Very few Switch titles actually use Vulkan. Just like GL ES 1.0 on the PS 1, it is more a box to tick than anything else.

It doesn't matter what they use. We are talking about engines themselves here, like Godot. And they shouldn't be wasting time and resources working around lock-in stupidity. Offering Vulkan for developers is the right thing to do for every platform. I.e. targeting Switch for them aligns well with their current Vulkan work. Targeting PS or Xbox - not really, they'll need to rely on translation (like gfx-rs), if one ev…

Except that isn't what gets spoken about on GDC corridors, rather IP business opportunities.

Re: Godot Engine – A decade in retrospective and future

#149

Post by vanderZwan »

FartyMcFarter wrote: post #94
vanderZwan wrote: post #71

Earlier quoted context omitted.

Conway's Law (which of course is not really "law") would suggest the last option is the most likely. Given that other game engines don't really have this issue the other two options seem less likely to me too. [0] https://en.wikipedia.org/wiki/Conway's_law

Unity does have a lot of offices in different cities, maybe you're on to something.

Oh, really? That can't be good for development. Other companies at least have different projects for different teams but since Unity is really one big umbrella project that is bound to get messy with that set-up

Re: Godot Engine – A decade in retrospective and future

#150

Post by ljm »

DonHopkins wrote: post #109
forgotpwd16 wrote: post #108

Earlier quoted context omitted.

Unreal has dropped their scripting language for a visual alternative called Blueprints. It is possible to make an entire game with it not writing any C++ and is possible to make one completely in C++. The best is of course using them together. And exactly the same applies to Godot. Just swap Blueprints for GDScript a Python-like scripting language. In a final note Unity, has dropped JavaScript. Though C++ can somehow…

> In a final note Unity, has dropped JavaScript. The thing that Unity dropped wasn't really JavaScript, and nobody in their right mind actually used it. It was called "UnityScript", and it was just a thin veneer over CLR that looked a bit like JavaScript, but exposed the CLR object model and C# APIs to arrays and dictionaries, etc, instead of supporting standard JavaScript APIs. The biggest problem was that most Java…

Oh, thank god Boo is gone. I thought that and the UnityScript looked odd. It just seemed weird in general to not use C#.
Post reply on HN