วีดีโอ

As a programmer of 15 years, the many many people in these comments who are complaining about the creator’s conflation of Inheritance and OOP need to freaking relax. Is this technically incorrect? Sure, okay. Does the average person who hasn’t seen this node composition style of game dev need to know that? Not at all. What’s more, y’all are conflating OOP composition and this node-based approach, which is arguably worse because it muddies the waters. OOP composition via interface extension isn’t going to solve a damn thing here, and would likely make the situation worse (is Java a better language for allowing diamond composition patterns? Maybe in theory, but in practice, no). If this helps people make their game in a more maintainable way, who the hell cares about the terminology?

You should draw a front and back facing sprites for the player character its so weird seeing them move upwards while looking to the right/left

As for music. 2 doesnt sound open just because you say it does. Quite personally 1 has a way better, more natural and lonely sound that the last human should hear. Another commenter also said the same. Dont scrap the second one, but id say the first onr hit the spot perfectly. Looling forward to seeing more. (If u want a guitar hmu)

Awesome video! Your game looks super beautiful. I really like the art style of your game. Also the game idea sounds very fun. The music is spot on and it does give that vast/openess feel to the game. Looking forward to your next devlog. Keep it up! :)

I respect the spitfire labs plugin, that felt feel is really sweet for this style

Nice devlog! The game looks good , nice work! Can't wait for the next devlog already :)) I'm really curious how did you get the pixelated effect in Godot, i've been searching for a while a tutorial but it seems i can't find the right one :D I'll really appreciate it if you could help me out :))

wowowow!

You know I think you're really onto a winner here with the stylised art and the theme of the music. If gives very cosy vibes. I love how simple it is but still so visually appealing. It's all so cohesive. 99% of indie openworld games I write off as a disaster waiting to happen but this one jumps out as having real potential. I hope you prototype out some areas. Would love to see what forests and caves etc would look like in this art style.

Damn I remember this music, caught me off guard.

r.e. the soundtracks, i think i prefer the 1st track with its minimalism for providing that open-ness vibe. For me the variety of sounds is not as important as the tempo of the melody. You also had some white noise under the 1st one giving the impression of wind, so maybe thats what im picking up on. Minimal melody (esp piano) + ambient sound is certainly a good combo for that wide open melacholy feeling. 2. gives me more of a arrival in basecamp vibe, Majula/Firelink shrine style.

Cool I realy like this project

This is composition, not ECS. ECS is a data-oriented paradigm where all components are stored in homogeneous arrays which are processed separately, and the entity is simply an ID that can be used to locate the corresponding components within those arrays. ECS works this way because processing contiguous arrays of homogeneous items avoids CPU cache misses and results in higher performance. Godot does not work this way. It has an object-oriented class hierarchy of polymorphic node types which relies on dynamic dispatch. The trees of nodes are traversed to propagate event notifications which are then subsequently processed in order of traversal. This results in very poor cache coherency because there is never any guarantee that two adjacent events will be affecting nodes that are actually adjacent in memory, not to mention that every virtual function call very likely introduces another cache miss. That being said, composition in Godot is an extremely flexible way to build games and fast enough for the vast majority of projects

I am tired of people blaming OOP for these issues. It's the patterns you use, OOP is just a language paradigm. C is procedural, C++ is Object Oriented, Lisp is Functional. I don't see anyone complaining about "Procedural" being the blame for bad software written

As many others, this video was recommended to me, too. I won't go into the specifics as to why the benchmark is incorrect, but I just wanted to add that building microbenchmarks is deceptively complex especially since you need to have a pretty good understanding of everything that's going on, from how the cache in your CPU works to the features of GDScript. From your pinned comment, I don't think you understand how terribly imprecise your approach to "benchmarks" is. If you really want to reach that "definitive conclusion", just look for another benchmark online or just ask someone with a CS background to help you out. All that being said, you explained it fairly well and the video's presentation is great

If it had potential...

This is probably the best example of OOP vs ECS, amazing video

Rooting for you buddy!!

