Hacker News Reader

Comment by je42 | Hacker News Reader

I wonder why Godot wasn't picked. Did I miss the points in the article?

Here is what I (not the article author) ran into when trying to use Godot to make a 2D game: https://forum.godotengine.org/t/shadows-go-over-the-sprite-w...

I rarely touch game dev but that made me think Godot wasn't very suitable

> We wrote extensive pros and cons, emphasizing how each option fared by the criteria above: Collaboration, Abstraction, Migration, Learning, and Modding.

Would you really expect Godot to win out over Unity given those priorities? Godot is pretty awesome these days, but it's still going to be behind for those priorities vs. Unity or Unreal.

I also would have liked to have seen the pro/con lists for each of the potential choices.

I've been toying with the idea of making a 2d game that I've had on my mind for awhile, but have no game development experience, and am having trouble deciding where to start (obviously wanting to avoid the author's predicament of choosing something and having to switch down the line).

The key is, you gotta be pretty cold in the analysis. It's probably more important to avoid what you hate than to lean in too hard to what you love, unless your terminal goal is to work in $FAVE_LANG. Too many people claim they want to make a game, but their actions show that their terminal goal was actually to work in their favorite language. I don't care if your goal is just to work in your favorite language, I just think you need to be brutally honest with yourself on that front.

Probably the best thing in your case is, look at the top three engines you could consider, spend maybe four hours gather what look like pros and cons, then just pick one and go. Don't overestimate your attachment to your first choice. You'll learn more just in finishing a tutorial for any of them then you can possibly learn with analysis in advance.

Thanks, I appreciate the comment! I'm certain that my goal is not to work in a specific language, but to bring a long-time idea to life, and ideally minimize the amount of avoidable headaches along the way.

You're probably right that it'd be best to just jump in and get going with a few of them rather than analyze the choice to death (as I am prone to do when starting anything).

This is goes for a lot of things in tech unfortunately. For example, being stuck in a SRE/devops amusement park can be incredibly frustrating and surprisingly resource intense.

Sometimes it feels like we could use some kind of a temperance movement, because if one can just manage to walk the line one can often reap great rewards. But the incentives seem to be pointing in the opposite direction.

I'm beginning to develop a heuristic around the concept of "amount of the library you use". It's intrinsically fuzzy and still something I'm working on, but in general, it's bad to use only a tiny fraction of a library or framework, and really bad to have a code base in which a large number of things are pulled in that you only use small fractions of.

There are some exceptions, e.g., pulling in your languages best-of-breed image library to load some JPGs even though it supports literally a dozen other formats is less disastrous to a code base than pulling in an industrial-strength web framework just to provide two API calls with some basic auth of some sort. But there's something to the concept in general, I think.

That sounds like a good balance indeed.

I wondered the same - the separate C# build might be a bit of a hassle still though.

But they also could have combined Rust parts and C# parts if they needed to keep some of what they had.

One of the complaints in the article was using a framework early in it's dev cycle. I imagine they were just picking what is safe at that point and didn't want to get burned again.

Reply on news.ycombinator.com