Recent searches
Search options
| 
@memoriesin8bit@mastodon.gamedev.placeWhy make functions for everything when you can put everything into setters and getters?
Legitimately all game settings I made so far are applied/read by changing variables.
It looks wonky to read, but it made the settings UI REALLY simple to code.
EDIT: You can also emit signals based on set/get - even with conditions, so you can immediately notify other game components quickly when (essentially) a variable changes. EDIT2: Maybe I'm just the last guy on earth to realize that. You decide.
@memoriesin8bit oh that's an interesting way to do it, I need to try that at some point.
Rn I'm using a modified version of this: https://github.com/bitbrain/godot-gamejam/blob/main/godot/settings/user_settings.gd
@geegaz tbh that you posted looks way smarter than what I did as it generalizes down everything to a key and value. I couldn't wrap my head around that for video settings tho - sometimes those need floats, sometimes ints, sometimes enums. Sometimes you need to change something in the viewport, sometimes the widow, the environment, etc. This is why I came up with the getters/setters to unify this.
I dunno if it's smart, but it works for me. :)
@memoriesin8bit yeah the way I do it is to handle the value differently depending on the key, and so having specific methods for different things... in the end it's just a more complicated setter/getter :p
@memoriesin8bit I get why people find this useful, but it's so unintuitive to have reads/assignments with side-effects via getset. I guess I'll never see this as a advantage over explicit setters/getters
@substain As I am a one-man-show it only has to make sense to me. Coming from my Unity game, I knew how convoluted Video options would be and predictably it was the same here. So this is more of an abstraction layer *specifically* for options - hence there are no side effects since that is what these "variables" are made for.
But I get this isn't everyone's cup of tea.
@memoriesin8bit What language is that?
I think the usefulness of get/setters really boils down to the language and language philosophies. Every time I see it in go I just sigh, but in other languages/settings it makes perfect sense :)
@yon This would be GDScript. And no, I am not sure if what I am doing right here is in line with GDScripts philosophy, but dong something dumb or wrong has never stopped me before so why should it now
@memoriesin8bit Single devs do as they please:)
I find that the people most obsessed by some aspect of programming (DRY, clean code, abstractions, everything is a framework, etc) write the worst code in the end.
Imho the less time you spend to get things done, and the less time to need to spend to fixing it, the better.
I really should play some with godot. I don’t think anything will come out of it, but maybe I can enjoy it for a bit :)
@yon I agree. I mean I have written absolute dogshit code in the past and it came back to bite me immediately. It was horrible. But each time I work on a project or a system, I try to do better, design better, more flexible and future proof... but give a project enough complexity, every system eventually comes crashing down. And that's why I wrote these setters/getters. Cause it makes other components interacting with them so super easy.
@memoriesin8bit I love simple dog shit code though. Because if it’s simple and straight forward I can fix it. That’s good.
Big complex with lots of abstractions and calling frameworks and magic etc. Can’t follow any of that and have to spend a ton of time to learn it. (And secret, designing a calling framework is super difficult and 99% of them are awful in the end.)
I prefer simple, and reuse by composition and called frameworks. Everything does what it says it does, and if something is broken I can easily fix it or rewrite it. Not locked in.
(Can’t remember if it’s a me-ism or a general thing. But a calling framework calls you. So like a web server, you provide callbacks that do stuff.
A called library is just stuff you call. Like functions or classes. Like a math library:))
@yon Exactly! That's the beauty of it! If I wanna change to fullscreen in godot, I need to access the window from the viewport and set the display mode.
Now I have a bool variable.
If I wanna change the brightness, I need to access the world, get the environment resource and modify adjustment parameters.
Now I have a float variable that goes from 0 to 1.
Imagine how much simpler my options menu works. Or the code that saves and loads these settings from a config file.
@memoriesin8bit Simpler is better. Smooth is great. Complex and convoluted is bad.
I think I already understand how this works, just from hints:) That’s good in my book.
(AWS APIs on the other hand, yikes. So convoluted I want to hide.)