Postmortem

GBJam 8 Postmortem

Mariothedog: This jam was quite a bit different compared to the last jam (Lowrezjam 2020) we (as in, Lospec) did. We had significantly less people, roughly a drop of 20 to 10 participants. I actually found this easier as the less teammates there are, the less time is spent deciding on each aspect of the game and ensuring that everyone is aware of what needs done. We also had a lot less time, which was simply due to GBJam being a 9 day jam and Lowrezjam being a 16 day jam. Nonetheless, I believe we made more effective use of the time we had at hand.

We used Trello for organising what needs to be done, much like in the last jam. However, we changed the system of managing cards (if you’re not familiar with it, a card is essentially just a “thing” that needs to be implemented/spirited/designed) to one that utilises a “day-based” label system. Originally, we used the card priority plugin (which adds options to the cards such as “high priority”, “medium priority”, “low priority” etc). However, I believe this is quite a poor way of handling it in that it’s not very clear what needs to be done by when. For example, in the Lowrezjam, some game features were implemented that should have been implemented later on. As in, it would have been more effective to build the main world scene in the first development day or so, which would allow people to work off of that. This time around, we changed the Trello board to employ a variety of labels which represented each day. For instance, cards that needed to be completed on the first day would have the “Day 1” label (such as the game idea). However, this didn’t go perfectly, as just like before, not everyone reserved cards on Trello so occasionally people were unsure of who was working on what already. Another issue was that the game concept was changed a lot over the days and sometimes this wasn’t replicated in the Trello board (i.e. some cards were not up to date). To give an example, initially our game idea consisted of grappling upwards and killing enemies that also attack the player back. However, after some more thought, we decided to change it so that enemies don’t damage the player directly but instead the player’s health depletes over time and the enemies regenerate the player’s health upon death. We also added in “rising magma” to increase the feel of a more instant threat.

In terms of how we handled the programming side of the game, we used the Unity engine. Previously, we had used the Godot engine in which I was the lead programmer. This time around, I was not very familiar with the engine we chose at all so I was lucky that I wasn’t the lead programmer. But it was still a fun learning experience. There were a lot of things I felt that were similar to Godot in Unity, others that I felt were worse, and stuff that I felt were better. Unity’s C# support was much better compared to Godot, which makes sense since C# is Unity’s main language and Godot’s is GDScript. I was already somewhat familiar with C# so it didn’t contribute much to the learning curve. I did most of the UI related scenes (Main Menu, and the HUD) and I feel like Godot handles UI a lot better. Although, we were using Unity’s old UI system so I don’t know how much of an improvement Unity’s new system is. In terms of what I felt were the positives of using Unity, I really liked how in script, there were so many useful attributes that allowed for enforcing that game objects had specific features (such as requiring a specific component) and how easy it is to create custom assets and view them in the file system. For some more things that I felt were Unity’s downsides, I feel like its UI is very cluttered and overly complicated, such as Unity’s animator controller system. Despite it being quite similar to Godot’s, when I was implementing the Lozpékistan Game Studios splash screen it took me quite a while to get my head around animating it and setting up an event for when it ends.

In regard to the game’s art, I didn’t do much of it so I don’t have a lot to comment on. The most significant contribution that I did in that field would probably be the game’s HUD which I felt went fairly well. The font used for the HUD did go quite a few revisions. At first it was a pretty basic 3x5 monospace font with just numbers and a hyphen, however I thought it looked quite boring so I stylized the ‘0’ slightly by removing a pixel from it which emulates a gap and makes it evoke a more sci-fi-like feel. I (along with some other people) tried to stylize the other numbers as well but when I play-tested it in game a few days later I felt that it impacted readability too heavily so I just reverted back to the version where the ‘0’ wasn’t stylized.

For the game’s music, it was all done by one person – RushJet1. So I can’t say much about that. However, for the SFX we initially used Zik’s (he contributed to our Lowrezjam entry) stock SFX pack. Later on (the day the jam was going to end!), we realised that it was against the rules to use assets made before the jam so we had to remake every single SFX. And by we, I mean I made one (out of 7) and someone else (Olivia/ATreeWithLeaves) did the rest.

ATreeWithLeaves: It was an honour to be able to help with assets, design, or just be a part of it, I think the game came out really well, and I think that’s thanks to each of us pitching in to supply as a team, but, we could not be able to complete the project without the lead contributors, but everyone did great, and I would say that everyone went above and beyond.

reverie: good job everyone, i think it turned out nicely (also spontaneously working on a game at 1am on the last day is fun)

Unsettled: This has been the second jam I’ve ever made, it’s been quite fun. Using Unity instead of Godot allowed me to actually contribute to programming (Godot’s vision is too different to get used to in a few days) and also learn a few new things about scriptable assets. I coded the level editor for the game and only at the end I realized that it wouldn’t have been so useful, since the additional features were very few and the scope of the project wasn’t so big to justify spending time to build a custom editor. I guess that since Unity is huge and boring to download for artists, it’s still been quite useful.

The different management of cards in Trello helped a lot more to understand what had to be done and when, but sometimes the communication was kinda faulty (eg me and A& built the same system in the same day), the fact that a few cards where kinda generic (“Build enemy controller”) gave the impression that they were supersets of more specific cards (“Add knockback and damage”). I feel like cards should be as specific as possible (speaking about Unity, ideally a card per script).

This brings me to another point: I often found myself in a situation where I needed data from other script but had to implement / modify other scripts in order to have them ready. I didn’t make most of said scripts, so it took me a while to understand how they worked and how I could expand them without breaking everything. It sounds like a kind of overkill for a simple game jam, but I feel like schemes such as UML (probably something simpler than that) would have helped. Specifying which classes will be needed, the relationships between them and the data needed by each script to work correctly would have required some time, but probably saved some as well. I don’t really know how much time that would require in a future jam, though, and I don’t know if it’s really worth experimenting. Just throwing ideas, as usual.

I found kinda funny the fact that 2 days ago (05/09/2020) we had the little problem that the game wasn’t fun. We had to introduce new mechanics (rising lava, unharmful enemies) in order to fix that. That showed me (us?) how much difficult is to make a (fun) game. I was really surprised by this, it turned out that A&’s way of organizing thought, asking questions about the objective and stuff like that, rationally describing the features of the game, did make sense.

I mainly make jams to try out what working in a team is like, so I think I kinda grew up regarding that aspect, both technically (I’ve learned something new about git and github) and humanly (this sounds kinda cringey sorry), as taking part in this jam made me more conscious about the way I behave in a team and about the way working in a team affects what I do and the way I think.

Thank you, it’s been fun.

Zarki: This is the first game jam I’ve done, as well as the first time I’ve worked with a team. It was a good experience for me; it was so cool to see everyone contribute and for everything to come together like it did. It wasn’t perfect, but that wasn’t the point and that’s something I get stuck on in my own work. I’m glad I had the opportunity to contribute to this, and thank you!