Deciding between Godot and Unity
Hey, all. I'm back four weeks to the day after you guys gave me a lot of great advice about potentially making a 2D RPG out of my tabletop RPG. I decided to try both Godot and Unity given what people told me and I completed two tutorials for each over the last few weeks. After completing these two tutorials, I have some questions that I hope maybe some of you can answer to help me choose between the two.
TL;DR at the bottom. This is a long post.
For context, here's the tutorials I did:
Godot - https://www.davidepesce.com/godot-tutorials/
Unity - https://learn.unity.com/project/ruby-s-2d-rpg
To be frank, the Unity tutorial wasn't really an RPG. There were no stats, no quests, XP. It was much more of an adventure game. That's fine, it still gave me a lot of time inside the engine to learn a lot of basics.
So, working with each one had it's own up and downs.
Unity's use of an external scripting program seemed to hurt me quite a bit, from simple things such as forgetting to save before going back to Unity (I did this way too much) to having to declare public variables in the script and then filling them in the Unity GUI rather than just doing it all by script. The editor itself also seems to be kind of heavy, I was get the spiral beach ball for a second or two every time I went between the script editor and Unity and I have a machine that can edit 8K video without proxies. These general load times and stuff like that seemed to come up regularly. Tilemapping in the tutorial didn't include autotiling, I assume Unity has this somewhere built in? Or do you need to purchase an asset to get this functionality?
On the plus side, Unity overall seemed easier to use for a non-programmer. A lot of things are done through the GUI. Animations seem easier to handle for sure. The Unity tutorial was also more written for someone that hasn't coded much as it explained what specifically the code was doing (so I assume more resources for Unity will be helpful in that way that perhaps Godot will not).
For Godot, GScript was easier to use than C#, but I do feel like it was easier to get my head around prefabs in Unity than the Node system in Godot. The Godot tutorial took almost twice as long as the Unity one, but I don't know if that's because Godot is more difficult or the combination of the Godot tutorial being more thorough (I feel like I mad an actual, if very uncomplicated game, plus I did Godot first, which probably helped me just learn more about scripting and thinking like a programmer that I took into Unity). The node/scene system seemed more difficult to get my head around than game objects and prefabs. That said, my Godot program felt very tight. There weren't things happening that I was having a tough time explaining or figuring out why they weren't working quite right, at least at the graphical level (this might have more to do with the Godot tutorial using 8-bit graphics and Unity using a more modern sprite look). Having the scripts in the editor meant I never ran into a case like in Unity where I couldn't attach code to a game object because it was failing to compile, but it was failing to compile because it wasn't attached to a game object (that headache took at least a half an hour to sort out).
Overall, I was able to finish both tutorials mostly understanding what the code I was given was doing and was able to edit it to get some different affects and kind of just play around. So, on that level, I'd say they're about equal.
One big thing I want for sure out of the engine we use is to be able to handle a lot of conversations and variables there from. We're hoping to make a "choices matter" (TM) game, and very story/dialog heavy. Ink seems like a good plug-in to do this in Unity, but implementation doesn't seem easy (though I did find a pretty good looking tutorial that may help de-mystify). Godot seems to have some assets available for handling dialog trees, but i haven't had a chance to really dig in to them yet. So, that could definitely be a decider for me: which engine has assets that make a dialog/choice heavy game easier to make.
While I had originally thought about making a tactics RPG for this project, looking around at both the Godot and Unity scenes, it seems like few people are making these types of projects that are giving out free advice on how to make them work in those engines. After talking with my team (I have a team!, see my post from a while back), it seemed like a good idea both to keep the game within the scope of a novice, but still tell the story we wanted, to do a skill role system instead. Since this came from a tabletop session anyway, seemed to make the most sense to do skill rolls rather than develop a whole combat system.
TL;DR - Looking for advice on which engine, between Godot and Unity, would be handle a 2D RPG that relies on a lot of dialog and choices along with skill rolls for the gameplay. Thanks in advance!
I think for your use case Godot sounds like the better option, just because it's lighter weight, has less restrictions (no forced splash screen), and can easily do the kind of game you want to make. Also, Godot has support for a number of different scripting languages, including C#, if that interests you. It seems like there are a number of Inkle plugins for Godot as well, so that shouldn't be an issue.
Man, thank you for pointing out there are Ink plug-ins for Godot. I probably should have done that search myself, but because the officially Inkle page never really mentioned Godot, I guess my brain just didn't put together it'd even be a possibility. Looks like there are two relatively recently updated assets and one even supports GDScript, so that seems like an excellent point.
I do also like how light weight Godot is. Just feels nice not to have to make a username and run a hub to get a version and so on like it was for Unity. Just download and get started. I also do like open source stuff and would like to support that, which was another point in Godot's favor.
Still waiting for one of my other coders to weigh in a bit, but this definitely gives me some ideas to bring to the table with her. Thanks.
This is my opinion not a recommendation, but as a programmer I found nodes more intuitive than prefabs, the fact that everything in Godot is a node build on top of other nodes gives the engine a hackable "aesthetic" that I find really attractive, and on top of that it is also open source.
But the lack of plug-ins in Godot is precisely why Unity is a more attractive alternative, you need to ask yourself what is more valuable: your time, or your money (assuming that some plug-ins are pay).
P.S. If you decide to use Godot and find yourself in the need of a programmer I'll gladly help, bulding a Choose Your Adventure plug-in for Godot seems like a fun project.
We sort of have a bit of both fun money and time to devote to this (scripting has become my "what did you emerge from the pandemic with as a new skill" thing). But that trade is still notable because while all of us coding have some experience with it, it's not very in depth. So, having more plug-ins that have already done the work is a good point.
As I mentioned to @tesseractcat, I do also like that Godot is open source, as I'm a proponent of that as well. And you are right that it feels more hackable. I took that part of the aesthetic of Godot as more "punk," the whole scene just feels more DIY, which I like.
The node thing does feel like once you get your brain around it, you can actually make it work a bit easier than prefabs/game object. I just need to start thinking about the design how Godot wants me to, my brain took to Unity's set-up a little easier, but that doesn't necessarily mean I can't adapt.
As far as your offer, that is super generous of you! I will keep it in mind if we do go with Godot! Maybe we can at least exchange contact information and I could hit you up if I need advice? I am not quite sure we're at a point where I would want to pay you for your time, but if you're willing to spare a few moments here and there, I'd definitely be appreciative. We do plan on having graphics in the game, I am looking at some asset makers that do a sort of 2D, SNES throwback style like Secret of Mana and Chrono Trigger. But would probably barrow, gameplay wise, more heavily from point and click adventures like Disco Elysium.
You can definitely hit me up whenever you feel stuck, DM so we can exchange contact info. And if you choose godot, I have no doubt that you'll figure it out after the initial friction.
I'll throw out Unreal Engine as another possibility, if node-based programming appeals to you. It is also free to download and use (they take 5% after you make a million). I used Unity for a few years (hobbyist) and then started using Unreal when I got my latest job. Everything about it feels so much more...... coherent. It's just pleasant to use as a tool.
I haven't' used it to build a 2D game (I've been focused on VR) so I can't speak to that toolset specifically. Here's a link to get started: https://docs.unrealengine.com/en-US/Engine/Paper2D/index.html
I'd say Unreal is overkill for this kind of game, and in fact lacks a lot of the tooling for good 2D games.
Since I haven't tried doing any 2D, what would you say it's lacking?
I'm pretty sure Paper2D isn't being actively maintained, however I haven't used it so I don't know the specifics. I do know however that the community support for Unreal is almost completely for 3D development, whereas Unity and Godot have ample support for 2D games.
I will read this for sure. I don't know if I'm ready to put my body through yet another tutorial, but obviously Unreal is a huge part of the industry and a lot of people think it's great!
I don't what the general skill level of your team is (if it has more novice programmers then perhaps Unity would be the better choice - not only a more extensive editor, but most importantly, a bajillion tutorials and guides for every possible idea by now), but I'd go with Godot. For something as technically simple as a 2D rpg, Unity is overkill, and you'll spend more time learning how to use the extensive tools to do what you want than you would just building them.
Like the dialogue tree, for instance. It really isn't that hard to get something up and running for that from scratch. The tree is one of, if not the, most basic CS datastructure after all.
I'd argue an RPG is one of the most difficult genres to develop for. It requires building an extensive number of systems, at least for a traditional RPG. Movement and camera, equipment, skills, party system, dialogue trees, quest tracking, enemy AI, damage types, shops. That's before you get into anything like magic systems or item use during combat.
RPGs require a lot of code to get to this point. For that reason I recommend against it as a genre to start learning programming with.
Appreciate the input, does seem like most of this group likes Godot. We're all fairly low level coders, part of this project will just be learning how to do some slightly more advanced work. We'll see if we get in over our heads or not! I do remember learning about trees back in the day, and the Godot tutorial I did had a tree structure for the quest/NPC dialog section.