*kill Unreal Engine*

*kill Unreal Engine*

Attached: Godot-logo-para-news.jpg (654x468, 37K)

Other urls found in this thread:

godotengine.org/article/dev-snapshot-godot-3-1-beta-11
godotengine.org/article/optional-typing-gdscript
twitter.com/NSFWRedditGif

It's killing gamemaker but it shares little with unreal.

I downloaded it yesterday mainly because it's FOSS and you can deploy your shit on many platforms.

3.1 is almost here boys

godotengine.org/article/dev-snapshot-godot-3-1-beta-11

I think Epic/Tencent is killing UE...

Name me at least one (1) well-known game made with Godot

Phoenix Wright: Trials and Tribulations

Attached: 1519112213360.jpg (372x372, 16K)

Brainlet here: Is godot even an option for me?

I laughed, thanks

I actually want to try using it to work on a game idea I had. Not sure if it will be any fun or how I'll do all the sprites since I am not an artist.

Attached: 043932489ab9d1f9d76d8cb7c3c516c15110d741.jpg (745x1000, 803K)

If you know you are brainlet then you are only half-brainlet. If you are able to learn you can do it. It's not hard just takes time

Yeah but I'm a brainlet so won't learning unity be easier? I just want to get to making games, not spend years learning python or whatever

>I just want to get to making games
Go straight to Unreal dude. Blueprint is the shit, it's like mario maker, you just need basic understanding of coding logic and time

Blueprints are literally just regular coding with a dumb interface, it won't make devving any easier.

Maybe, but youtube tutorials for making things with blueprints will go straight to the point when you'll struggle to find tutorials for basic stuff with regular code. If you just want to mess up with 3D models / create menus, just copy/paste, it's just 20 minutes on youtube

why are indie devs so stupid
like i've genuinely heard faggots here make the claim that writing shaders is engine work
what the actual fuck
and the fact that people actually use shit like blueprints just boggles the mind

t. advanced c++ programmer currently learning lockfree programming

I really don't like their shitty node system. The mental gymnastics you have to go through to make a fucking projectile is absolutely ridiculous.
I had to watch a confusing 20 minute tutorial and then had to keep going over it for another half an hour to actually do the same thing, ending up with a result that's not even close to what I want, is fucking confusing as fuck with all the goddamn connections it has, which is hidden in one of 4 different "node property" menus & a fucking extra bloat script file.
On the other hand it took me fucking 5 minutes to write that shit in monogame (a fucking framework that only renders pictures you give it at location you have to exactly calculate through a camera and stuff) of all things.
The engine was also buggy as fuck (3.0) and for the little time I worked with it (about 2 weeks), it has crashed multiple times (about once every hour) for no apparent reason.
Working with their tilesets nodes was also one of the fucking buggiest shitfests I ever encountered.
Last but not least, the fact that there are so many fucking nodes, and that there is little to no documentation on them other than a 20 minute youtube tutorial from some french faggot is more than enough for me to just move to monogame or similar frameworks entirely.
Anyone who praises this thing has either never actually worked with it or has only done tutorial projects rather than making something new.
Kind of a shame though, since the rendering seems pretty good. If I had the time (or if they had some fucking documentation) to go over their code files and just use the engine like that, then it would probably be god tier.
tl;dr godot's node system sucks dick if you actually know how to code

>currently learning lockfree programming
so you're not making any game, eat shit

