Things learnt from a Reach the Finish Line Prototype: a postmortem

I learnt a lot making this prototype. So here we go with a postmortem style to say thanks for all the fish to Reach the Finish Line.

If you are into postmortem:

- Cool (classic) postmortems are here https://www.gamedeveloper.com/audio/10-seminal-game-postmortems-every-developer-...

- marketing related postmortem are here https://howtomarketagame.com/2021/12/27/what-worked-in-2021/

What Went Right

1. Can you make assets, sounds, etc while making your game? Well, I realized the answer is yes! Of course, the "yes" is relative to the size of the project. The prototype was super easy, and so was the concept. But I made my basic pixel art, learnt some Pixelorama tooling in the making and figured out it can be done. Now I have also pixel art, animation and Pixelorama (https://orama-interactive.itch.io/pixelorama) to learn! :) 

2. Can you expand on a basic concept and keep learning things in the making? Again, yes (same caveat as above).

The project started as "make a racing game in space with some obstacles". Or something like that. I want it to be easy to do at first, and then I wanted to expand on that. I made the game and a few levels. Then started making it "more real". So I added a menu, some options and start to manage with resources.  I made the blackhole and added animation and twines. I had to start thinking about bigger game architecture: you have a series of levels, some progression, etc. Each level has a timer (different timers if you have different difficulty levels), each level should have its soundtrack and, once you add a map, each visited level will unlock something clickable in the map. How do you keep this logic organized?

3. Level design on paper is great. I realized I like to build mazes on paper. They then start to breath on the editor as you realize them. They prompt new assets: like arrows to (mis)lead the player or even new mechanics. What about having the finish line of the level in 4 different positions and you pick up one randomly?

4. I have a nice bucket of ideas and leftovers. Scope creep was managed decently. I had problems and needs and start 

Getting a bit more technical, that's what I've learnt:

1. play audio

2. build collectibles that interacts with the HUD

3. twines and animation

4. having obstacles interact with the player or: the variety of what happens on collision

5. drawing tiles and build tilemaps (even thouch I realized there's a hell more to learn, like having the terrain interact with tilemap. See this)

6. RigidBody2d vs CharacterBody2d (see below)

7. animating stuff with Pixelorama

8. adding a game pad

9. add a map to resume levels you unlocked.

What Went Wrong

Ordered from less important to more important

1. Deploy on itch.io needs more study. I have used this guide from foosel that served me well https://foosel.net/til/how-to-export-a-godot-4-game-to-run-on-the-web-on-itchio/ . As the project grew I experienced issues,  map crushes and more. Open the console and have a look, lol. How can we do better? Have  a look at Adam C Younis pipeline for his "Though I walk" game (here: https://github.com/adamcyounis/LD54/blob/main/.github/workflows/deploy.yaml). Read better the butler stuff (here: https://itch.io/docs/butler/).

2.  There was no organization of the overall architecture. This is something I can say now. When I started it was enough to figure out the pieces and add them together. I am super thankful I discover that aspect here on a toy project. How can I do better next time? Plan a bit more. Read on the discord server of Godot more about game architecture. Do some further research.

3. The game is not fun. That's a big problem. I have a partial explanation for this that lies in the commands and control. Maybe that should have been a RigidBody2D and not a CharacaterBody2d.

4. Screen resizing. Ok, you may argue that a game that is not fun is the worst outcome. But I started the project to learn and start having some sort of components for a game I could reuse. One of the things on the list were options menu. This I did and was quite happy about it. But the failing issue is that if you open the game locally and start play around with the window size... that is not good. Period. (You can figure out how bad that is playing on mobile). So the main issue is that I have something on the list that I failed to achieve. I guess the best to figure this out will be to find a game that does the trick well and learn from that. (More technically: I guess I'll have way less absolute positioning and sizing. In the long run this will add even more game planning stages.)

What I am not sure about

1. Rebuild the game with a new character. 

2. Adding the items on the list. Like power ups and ship menu selection. I feel like there are already many things not working over there. It's better do something super small with a better architecture than building a spaghetti monster. The spaghettiness of this project is something I can deal with as it was a learning project. I don't want to end up with too much to maintain which grow out without any thinging.

3. Time spent creating a font I ended up not using. I learnt something but I am still not sure about whether it was good or not to obsessed on the this aspect.

4. Release the code. Will that be helpful in some way? No idea. Should I do that, I'll have to clean some of the code.
5. Marketing. I did none of that. Just randomly mentioned that. Maybe I should have done something.

6. Localization. I told relatives about the game. But the game was is English. That is definitely something to be considered to gain more support.