Nice video! A baba is you type game was a great way to broach the topic. While I love the components over inheritance approach godot promotes, I do sometimes find myself wishing godot had other OOP features like generics and multiple inheritance.

This is why I think in programming in general without double inheritance, when deciding what to inherit or compose you focus on what methods exist in both but differ including initializers but then you run into not all programming languages allowing initilizers to be inherited. Multi inheritance makes inheritance as a concept mutch more powerful.

In your own words, what is fun or compelling about the game?

Good luck man

You got it brother keep goin!

the art looks nice, plz complete the game so we can try it

It’s an Enderman with antlers!

I'm loving the style of this latest iteration, hope you continue down this path!

I think you need a game design document finished before working more on this. The game(s) shown feel more like art demos - where is the gameplay?

Evolve dis

Cool to see all the iterations. And the roomate at the end 😂

One thing I forgot to mention: In this prototype, I was testing out the visual style, figuring out how to get that "3D pixel art" look. In terms of progress towards the game, I'm currently in the worldbuilding phase. From here, I want to keep developing Craven and keep you guys updated with devlogs and insights.

so like... why not just check when the player collides with something and it is in group pushable, push it? is the idea here... to simply add extendability? for example objects can push other ones etc...

good :)

cool, thanks for sharing :)

WARNING For those making a 2.5d game...STAY AWAY FROM GODOT. Alpha sorting STILL hasn't been fixed, if you want to use animated sprites in 3d enjoy MANUALLY (through code) animating frames on a meshinstance3d as that is the only way to get depth sorting to work correctly...this literally turns a 2 minute action into hours of work depending on the amount of sprite animations. I found out half way through development the devs have no plans to address this.

Actually a very good video. It's perfect for my ADHD brain and it show and explains everything in simple words. Nice!

in c# they don't have any functionality make them worthless there

new opportunity thanks for the knowledge

Feels like using enums, except the way enums work feels faster. If you want a constant ID that's fast to compare, enums just pair keys to numbers, giving you the same number-to-number comparison speed you want... Except there's no memory lookup needed, because under the hood, the enum keys already are the numbers. Now I'm wondering if GDscript has enums, because with Python, you need a library and I don't like how messy it gets... Classes tend to do the trick for me though. Thoughts?

Enums are better anyway

I would redo the test with a switch staetment rather then compring a ransom steing to another random string. Because they couls stop on the first letter which would be similar to comparing numbers. If you look at your strings only two start with the same letter so it will be pretty much the same as steing names.

I think your conclusion about string name initialization is wrong as this would have happened at compile time. You should have tested it against an enumeration. As this would be the ideal comparison, as it would provide an extra feature over enums by printing their named values in human readable form.

**CORRECTION** As many of you have pointed out, my benchmarks were flawed. So, I rerun them with the suggested improvements: 1. Iterate over some pre-computed Arrays instead of picking a random element on the fly. This removes the variable of generating random numbers, which likely have been polluting the results. It also enables us to ensure that circumstances are the exact same by using the same arrays for both tests. 2. Don't use the same Strings. Strings in Godot are Reference-counted (which I didn't know, thanks for pointing out! :0). In the new benchmarks, I made sure not to compare the same String references against themselves by doing `string.reverse().reverse()` on them. This creates a copy of the String that's not the same Reference. Any other operation should work fine too, this was just the first one that came to mind. 3. Use strings that are more similar. This one's completely on me. I even talked about how StringNames should be faster for more similar ones in the start. After these changes, the results were: Mostly the same. StringNames were consistently hovering around 1s faster than regular Strings, over

This is an interesting video, and hats off to you for testing your hypothesis! But, if you don't mind some constructive criticism, I think focusing on speed benchmarks to compare Strings and StringNames kind of misses the forest for the trees. The main benefit of StringNames is not performance, it's type safety. StringNames provide a finite amount of values that a property or parameter can be set to. For instance, Input.is_action_just_pressed, will only accept valid arguments like "ui_accept" or custom actions like "jump". It won't accept "ui_accep" or "jum" because those strings do not match any StringName. Any errors like this will be caught at buildtime rather than runtime. If you're using strings, typos can become runtime bugs that will take development cycles to fix. With StringNames, typos will not compile so you will instantly know if you've passed an invalid value. I think you're also right that assigning values to a StringName property many times per second is impacting performance. When benchmarking, it's a good idea to separate code that is part of the "cold path" and "hot path". By their nature, StringNames are not meant to be created at runtime, so it would be much less common to write to a StringName value than read from it. It might be worth testing your hypothesis to see if frequent StringName assignment is what's causing latency. Very interesting video that's spawned a good conversation on an easily overlooked feature of GDScript!