I have been working with it for years and your complaints are either completely wrong (constant crashing shouldn't be happening and all nodes have documentation for example) or just newbie filters like the node system which is fine when actually bother learning it.

the famous non-programmer moron who thinks he can make video games victim complex shows itself again
how about you kill yourself /agdg/ retard

Indie devs don't care about code, modern machines are fast enough for bruteforcing their shit, same with web devs. No hardware constrains breed lazyness.

it's not even about performance though, if you don't write shaders your game's going to look like shit

>you have learn an useless godot script language to use-
*revives Unreal Engine*

>for years
Show me stuff you made then, I'm genuinely curious.
Whatever I did or tried, it always felt like I was pushing shit into the asshole of the engine and doing workarounds for things that should be simple.
Implementing wall jumps is a fantastic example. No matter what I tried, the node system completely prevented me from properly detecting whether or not I was attached to a wall or not and I had to do retarded shit like making an extra hitbox that's slightly bigger than the player in order to detect it, but this in turn completely fucks over everything since now you need to make an extra hitbox like that in all 4 directions because you of course want to differentiate between the floor, left walls, right walls and ceiling, turning your code into one big bloated mess.

It's almost exactly like python and UE4 doesn't have a real script language either.
>but C++
No, UE4's C++ is an abomination full of abstractions, meanwhile in Godot you can just use C# or literally any other language with GDNative if you are one of the morons who think learning new language syntaxes is the same as learning your first programming language.

Even better, game looks like shit and runs like shit.
And we still have to use API to comunicate with GPUs.

gdnative is a massive fucking pain in the ass to set up

Yikes, artists don't need you anymore, cope.

Attached: 1541161140257.jpg (455x427, 78K)

KinematicBody2D's automatically detects walls, floors and ceilings, you can look at all the node's functions in the engine or the docs and how the bools are updated, and you can look at the source if you are interested in learning how they implemented it.

50% of people are completely incapable of learning to program
those 50% of people are objectively inferior
sorry

>I dropped this thing in two weeks after failing to do literally anything with it
>am I just a retard? No it's the engine fault and now I know everything about the engine despite saying I don't have any experience with it!
You aren't ready for gamedev, sorry bud.

come back when there's a game made with it

so you've never actually made anything, huh

Yes, please completely ignore the fact that I was able to code everything I wanted in less time in a framework with less than 1% of the features godot offers.
Great post, thanks for sharing your well educated opinion.

Your second post was you complaining about not being able to do something the engine already does for you, I don't think you're knowledgeable enough to talk about the engine's strengths and weaknesses other than maybe retard-unfriendliness.

There are people making 15k/month for furry porn. Those could pay 2 programmers full time to make a shitty game about fucking dogs
sorry

programming is fun, retard
it must be sad not being able to enjoy it

Also you could use direct space states to do raycast or shape queries in case you want specific kinds of detection without spamming collision nodes, this is all written in the tutorials.

Imagine to fall so low you are codemonkey for some furfag.

Seeing your game over is double the fun.

Attached: 1414280199339.png (643x768, 522K)

The only fun part of gamedev is the initial alpha stage where you are just building up the systems and testing the fun stuff out, everything after that is pure hell.

I just went and looked at the code I wrote and noticed I did in fact know that. I sort of forgot what it actually was I was having trouble with, but I think it was not being able to detect what kind of type the wall I was colliding with was, given that I was in fact colliding with it.
Blame my incompetence all you want, but godot's documentation was (about half a year ago) absolute trash. If you think the documentation is "good", then I invite you to go look at documentation of almost anything else.

nope
once a game's done it's done
programming is fun forever
in fact it's the most fun thing ever

Unreal cucks BTFO.

Attached: 1367523753992.jpg (465x550, 56K)

I think the only part of the wall detection that might be confusing is how you need to set a floor normal or else it automatically assumes it's a topdown game where everything is walls, but that's already told in the class reference.
I also use a lot of UE4 and I'd say Godot's docs and class ref is a lot comfier while UE4 can a weird maze of deprecated features despite being powerful, I think Godot is best for 2D while UE4 is best for 3D overall but UE4 takes a lot more effort to learn properly.

Do you think it's managable to make 2D RTS/Sim in Godot?

Attached: aybabtu.png (220x147, 38K)

What else does gamedev even encompass past building systems and testing things, and why is it hell?

It should be fine but don't expect your first game to be halfway competent no matter what engine you make it in, the scripting language isn't blazing fast but it has its own pathfinding class running on C++ which should take care of the heavy lifting related to RTSes and if some other bottleneck comes along you can just code your own C++ module to take care of that too.
There's an RTS tutorial on youtube but I don't know how good it is, my rule of thumb is to never take everything you see on youtube vids at face value since it's always full of retards that barely know what they're doing but think they can teach others.

Based

Another thing is that most gamedev and programming concepts can apply to any engine with the right translations between syntaxes and engine structure so don't try too hard to find specific engine tutorials and instead broaden your horizons to general programming tutorials if you are struggling with something, don't fall for that "learn just enough to implement this one feature" trap where you barely even know what you're doing most of the time, and instead focus on having a good foundation so you aren't constantly struggling.

Making a game on godot, only complaint I have so far is that dynamic typing makes typos a bitch since you won't see them until runtime. Tried to test some systems, and had to run and then the scene a bunch of times until I finally fixed all the add_child calls I had typed as addChild, which would invariably crash the whole project.

Nah i expect lots of trial end error.
Also should i build my asset base first, even if they are placeholders?

3.1 will have optional static typing, I haven't tried it yet but it seems to have a lot of niceties.
godotengine.org/article/optional-typing-gdscript

it's called duck typing, dynamic typing is something else, and it's is only beneficial to idiots
there's a reason no one familiar with type theory thinks it's a good idea

*duck typing is only beneficial to idiots

That's what I am doing. I was testing the kinematicbody2D in certain scenarios, like walking along sloping platforms that are moving very fast and sporadically. I found them lackluster and was difficult to keep the player nice and tight on the platform.

What I am instead doing is using the raycast method similar to the one in Sebastian Lague's Unity platformer tutorial.

I have multiple functions like DownCollisions(), RightCollisions(), LeftCollisions() that casts many rays in their direction using intersect_ray(). But before that, I cover the raycasts with an intersect_shape() so that I can analyze any collisions and deem them worthy enough for the raycasts to detect. If it's not a worthy collision, then place it in an array called "exceptions", that you place inside the intersect_ray() function.

based and redscreened

Attached: godot.png (889x1218, 837K)

I use a bunch of shape queries to do the ledge grabbing in this video, I barely touched 2D physics but it works alright in 3D, you can see the colored shapes in the top right representing the queries.
It's nothing too complex, it just checks if there's a wall ahead and if there's enough space above to climb up.

Attached: Grey Butterfly - You are ready to begin your trials.webm (1280x720, 2.89M)

Do you making stealth game? How do you getting light data? Light level, "shadowed by cube" and so on. I don't remember godot having easy method to do that.

>youtube vids at face value since it's always full of retards that barely know what they're doing but think they can teach others.
Curse of youtube
Curse of news/tech aggregators
Curse of the Interwebs
And curse of the Magazines.

Attached: Youtube_whatisthewebwithoutadvertisement.jpg (1280x1024, 374K)

It's all raycasting between lights and the player and calculating light level based on the same formulas the engine uses to draw the lights, these webms are actually 1 year old because I moved the project to UE4 since Godot has some 3D annoyances like stuttering when loading assets and flickering lights and nothing really can compare to UE4's sheer amount of features, I still use Godot for 2D though.
In UE4 I did another solution based on calculating the actual light value hitting an invisible cone by counting the light values of pixels which is similar to what The Dark Mod does, it's more accurate but can lead to other annoyances like the image capture having different light values than what the player is seeing.

Attached: Grey Butterfly - Lightgem rays.webm (1280x720, 2.88M)

Thanks for answer. So raycasting, like i supposed.
Sadly 3D is still not good enough in godot, but 2d is really good. Exepting tilemaps.

And here's the 2D game in case anyone is curious, basically Sokoban with new stuff added in.

Attached: Harmonic - wander.webm (720x720, 2.74M)