What I have learned

The Ferryman is my second game I managed to publish and also the second I made for a jam. So from this perspective it seems that jams get me going. I'd like to use this post to record briefly what I learned from this project.

Estimation is hard

Completing the first game taught my how much work little things can be. Yet I underestimated the amount of work this project was going to be. Although that didn't catch me by surprise overall (games get delayed all the time for a reason), it was surprising how quickly I could implement some things I had deemed much more elaborate and how long it would take me to finish a feature I had considered to be tiny.

Building Godot, for example, was much easier and straight forward than I had anticipated. Getting a set of export templates to fulfil the jam's requirements  on the other hand was a lot harder. Compiling the export template for Linux, being my development environment of choice, was easy. To get the windows build I had to do a little research since the cross compiler package had been moved to the AUR. That also involved some extra compiling to get all the dependencies. But overall I was surprised how well that went in the end, too.

The export templates for MacOS are a whole different story though. I vaguely remembered that the licence you have to agree to when using Apple's SDKs is not particularly open. So I did a bit of digging and found out that, as far as I can tell, you can only use them (no matter if cross compiling or not) you have to run it on "Apple branded" hardware. No Apple, no build, no export template, no jam.

I had considered using the official release export templates, but since they were available only for the latest stable build 3.1.1 at the time of the jam, I wasn't so sure if it would run well when exporting a project made with a bleeding edge 3.2 editor. Well, when I accidentally opened the project with the 3.1 editor (I did not install the 3.2 custom build system wide), git diff  told me that the tween_all_completed signal had been gone. And indeed, that was new in 3,2 and a reason for me to not use the 3.1.1 templates.

Next step then was to check the page linked from the jam's landing page where one should be able to obtain bleeding edge export templates. For some reason I had a hard time downloading those, since the connection would more than once terminate, causing me having to download everything again because Chromium was not able to resume. But then I noticed that the export templates - at least for Linux and Windows - were huge - more than a hundred MB each! How were people able to upload a whole game  for the jam with less than 20 MB in size? So I decided not to use those templates.

A little research later I found a post in the Godot community forums that led me to Hugo Locurcio's page where nightly builds of the export templates (and the editor, but I didn't need those) were available. These templates' sizes where close to those of the official ones, so I decided to pick it up. Thanks Hugo!

It was a little later I found out, by more attentively reading the Godot build instructions, how to optimise custom built templates for size, excluding modules and the whole 3D pipeline and, the most important bit, stripping the binary of all debug symbols. I naively had expected that a release build would not contain any of those in the first place, but that way I was able to shrink my custom built export templates for Linux and Windows to about 16 respectively 19 MB. Sweet!

Brace yourself as there will be problems

Again no big surprise here, but especially when working with tools you're not that familiar with yet or doing things a new way things will break. In this case, for example, I had problems with 2D lighting in Godot. Sprites would be randomly lit or not lit when using lights in masking mode. Seems this is kind of broken and will only be fixed when the Vulkan renderer is available. That got me to break a sweat because I wanted to have several lights in the scene that, instead of illuminating stuff, should mask out a shadow overlay. I was able to get around by rendering to a viewport and using it's texture for a masking Light2D. In the end I still had to write a custom shader to combine this shadow masking with partial occlusion from lights being hidden behind a solid object. But I managed and learned on the way, so I will not complain.

I also hat some fights with the AnimationPlayer and still don't know why it wouldn't animate as I had intended until I manually created a keyframe for each animation step. That was cumbersome, but since the animations only had a few frames I went that way. There were similar disputes with the 2D path system. I wanted to have some sprites follow the path and use the current location's rotation to control which animation to play (walking up or sideways), but I could not find a direct way to ask the path (or a follow node) for the rotation at a given offset. So instead I had an invisible proxy follow and rotate along the path and then used that so adjust my sprite's properties programmatically.

Audio design is driving me nuts

Really, I didn't expect this topic to be so time consuming and unnerving. For hours I was browsing web pages offering free sound effects in search for suitable ones. That's not to say there aren't any free good quality samples out there, but I had no idea how to appropriately narrow my search, so I just drowned in results I had to listen through that were way off of what I had in mind for the game. Also since the volume sometimes was too loud or some of the sound effects were just torturing my ear this in no way had been a pleasant experience.

