Godot 4.0 will get a new lightmapper
godotengine.org
godotengine.org
Here is my tutorial on using Godot and Rust together - https://medium.com/@recallsingularity/gorgeous-godot-games-i...
Also, I'm making a space factory game. Sporadic updates so far but here is the most recent
https://medium.com/@recallsingularity/space-factory-building...
There is a Discord mentioned in there if you run into any issues with your godot-rust dev, we've got a very active development community there.
Godot also supports GDScript, C#, Python, C++ and more.
Are you sure this is happening? Pretty sure I heard this wasnt happening.
Would be interested to hear if it'd been dropped because I have alternative solutions I can play, just far less convenient.
It likely won't ever directly support consoles. [1]
But yes Godot is awesome and Juan is doing an extremely large public good in terms of education. I've been a gamedev for half a decade and there's still so much to learn, and godot's code base serves as an amazing resource.
EDIT: link
(1): https://docs.godotengine.org/en/stable/tutorials/platform/co...
There's a couple companies out there that will port your game to consoles for you. [1]
https://docs.godotengine.org/en/stable/tutorials/platform/co...
I really like Godot. It's not as full featured as other engines but it feels very logical and clear.
The Switch does support Vulkan but it still leads to the problem of the walled-garden and NDAs which has already been discussed here at length, and also prevents any further abstraction layers for consoles from being developed by anyone besides these approved middleware companies. If the open source aspect is important to you then I would suggest avoiding these walled-garden consoles completely.
I don't think the console manufacturers have many incentives to work too hard on supporting these shared APIs. Their business models make it much more valuable to provide higher performing and more specialized code that works better on their console. And that price generally ends up being pretty small and well worth it for a team maintaining their own engine. And that math only becomes more insignificant the more teams are switching to the main engines such as Unity and Unreal.
I don't think your second paragraph is quite true and it's only because Vulkan is already supported on one of the consoles (Switch) and has been promoted by them for years as a way to make it easier for PC developers to port their games. There are also things like MoltenVK (which was a prime motivator for Vulkan support in Godot) that prove that there is some demand AND that other companies are willing to pay the expense of maintaining it, so it's not something that has to cut into their business model or mess with other products either.
Even if it is now finally supported, most of the game developers I know of are using the NVN backend.
You have to sign agreements with the console manufacturers - they get to set any rules the market will support.
If I were to guess, I'd say it's to prevent both piracy as well as games being sold from 3rd party markets.
On the unofficial side, https://github.com/Stary2001/godot is a godot port that runs on the standard nintendo switch homebrew stack
What do you mean?
Specially small developers that would benefit from such free middleware...
The companies hold the gates to millions and millions of potential buyers. Indies want to sell in all of them and there is no other way for them to do so.
In addition, consider that most indies use Unity/UE, which already support the consoles, so vendors couldn't compete on ease of development even if they wanted.
If Godot was overwhelmingly used by indies, then yes, you could be right.
Considering that Epic, and Unity clearly share their console API code with developers with agreements with MS and Sony it's clear that this is the case (+ or - maybe some exceptions specified in the agreements)
I think the Godot devs have not been clear enough communicating about console support. There are export templates ready to use, up to date and fully working on different consoles. They just can't be offered as part of the open source engine due to legal reasons. That actually applies to other engines too. In the case of Unity, to build for Switch you need to download the required software from the Nintendo Developers portal and it's only accessible to you if you get approved as a developer. If Nintendo wishes to do the same with Godot they can do it know since there are no technical or legal impediments. Since Nintendo hasn't done it so far and the Godot team can't do it for legal reasons, it falls to third parties to do it. One of those is Lone Worlf Technology LLC, owned by one of the co-founders of the engine, so it's as official as it can get. If you don't want to work with them you now have a second option that's called Pineapple Works.
It's not like you have to pay a company to port your game to switch from scratch. I think many people get that idea.
Edit: orthography
Edit2: Just to clarify even further. If you check the process to build for switch using Unreal you'll see that the process is exactly the same as with Godot, the only difference being that in the case of Unreal it's the same company providing the base engine and the switch export tools. https://www.unrealengine.com/en-US/blog/launch-your-game-on-...
Your reply is a really good one because I totally got this impression from the other replies here! So Godot isn't fundamentally incompatible with consoles, it's just the open source part of it that is.
Of course there's still h264, aac, etc.
But to be fair the Play Store definitely has more of such low-quality games.
Yet it is still better than not having a net at all, leading to a bunch of "Hello World" games, half finished game demos, copy cats that dilute branding.
Alone on iOS there are around 3000 submissions per month on average, even taking around 50% away for updates, it still leaves us with an enormous amount of low quality games to triage, per month.
https://www.pocketgamer.biz/metrics/app-store/submissions/
Not even the modern variants of Crash!, YourSinclar, Amiga Format can keep up with such submission rate.
What it does do is make it less expensive to exert total control over the associated branding. This might seem like a good thing for customers if this branding wasn't already for sale to the the highest bidder, but it is. The practice of hardware manufacturers paying for exclusives proves this.
https://en.wikipedia.org/wiki/Video_game_crash_of_1983
Game publishers love exclusives, it means there is no way copy cats land on the same medium.
For example, how Naughty Dog tried to turn Crash Bandicoot into Sony's mascot against Sega's Sonic.
"Crash Bandicoot Co-Creator Andy Gavin: Extended Interview"
https://www.youtube.com/watch?v=pSHj5UKSylk
It is ironic how disparate these kind of discussions on HN feel versus the general themes on game developer forums, magazines and conferences.
Same thing with APIs, on game developer universe "what cool things can I do with it", here "boo yet another way for the man to subjugate us".
I personally have avoided many game development communities for exactly the reasons you describe — overly extreme fear of "copy cats" to the point of paranoia, coupled with way too much enthusiasm to adopt certain pieces of cargo-culted technology without considering the question of who will support it and for how long. I think Godot is a step in the right direction, but it will take these companies time to let go of these other APIs that cost them high prices just for the privilege of being able to read the documentation. They are not immune to these price dynamics.
This is like complaining about what Apple allows or not on their platforms, if you are not happy give your money to someone else.
https://www.gamesradar.com/edge/
https://2020.revision-party.net
Now if you refuse to accept how things work fine, but then do something about it instead of cursing and trolling everyone that actually have experience in the industry.
I don't know, create an association, start a movement or something else.
If no one likes the garbage as you say, it won't be hard to get people to join your cause, after all it takes one person to change the world.
After all you argue against everyone like myself, with games development experience, as apparent in several games related forums on Reddit and who knows where else, and yet don't get anyone to pay attention.
Yes I am perfectly alright defending industry practices, try to offend me won't change anything on the games industry.
If you want to change anything start a revolution, writing comments is easy.
After all I would expect that with such energy we would have seen you at some GDC(E) teaching us the true path, leading the way out of the slavery from game development industry practices.
But no, we get rants on online forums instead.
> we already have enough garbage
That's not an issue of NDAs but discovery (or lack of curation). NDAs may exist as a proxy for some companies, but that's still a separate issue that can be addressed in the vacuum.
They are a gross facimilie of computer. They waste what could be general usage hardware on restricted functionality all for the sake of maintaing total software control to extort maximum profits out of their userbase. And they can only get away with it by having their userbases - the audience they hold captive is pressure on game developers to have to submit to their rule to access their captive audience.
They are a middle men that parasitizes developers and gamers for the utility of "convenience" but its their market dominance that prevents less heinous alternatives from emerging. SteamOS was the closest we saw and even that Valve wasn't willing to invest that much into given its less profitable than the fully proprietary contemporaries.
Take the switch, if you wanted to sell it as an "open" platform my guess is Nintendo would have to price it $75-100 higher. That's a huge shift in what consumers are willing to buy and my guess is it would be a lot less successful as a platform.
But I know for a fact that since launch the Xbone and PS4 were profitable. They were never sold as a loss leader.
Especially now, after all 3 have been out for years, none are losing money. They are all profitable when sold and then infinite money machines by acting as a tax on developers and consumers.
If wide open hardware and appstore was a recipe for success Android would be a clear winner. However if you want to ship a title where you get the most out of the platform and you can rely on the platform to be stable from both HW and SW perspective then curating that space seems to be a recipe for success.
It's be really neat if all the console hardware was wide open, however there's a bunch of hurdles there that tend to lead towards curated platforms being more successful.
The reality of open source in games is we need more engine sponsors from the studios running those engines in order to keep development alive.
Console driven development should also come from the studios, and they should partner with GoDot to enable packs/modules/tools.
Blender successfully navigated this with the open movies project. The game engines need a similar model.
I haven't had time for it lately, but I used to participate in the Godot Wild Jam. It's a great way to connect with other Godot users and test out these new engine features. I highly recommend it for any new Godot users: https://godotwildjam.com/
Then you'll have a great basis to start soaking in GDQuest's youtube channel. GDQuest on youtube is THE place to go to for Godot video tutorials. [2]
(1): https://docs.godotengine.org/en/stable/getting_started/step_... (2): https://www.youtube.com/watch?v=Mc13Z2gboEk
Now I'm very fluent in it, and it's been a JOY. I've been building a game in it for the last month or so and progress so far is very satisfying.
I'm also a fan of HeartBeast on YouTube: https://www.youtube.com/channel/UCrHQNOyU1q6BFEfkNq2CYMA
After that I have watched "Top-down Tank Battle"[2], and I highly recommend it, absolutely brilliant series of tutorials(all of the tutorials on this channel are great). Really helped me to understand all the concepts much better.
For intermediate/advanced tutorials, watch GDQuest. They have a youtube channel[3] and excellent video courses[4]. They are planning to release courses on procedural generation and multiplayer too, I'm really looking forward to watching those.
Finally, a shameless plug - I'm making some tutorials on Godot(alongside with some general Digital Art and Houdini videos). I'm still just getting started, but people seem to like them. The most popular one I've made so far is "Creating Platformer Character Movement in Godot - Wall Jumping/Sliding, Double Jumping, Dashing"[5].
[1] https://www.udemy.com/course/godot/
[2] https://www.youtube.com/playlist?list=PLsk-HSGFjnaFC8kEv6MaL...
[3] https://www.youtube.com/channel/UCxboW7x0jZqFdvMdCFKTMsQ
Light maps only work on non-moving lights and non-moving objects, but they're usually combined with light probes, which are samples of what the shadows would be like in a given chunk of empty space if an object were there. Moving objects can shadow themselves using these.
Light maps can be combined with other lighting/shadow algorithms. For example you might leave out the direct lighting from the most important lights in your scene, and use shadow maps for those instead, so dynamic objects can cast shadows.
I really like democoder Smash's old blog for getting an idea of the graphics coding mindset - https://directtovideo.wordpress.com/ . Another good source of what is possible and what it's named is the yearly Siggraph Technical Papers Trailer.
But it's usually going to come down to learning the names of the techniques used and then finding the papers.
Note if the post author is here, there is a typo in the sentence "In Godot, different scenes can have their own ligthmaps and you can mix and match them however you like."
I'm not affiliated with Godot, just love using it :-)
I think it's exactly why I don't like godot for the same reason I dislike unity, unreal, etc: they're frameworks.
Frameworks are not so cut and dry compared to libraries. Not using a framework is not necessarily a bad idea.
I do get your point but honestly unless you're a big studio or a custom engine enthusiast, there's very few logical reasons not to use a framework.
Again, just a wild guess based on watching that clip, I'm open to corrections!
And from looking at a tutorial it appears to be a retained mode UI.
(runs and hides)
Considering they don't have enough manpower to compete with UE/Unity in raster, would it make sense going for full raytracing now?
That way, when next-next-gen hardware arrives in 2-3 years, they could be on the forefront of editors specialized in fully raytraced games.
I dont know how this makes sense.
Considering they have less manpower, they should make a more cutting edge renderer on unproven, unstable tech?
Full ray tracing is not going be any where near ubiquitous in 2-3 years, mark my words.
The idea is that since there are several years ahead until full raytracing hardware starts to appear, you could focus on that (and a single Vulkan renderer), reducing the manpower needed.
Meanwhile, commercial engines have to focus on current games, rasterization, raster + RT and the myriad of renderers and hardware they support.
Full raytracing is very possible sooner than we may think if approaches like DLSS 2 keep improving.
I thought you were saying they should focus on ray tracing instead of the Vulkan renderer. Saying they should build a vulkan renderer and a ray tracing renderer is a much different statement than what I was understanding, and sounds like a lot to ask for.
Additionally there's a ton of risk in betting on full ray tracing in several years. Given that they are a small team with a small community and small funding, they simply have to hedge there bets, and myself as a user am damn glad they are. Unity going guns blazing on new shit and having things be broken all the time is a huge reason why I switched to Godot in the first place.
A nice thing about godot is that it's code base is very easy to get your hands in to, so if Juan wants to focus on the big stable market with the raster renderer, the community can work on a ray tracing renderer. Juan is exposing an api called RenderingDevice in 4.0 that should enable the community to write their own renderers easier than from scratch.
Raytracing is an extension on Vulkan. I don't understand what you are trying to say. I am not talking about CPU raytracers.
> Additionally there's a ton of risk in betting on full ray tracing in several years.
They are not commercial, so the risk is minimal. That is why Godot is such a good place for that.
> Unity going guns blazing on new shit and having things be broken all the time is a huge reason why I switched to Godot in the first place.
That is true and it is why most games avoid updating Unity if possible. But I feel if Godot had so many features, it would have the same problem too (or worse, given less manpower).
> the community can work on a ray tracing renderer
Juan is the one with financial support. Most people cannot afford to take on a research-heavy, multi-year project on their own.
Nevertheless, RenderingDevice sounds great for research projects and academia!
Not technically wrong, but an incomplete picture. The way that engine renderers are organized right now does not lend them well to raytracing. The Vulkan extension we're talking about requires you to set up completely separate pipelines, use different kinds of dispatches, and different shaders. Very little is compatible, and most "ray-traced" are bodged in there in a weird way -- they're mostly used for single-bounce specular AA, as we only have a very small ray budget.
My original post was precisely about focusing on such a full RT renderer (via Vulkan). I am not an expert, so it may be a dumb idea, but it would be nice to have a FOSS production-quality renderer by the time full RT becomes a thing for more and more games.
I was a little dismayed. It seems like AAA games are also not making a huge amount of use of it either. Despite the RTX name I don't know if it's really ready for prime time, at all.
DLSS 2 and similar techniques help a lot to reduce the number of rays needed. Perhaps by the time of RTX 4000 (what I meant as next-next-gen) we might be able to see full raytracing.
But yeah generally I agree, a game that is already doing AAA amounts of gemeometry and shading, that uses RTX to good effect, is going to need 2080ti in SLI to be still a bit slow.