Comment by spencerflem
11 days ago
I love library based game dev, like raylib or libgdx, but there is a reason that games like slay the spire moved to unity and then godot for their sequel.
That is to say, I don't think people are using Unity because they were mistaught by complexity loving professors.
Another thing related to this that I found kind of interesting, is this post [0] (unfortunately on twitter) of the developer of Caves of Qud, where they fully ported their game from Unity to Godot as an experiment, showing that they seem to have built the game around a single node, essentially just using Unity (and then Godot) as the presentational layer, similar to a simple graphics library type thing, basically ignoring the whole node system of either engine.
I wonder if this kind of architecture might also be a pretty good approach. The fact that they were able to port the game to another engine within a day is pretty impressive.
[0] https://xcancel.com/unormal/status/1703163364229161236
I don't think that the developers of Slay The Spire were taught by complexity loving professors, no. But education does more than influence the people at universities. Education informs norms, traditions, and styles that permeate through industries. An example from outside tech: the music notation app Finale found a strangle hold on the education market, and now it's one of the standards for notation, despite being the worst option (source: have you tried Finale?).
I've never played the game, but my understanding is that Slay the Spire largely impresses on a design and artistic front, not a technical one. Its engine requirements were not based on feature set or code quality, but on what developers knew. So they probably picked Unity because it was ubiquitous. Education starts the problem, and then devs who need something common they care hire for continue the problem. I don't blame devs for this, it's the right choice to make and obviously Slay the Spire is great, but I am saying that this is a force that drives down the quality of game engines.
No, they started with a code only framework (my beloved LibGDX) and then moved to Unity/Godot for the sequel for pragmatic reasons. See my other comment.
Being ubiquitous was part of the decision, yes, because it means there are many high quality plugins instantly integratable which is a huge time-saver.
Fair, though when I say "quality decline" I'm mostly talking about extraneous useless features and overly complicated node-based architectures that require GUIs. There are simpler ways to do all of this stuff. This engine, Tramway, is proof of that. Godot sits somewhere in the middle, I've used it a little but I don't know enough about it to say whether it's overly complex or not.
You are correct: I definitely agree that not all gamedevs should be making stuff from scratch, but I also think that Unity is a little too much. There's a good middle ground somewhere slightly above raylib.
My argument is that the promotion of engines that live near this middle ground is blocked by education: people who want to be able to sell long courses to the people who look up "how to make a video game."
I’m curious, what was/is the reason? I would like to learn more about the tradeoffs people are experiencing.
This is mostly on switching from Unity to Godot: https://caseyyano.com/on-evaluating-godot-b35ea86e8cf4
But also features this brief comment on game libraries:
"More than a Game Library: Having worked in SDL and LWJGL I’d like a bit more handholding. A few in-house APIs for loading/unloading resources, font stuff, and display handling please. I don’t want to write those; I want to make games!"
and some words on LibGDX in specific
"The reason we chose LibGDX for Slay the Spire was because it could do PC, Mac, and Linux. Yes, it runs in a JavaVM and it has all sorts of problems but it’s write once, run anywhere amirite? No. It don’t run on consoles and Mac and Windows updates constantly break it. "
All that said, I still love LibGDX, raylib, löve, and if I was going to make a game I'd use one of those because I think they're more fun. But I'm also not doing this professionally, on a deadline, and with a requirement to work on consoles
Doesn't Slay the Spire rerender every card's render target every single frame? It runs like dogshit on the Switch for no good reason, given how graphically simple the game is compared to other titles on the platform.
I'm not sure. I can tell you that the port was done by a third party that needed to transpile the java code first to C# and then to C++.
https://pbs.twimg.com/media/ETkH_QvXkAAD2N7?format=png
Wow, that's wild—almost seems like it would've been less work to just rewrite it manually at that point!
But yeah, the more cards there are on the screen at once, the lower the framerate gets—very noticeably so, when you're e.g. looking at the view of your entire deck, or when you draw several cards at once. I just assumed it was some inefficiency that entirely unnoticeable on a high-end PC (250+FPS, no problem), but was very apparent on the Switch. I never would've guessed there would be something far crazier at play than I imagined!