I thought the point of StringNames is to save up on memory consumption when you're declaring the same strings in a loop, for example, or across the whole codebase.

Are there any uses for stringnames that aren't just for performance?

LISP has a different name for these types of strings: symbols. It also has another type of string called keys. In C++, most string types (There are many, since STL wasn't made when C++ was first released, so many libraries have their own.) have a "small string optimization", which is better than symbols because it can come from something other than the static area, such as user input, and the comparison may even be as fast (SIMD registers on the most modern CPUs are 512 bits wide, so 1 cycle compares can compare 64 bytes at a time, but there is a tag check, mask generation, and an AND mask, which take a few more cycles). GDScript could easily adopt these methods.

Someone should make a video about placeholder instances c:

Your benchmark code might be the cause of the statistically equal results. Pretty sure that picking a random item will always be a lot slower than the string comparison, thus making the time spent on the comparisons a small slice of the pie and why the results are so similar. A better way to check the difference would be to pre compute another array with random items and iterate over it, searching the first array for the items in the second. If you only start measuring the time after both arrays are created, your results should have a more significant difference

I saw them before but never used them nor read anything about them in the docs. So basically, they are not worth it.

If I remember correctly, Java has something like that. When looking at Strings and try to compare them, they don't actually compare the content, but instead just the address. Something like that.

This video was recommended to me and I have no experience with Godot. However, I strongly believe your benchmark is bad in that you're not measuring what you think you're measuring (or anything useful at all). Here are my reasons for believing this: 1. The data you used to benchmark is highly favorable for String. All your strings start with a different character, so by the string comparison algorithm you explained, it is to expected that comparing a single byte is fast. This defeats the point of using StringNames in the first place. 2. Character-by-character string comparison doesn't work like you explained. What you explained is how C-style strings would be compared, but all modern language store the length of the string along-side its raw character data. This is obviously useful for comparison, because strings with different lengths must be unequal. In your dataset, there are only 2 strings with the same length. Given that you pick a single random string to compare against, in most runs of your benchmark, String == String comparisons will be done after simply comparing the lengths. 3. Godot Strings are reference counted (I looked up the docs). Since you're not doing any string manipulation in your benchmark, this means that equal strings will point to the same memory holding the character data. This can be used to fast-path equal strings by simply comparing the memory address of the character data, just like what StringNames are doing. 4. And when we do fall back to actually having to do char-by-char comparisons (condition: equal length and different addresses), then it would be much faster than in your benchmark. 1M iters for standard string comp took 340ms or 340ns/it in your benchmark. 340ns is laughably slow for a single string comparison. Modern string algorithms are highly optimized and utilize methods like SIMD for optimal performance. Given the length of your strings, I would expect string comparisons to be no slower than 10ns given that all your strings are in cache. 5. The same thing goes for StringNames too. If your explanation of StringNames is correct (and it seems to be comparing to Godot docs), then comparing them is literally a single instruction, comparing a single word-sized number. On modern hardware, this should take less than 1ns, because this is the kind of stuff modern hardware is built for. But according to your benchmark, it takes around 350ns. It just doesn't make sense. But I repeat: I have never worked with Godot. I'm simply pointing out the flaws with your benchmark and that the times you measured make no sense for modern algorithms and hardware. My best guess is that you benchmark your code in a sort of debug mode (so without optimizations, which makes any perf comparison meaningless), that you are mostly benchmarking `pick_random` (maybe its RNG is slow? idk), or both. However, I can confidently say that your benchmark is *not* measuring the performance of string comparisons.