Disclaimer: This project is a non-commercial fan game, based on the game "Hades" by Supergiant Games 
https://www.supergiantgames.com/games/hades

Hades3310 is a small game that I've made for NOKIA 3310 JAM 2 in February 2020. The Nokia 3310 jam is a short game-jam dedicated to making games that could have been played on the original Nokia 3310 cell phone. The restrictions of the jam were only aesthetic: 

• 84 x 48 screen resolution (can be upscaled) 
• 2 colors 
• monophonic sound
• a limited number of controls

Theme

A theme of the jam was "Death is good". On the first day of the jam, I desperately tried to find a game idea that was not too grim. I said "Death is good" too many times in my head, which I, personally, found rather depressing. So, if you ever decide to organize a game jam, please, don't use a theme that would be disturbing to say a hundred times in a row. 

My first ideas were all about graveyards, ghosts, and grim reapers. But none of those ideas were interesting or worthwhile. 

At that time I was playing a game Hades by Supergiant Games (also known for the games, such as Bastion and Transistor). In this game, a son of Hades (the Greek god of the dead) tries to escape the Land of the Dead and reach Olympus. Each time he dies in this game, the game starts over again but the player becomes a little stronger. This game mechanics was a perfect fit for the theme of the jam. So, I asked myself: "What if Hades was created for Nokia3310?".

Technology 

I used Unity as a game engine because it is the only engine I'm familiar with. For making the visual assets I used Aseprite. 

The code of Hades3310 is open-sourced and licensed under MIT license. Please, feel free to take a look https://github.com/AndreyChernykh/Hades3310

What went right

I submitted a project on time. Well... barely missed the deadline, though =) 

Submitted by Mulberg (@AndreiMulberg) — 42 seconds before the deadline

But it the end, a submitted project is better than nothing. More about that in the "What went wrong" section below. 

For planning, I used a small text file with a todo-list. No fancy tools, no web-apps. That helped me to keep my scope small, and keep it simple.

Usually,-I tend to think about the project architecture, long-term support, and code extensibility and reusability. However, a game-jam requires a completely different mindset. Gladly, I managed not to overthink or over-engineer my game this time. Yes, some of the approaches that I used, such as hardcoded values or singleton services, are considered a code-smell. But these shortcuts allowed me to move fast and finish almost everything that I've planned for the jam. 

What went wrong

My biggest mistake was that I didn't test my project in the browser (I made a WebGL version) before the submission. First, 30 min before the deadline I discovered that I don't have a WebGL Unity plugin installed (facepalm). It took me about 10 min to download and install it, and then even more time to build the project the first time. I uploaded my game 42 seconds before the deadline! So, I barely made it. That didn't leave me any chance to test my game and upload any bugfixes, because after the deadline all uploads were blocked. 

Lesson learned: test your game on the target platform early and often.

The second issue I discovered after I run my game in the browser for the first time - the game was slow. It wasn't laggy, it was like on the 0.25x speed compared to my PC build. That was very disappointing. First, because now I had to spend extra time debugging my game, and second because I couldn't upload bugfixes until the end of the voting. That meant that all players would see only the buggy slow version of my game.

On the other hand, that was a valuable lesson and a perfect opportunity to dig into performance testing and profiling. I started analyzing the issue and try to guess what could cause it. 

I've noticed that my game seemed to be OK in menus, and slow only in the play mode. First, I looked into the Unity profiler for the first time in my life... aaand I understand nothing. Well, at least I didn't see any performance spikes during the gameplay. Absolute values didn't tell me much, though, - I didn't know how what are the resource limitations WebGL environment has. And, just a reminder, the game looked perfectly fine and smooth in the editor. So, I started optimizing my code in an attempt to find a root cause of the issue. 

First, I removed any unnecessary 3rd party libraries. That didn't help at all.

Second, I removed most of the `Debug.` calls from the code and commented the rest with #if UNITY_EDITOR. That didn't help either. 

(see https://docs.unity3d.com/Manual/PlatformDependentCompilation.html)  

My next guess was that maybe I have some operations in the Update methods, that might be, for some reason, slow in the WebGL. For instance, I had a player heath bar updated with TextMeshPro text.setText every frame. Replaced it with the event-based solution. Nope. Didn't help. 

After a while, I've figured out how to profile my dev build for a target platform without all the extra noise that is added by the editor. Turned out that my game consumes a ridiculously small amount of resources. "That can't be right..." - I thought. "WebGL can't be that slow! I probably dig in the wrong direction."

Finally, an idea came to my head: "What if it is not WebGL slow (in terms of bad performance), what if my game is SLOW? I mean, what if FPS is fine but the characters on the screen move slower than they should?" 

I looked at my code one more time and finally got it: I forgot to multiply my movement values to Time.deltaTime. I, probably, quickly prototyped my initial code without it, and later just forgot to add it. 

The game looked fine on my PC because of the very very high FPS, but in the browser, all the movement slowed down as the FPS was lower. 

Lesson learned: even when prototyping, don't forget to use the best practices that are easy to follow. 

TL;DR

1. Don't over-engineer you game jam project
2. Test your game on the target platform early and often
3. Learn how to use the Unity Profiler
4. Don't forget to use Time.deltaTime