Munkkiliiga FGJ 2020 project: Korjaussarja.

Game about brave captain of a kyykkä team trying to sober up and make it to the tournament quarters.

The theme for the year 2020 was repair. In finnish this is “korjaus”, and “korjaussarja” literally translates to “repair kit” but also means a drink to help you get past the hangover state. We agreed instantly that this will be the theme for our game. Now it was just left for us to figure out how will this translate into a game. Our initial idea was to make a 2.5d single room game in which the player awakens from his house and has to gather multiple ingredients to the blender to make the ultimate hangover cure and each time he hits something he shouldn't it would mess up with the controls of the game. However, we figured out that this might prove to be too difficult as we would need to draw too many assets and we weren't entirely prepared for that. Another idea was to simply make a game where the player has to travel to somewhere while talking to npc's and gathering drinks along the way to feel better and move faster. We also remembered one incident of similar kind from a past kyykkä tournament where the team captain was having a bad hangover and alledgedly had hard time walking to the game site from a nearby student housing, and after having a small laughter with the team we decided that this would be the story and gameplay of our game.

So, the game resolves around few factors:

1. There is a health bar, which will degrade while the player is moving.
2. The health bar can be renewed by talking to various npc's (technically seen as getting a sip of drink from whatever they're drinking)
3. Some of the npc's are traps and will decrease your health bar by offering bad drinks
4. The game ends when the player makes it to the actual kyykkä field.

We had previously decided that we'll use 2.5d graphics, and to do that we ended up in using the Phaser html5 framework: https://phaser.io/ In addition to the actual game engine, we would need some audio, which we would create using the FL Studio software. https://www.image-line.com/flstudio/ Lastly, we needed the graphics for the game and decided to create the sprites of the npc's and the player by using piskel https://www.piskelapp.com/ and lastly, as we had to recreate the university surroundings in the game, we ended up on using tiled https://www.mapeditor.org/ to create a level with some tileset art which we found from https://opengameart.org/

So, now that we had found the tools, it was time to do the initial setup. This took a lot more time than we had expected, since one of our developers used a Mac environment, and not all of the tools were compatible. We also had lots of trouble with our git repository (again), and struggled to get the phaser base file running on every machine. We hosted our project in GitLab https://about.gitlab.com/ and after the initial hassle with the setup, everything was ready to race and we started the development process.

We (of course) encountered some problems with the development process, and here are just some of them that we can remember:

• Lack of documentation and examples for the Phaser 3 game engine. This was extremely frustrating.
• Problems with the audio parsing, since the audio was in mp3 form and this would need to be rendered before launching the actual game in order to be played without a significant delay
• Problems with the tiled software, as it once wiped our whole map forcing us to start from scratch, and lastly importing the tiled map into the phaser was a pain as there once again was no sufficient level of documentation
• Finding a proper free and open source tileset for our tiled map. We tried a few, and lastly settled on https://opengameart.org/content/16xx16-tileset-pokemonzelda-styled and due to it being wrong color (summer instead of winter), we just decided that we'll use it as is and later on change the colors of the source image.

Unfortunately, in 2020 we only had 24 hours of time instead of 48 to actually make the game. As a result, the final result contains only the very core features, such as animated and controllable player sprite and the tiled map based on the university premesis which the player can explore. There are npc assets and audio assets in the source code, but they are not yet implemented. It was our initial idea to make the game as simple as possible in order to finish it in the 24 hours time period, but this proved to be near impossible due to all of the hassle with the initial setup.

Some things that we didn't have time to make:

• Layering to the map, so that the player would walk “behind” the houses instead “on top” of them and adding some borders
• Voices should be implemented. They're in the source code but we didn't have time to study the events on how to launch them correctly.
• Recolouring the map. Nice idea, totally easy and simple to do, just didn't have the time.
• More npc's

This year sadly we only had 24 hours of time to make the game. This is why we tried to make it as simple as possible, and still were quite surprised about how much time simple things can take (such as getting the initial phaser5 running on every machine and setting up the git for everyone). Even though this was a mini-edition of the jam for us, it was still a quite good learning experience as this forced us to go from where the fence was the lowest, and if we should have had time for another day, the game would surely have been finished as we had tackled all of the main obstacles by the end of saturday.

• Decide on your technology beforehand and get it running on everyone's computer. You can literally do anything with phaser for example, and having that installed on everyone's computer and with a functional git repository behind the source code, you could start the development right away instead of wasting ~2 hours in the installation process.
• It's not a crime to go from where the fence is the lowest. This, in fact, gives you more time in the second and third day (as by that time you've probably created the core features of your game) to polish the game and make it more fluid. Simple polished games are always better than complicated and unfinished games.
• Don't let anyone tell you that what you do is incorrect/lame/stupid. The best ideas are wacky, the best game I've ever seen made was a python text adventure with ascii graphics (very very very simple, but it was ultimately well done and wasn't “flashy” by any means), just do your best and even if you yourself think that the game sucks and it's terrible (which is what we did after this and the previous game jam), it doesn't mean that it's terrible. Well, it kinda does, but then again you'll have more motivation to make a better game next year.
• Have fun. Even though we only had 24 hours and didn't quite finish with the game, the main idea is to have fun. We had a blast creating the hangover audio lines for the players, creating sprites based on students in overalls and laughing maniacally while settling on our initial game idea.

Best regards, Munkkiliiga.