Last month, me and two friends participated on our first game jam which was named appropriately: My First Game Jam. For us though, it was also the first time trying to make a game. Our team was two programmers and one artist. The optional theme was love. We figured might as well do the theme.
We ended up doing a visual novel about gaining the affection of a dog. The main mechanics are that any option can work assuming succeed in the mini-game that comes from that choice. The idea was that I really wanted a game where you could get away with any option you select in a dialog wheel, regardless of how terrible that option is. So in this case, if you pick a terrible looking option, you'll get a harder mini-game but if you succeed, you gain the same benefits as picking the optimal choice.
Early on we wanted to make that game but instead of a dog, you'd be playing as an information gathering agent working for a big agency. You'd be charged with interrogating and befriending people in order to get information for the organization you work for. In that version, one of the secret character you can interact with would be a dog. Because of our inexperience and the scope of the original idea, we just decided to focus on the dog part for our first jam.
What went right
Honestly speaking, that section is going to be short. Being our first game, not a lot went right but every mistake was a learning experience. We learned a lot with our first jam which helped a lot for the second one we did (post-mortem for that one coming soonish). There was still a few things that helped us a lot that I want to point out here.
Godot is a great engine
I picked the engine because of the good things I've heard of it and it is quite less popular than the likes of Unity, Unreal Engine 4 and Game Maker. Turned out to be quite a good option. I think that if we went with another option, our end result would have been much worse than what we ended up with. We liked it so much that we ended up using it for the following game jam to even better success (and in a quick jam I did alone afterwards).
One thing about Godot though, we went with the GDScript option but I think we will switch to the Mono C# version in the future. I've looked at benches and it runs quite faster than the other one even if there are clear benefits to how easy GDScript is to use. Maybe that will change in the future but for now its clear that compiled vs interpreted is still not a fair fight for interpreted.
The style of game we picked was the perfect for a first game
It was a simple style but we got to practice multiple things that are pretty valuable. Because it was less animation heavy, it allowed us to experiment to find a proper pipeline to produce assets effectively in the future. Code wise, it was pretty simple but the mini-games allowed us to experiment with multiple style of games and learn the engine better.
What went wrong
Our asset production pipeline was bad
Because we had a good idea of what we wanted art wise, we ended up skipping a lot of steps when producing art. That was bad. If we wanted to make a change or if something wasn't optimal, we wasted a lot of time since there was already a lot of time invested in every asset.
Music is hard
I figured I could wing it and make music. Nope, not in the span of a weekend without knowing what I'm doing. That was a huge waste of time on my part and we ended up grabbing royalty free music assets that ended up somewhat working, somewhat not working. As soon as the jam ended, I started looking for someone to join our team to take care of the sound and music side of things because in my opinion, its very important to a game.
The game was too short
We only had 3 mini-games in so to not make it too repetitive, if you won 3 times you cleared the game. We should have spent less time on the few mini-games and expanded to add way more to the game.
The entire project structure was terrible
Scenes were being saved everywhere, in multiple different folder structure depending on who made the scene or not. The assets were saved directly in a folder inside the Godot project which were imported automatically and broke Godot from time to time forcing a restart in order to work with the asset. What we should have done is to have the assets saved outside of the game project then have each assets imported when needed into the game files.
Having instructions is important
We didn't make the gameplay clear enough. We didn't include an how to play or a controls section in-game. It wasn't clear when people had to do things inside a mini-game. This is very important so people can actually enjoy your game, it's something we will work on in the future to never fail to include.
I'm not too proud of that one. It was mostly due to lack of experience. Honestly there's quite a few things. We could not reset the data without having a function that would empty each meta data. We didn't implement background scene loading and an asynchronous resource loader (the first thing I coded as soon as the project ended). We animated frame by frame in the code instead of using the great animating system inside Godot.
We had a lot of fun and the game made us laugh a lot. We learned a lot from the experience and we absolutely loved doing this. We made a ton of mistakes, but I'm glad of the progress and things we learned from them. You can find the game right here if any of you want to try it: https://nasolid.itch.io/woof