I feel bad, I practically have abandoned writing about A:\dventure at all, but that’s not the only thing I abandoned in the past few months. See, about a week ago I first presented A:\dventure publically in a semi-playable state at TooManyGames for people to playtest. Everyone who tried it said things like they enjoy how smooth it played, they enjoyed the subtle but quirky humor of it, and they generally liked the new gameplay style of the game versus C:\raft. However, what surprised people the most was the fact that I told them I’ve only been working on it on-and-off a month.
Now, if you’ve read previous blog posts from around 6 months ago, you’ll read that as a complete lie and marketing stunt, but in reality it’s the truth. You see, feeling like there’s no point in frustrating myself in my free time stumbling about in Unity, trying to make it do things in ways that work but not ways that are intuitive, I scrapped everything I made.
I’ve mentioned I’ve played around with Godot before, and originally the reason why I didn’t start this project in it was because 3.0 wasn’t yet stable at the time. I’ve always been a fan, even though I had no practical experience making anything of a decent scale in it. Also, since my free time has been stretched thinner than I anticipated when I started working on A:\dventure, before I knew it Godot 3.0 was out and my game hadn’t progressed anywhere in development. So with a month to go until TooManyGames, I thought I might as well do what I always do when I present at that con and just try to pump something new out fast.
With 3.0, Godot added C# support, which is cool if you know C#. I do know C#, but seeing that there’s very little similar between Unity and Godot’s API, it’s not like everything you know about working in Unity’s C# will help you transition to Godot’s. Instead, because I’d have to rewrite everything anyway, I opted to use GDScript as the language of choice for the game. Since the game is designed to be incredibly small and lightweight, not having to include the Mono runtime keeps the binary smaller. Also, due to the simplicity of my game’s logic and object count at any point in time, I’m not worried about any potential performance drawbacks using an interpreted language would have on my game. This allows me to be more concerned about the general quality of my game’s code and the ability to write things out fast in a simple pythonic language designed for game creation.
Godot’s UI creation tools are comparable to Unity’s, allowing for anchoring and resizable UIs, which is cool. I was able to recreate most of the UIs I had before and then some more using most of what I had learned in Unity, so it went significantly faster the second time around. However, unlike Unity, Godot plays well at doing pixel perfect scaling out of the box for 2D heavy, low resolution games. Unlike many pixel art games that you see nowadays, A:\dventure renders at only 320x240 and everything is pixel perfect. Every pixel counts with my assets, and being able to scale them appropriately with no excessive filtering is important. You won’t see a mix of pixels that are 2x2 and 3x3, you won’t see assets blending between the “grid” like you get with high res pixel art games. In a previous post I talked about how dealing with this kind of rendering was a struggle in Unity. Godot took those worries away, so now I don’t have to spend as much time fiddling with my assets to make things look right.
Implementing the gameplay has never been easier. The signal system that Godot has out of the box is just incredibly elegant and simple to use, and eliminated a bunch of code and boilerplate I had for doing the same thing in Unity. Straight forward and visible event registration makes it easy to see and set up logic for executing actions relating to input handling, queue up a multiple stage pipeline for building my dungeons, and even trigger animations. So much programming in a turn-based game functions better in an event based fashion, so this was the approach I was always going to take. To have tools that allow me to follow that path with little resistance only makes implementing it the way I imagined it all the more satisfying.
Generally, the entire work environment has just felt more natural since the switch, and thus I’m going to continue with this direction for working on my game. Getting things to the same point and further has taken less time even though I had about the same level of experience in both engines. You might chalk this up to me already having more of a plan of what I needed to do than when I first started working on this, but even still, I feel no regret for changing engines.
Follow up posts will be related more to updates about features I’m working on and things to look forward to with the development of the game itself.
