Comment by bowsamic
Honestly this is the kinda stuff that put me off Godot. A million ways to do things and they all seem bad or feel like they’re going to shoot me in the foot later. Somehow I never had these issues in Unity
Honestly this is the kinda stuff that put me off Godot. A million ways to do things and they all seem bad or feel like they’re going to shoot me in the foot later. Somehow I never had these issues in Unity
Man maybe I should have started with unity but I’m such a fucking hipster I just never go with the popular thing. Ultimately happy I don’t have to worry about the licensing BS and I still get to claim hipsterdom, but it’s clashing with my desire to work in ways that make sense to my poo brain.
I feel your frustration about spending years trying to understand the right way to use an arcane system. I don't know if this is the kind of response you were hoping for, but I urge you to just pick one method and try to develop past it, see how far you can get, see if it holds you back, if you needed to generalize better. Just brute force a couple approaches at random until you find one that lets you get shit done, so you can get to a working demo that has 1 semi-complete level/stage, no matter how hacky. Working on other things besides the difficult abstract one might lead you to useful answers or better ways of (re-)implementing features, and nothing will motivate you to find a system that works more than having a working demo that you know proves your concept, but also knowing the code is shit and ripe for refactoring.
I appreciate your response! This is basically how I have managed to finish small games in the past. Only issue is much of my intention on finishing those small projects was to find the 'right' way forward, when that clearly isn't an effective way of thinking about it.
I think my best bet is to apply the same mentality you're describing to larger projects, like you're saying. As long as I don't get too sloppy, refactoring will be a necessary effort when I actually hit issues that stall my progress.
Are there any Godot FAQs or documentation with "blessed" paths for the various mainstay gamedev needs?!
This conversation got me looking into the Godoy asset library, where I found a number of examples that wound up being very helpful. There are a few 2d platformer examples made by the Godoy team that emphasize just how many options there are (and for good reason). The ‘thing is a thing’ mentality that comes with learning OOP (or at least the way I have been learning) is probably a good one to get past, because indeed there is are many reasons to do one thing different ways based on the little differences between implementations of said thing.
So the project I just looked at had 3 types of platforms that I could tell:
The level was made up primarily of a tile map. It had its own collision set in the resource per tile and represents the most copy-cut type platforms you’re likely to see
Then there was a static body tile, which had a polygon2d shape, used to create an irregular platform that would have been more painful (maybe near impossible) to make in the tile map.
Finally, there were two moving platforms that were instances in as scenes.
So the big revelation for me today is that I need to not get hung up on doing any one conceptual thing anyone one way. Any (seemingly minor) difference in fundamentals about what that thing is or does may lead to another basic node type being the best thing to use. I need to not be afraid of making use of more varied tools, even if things feel like they should be all just be the same simple thing in the head.
I think every developer finds footgun issues with various tools for their aims. Or, I know developers that express similar sentiments towards Unity (or Unreal, proprietary engines, etc.).
When a game team is successful, it can often stem from having picked tooling and workflows that enabled them to be productive enough and avoid enough pitfalls. That’s going to change from project to project and team to team.