I can only guess how much work, know how and skill is involved to create a rewarding and consistent sound experience for the player in larger projects. It seems I am either very unsuited for this process or you definitely should have professionals handle that stuff. What do you think?

I can handle my priorities

The previous points are all about what can go wrong and how much work everything is, but there is also some on the plus side. I am a bit pleasantly surprised that I managed to do (in my opinion) very well to manage my priorities. That is I get the most important thins done first and start polishing later. I constantly asked myself: what it the most lacking part right now? If I would release the game in it's current (broken) state, what would be the most annoying thing, the biggest let down? Do I really have to replace this placeholder asset right now? Does this cool looking feature really add much value to the game or is it just the nerd wanting to showcase his skills? Wouldn't a little animation here improve the atmosphere a lot?

Little things can make a huge difference

I already made this experience during the Linux Game Jam 2019 with my first game. There I managed to add some little detail once I had done the core mechanics, like a looking ahead mini map that gives you a hint of what to expect. For The Ferryman I made this experience with the extra animation when swapping tiles, for example. It makes you see what is happening and provides an immediate and easy to grasp feedback to your actions. Or  randomly chosen flip values for some sprites on creation to increase the variation without having to actually add new assets.

Care for code is important right from the start

You might be thinking "ah, I will only work on this project for a week or so, I don't have to care for clean and structured code". I found this statement to be very wrong, at least during my projects (games and software in general) so far. True, you probably don't have to elaborately plan you code or project structure. But especially when time is short you don't want to waste it debugging messy and unreadable code of by constantly navigating a single huge script file. Take the time, for example after completing a feature, to reassess your code base and scene structure and see if it can't be improved considerably by a partial refactoring.

Also, use a VCS! Even if you only use a local repository, do it! Commit regularly so you can go back to previous versions of your code or experiment without the fear of irrevertably (is that a word?) messing up stuff. Git is very easy to set up and very powerful. If you haven't looked into it yet, consider it for your next project.

Well, that turned a bit into "you should to that and should not do that" instead of "what I learned". So, what did I learn? That it pays of to refactor now and then and use git. :-) I even should have done more refactoring but was a bit reluctant at first because I misjudged the complexity of the game at the start.

Feedback is vital

Getting feedback is what virtually every game development tutorials cover at some point. You could extend that to "get early feedback", but since I'm talking game jam here right now, that term might be a bit off place of too vague. So let me put it this way: even though I only had a single person play test my game every now and then it improved the game and the development process as a whole  considerably. Some things you just overlook or misjudge due to your perspective as the developer/designer. Also discussing possible additions to the game or even gathering thoughts on what should be the top priority right now (see "I can handle my priorities"!) can be a huge boost in terms of value output per time.

In my case I had to cut some features I had planned initially. Taking the feedback into account brought me to the conclusion that my time was better spent at other places. And yes, it is disappointing nit be able to implement a very cool looking fog overlay that interacts nicely with the lighting (or so I imagine), but better polish the core gameplay, improve usability than ship a visually stunning but incomprehensible mess of incomplete features. (I hope I succeeded in this regard, you be the judges!)

Don't cling to ideals

This directly follows from the previous point. When I think about all the games I "always wanted to make" and I have never written a single line of code of created the shabbiest asset for, I really think that "start small" is the mantra to go. Maybe unless you are a full fledged professional, I don't know. So what did I need in order to get started? To care less. Care less about the degree of perfectness of the outcome, care less about the impact the game will (not) make, care less about the lack of praise and wealth coming from it. This or that didn't come out as hoped or expected? Well, at least it works. I can't play this game for more than five minutes because I get bored? Well, at least I can play it for five minutes!

So to sum it up, the time frame given by a jam leaves no doubts that no AAA title or even a polished game is to expect. A jam gives me the opportunity to just throw myself onto it and get going instead of wasting time planning and dreaming big. Now if you please excuse me, talking about jams all the time has made me hungry.