What did we learn?

• I learned the fundamentals of programming in Godot 4, how to manage 2D sprite animation, sounds and building a simple player control + a recording/playback mechanic.
• I learned that ego is the killer of speed and flow, and that speed & flow give you the opportunity to test more ideas quickly and make constant progress. So, embracing any idea coming from anyone with an open mind, and being ready to drop any idea at the first sign of issue, allows the team to go fast and enjoy more what we actually control.
• Focus on what you don't control: What we control is what we know really well (our core skillset), everything else must be tested on the field with real players. Ex. Mauro knows how to draw and animate, there is no need to discuss how he will do that part of the job. I was fully in control of how to structure my code, there was no discussion about that. Anything else in the middle which is out of our experience zone (game design, vfx, sounds etc.) needed to be quickly tested and discussed together. Show, don't tell!
• I learned that any design idea must be validated to deserve a place in the game. These are the check that each idea has to pass:
  - Tech skill level check: Can I build what's needed to playtest this design idea?
  - Artistic scope check: Does Mauro have the time to draw all the images that are needed for this idea to fully work?
  - Player engagement check: Is it Fun for the player to play?
• We can't anticipate what will work. We have to be fast at de-risking a design idea, by first passing the Tech & Artistic check. We are not smart enough to validate the Player engagement check out of our thoughts, we need a player to actually play it to confirm or not.
• Lack of vision or designer confusion are another speed & time killer. When comparing 2 design ideas, go with the one that is clear over the one that feels "cooler" but it's unfinished. As a programmer, you need to know exactly what to code, so if the idea isn't clear, you gotta make it clear or you won't be able to start coding.
• A game jam is a microcosm of the real game development scene. With over 9K games being created at the same time, discoverability is a major issue that I don't know exactly how to solve yet.

What worked well?

a) Our development process

We had structured in advance how we would spend our time, so we had a general goal for the end of each day. No task was fixed, only the daily goal. We updated the task list at the beginning of each day, based on how the game development was taking shape, but we never changed the goals.

So this was our development process:

Ideation > Prototyping > Add Content > Polish > Build & Marketing

This was our tracking spreadsheet. Although the project was simple enough that we could keep pretty much all of this in our head, it helped to have a place to store ideas and it felt good when we checked off tasks.

So, we sliced our process in 5 steps, these are the details:

1) Ideation & high end design phase: evening after the theme announcement. We brainstormed for 2 hours and went to bed without any decision. The next morning we picked the idea the stuck with us the most and went with it. We chose this idea because of the simple scope in terms of coding and animations.

2) Prototype phase (day 1): we worked at implementing the most complex mechanic first, which was Player movement and Recording/Playback. I coded the basic based on improvised design that I had in my mind. Then I balanced the mechanic playtesting it and fixing it as I went. I wouldn't move on to the next mechanic/task until it felt good and bug free. If something wasn't achievable, I was ready to inform Mauro to change the high end design (it didn't happen). We tested externally the final build of the day with our family. My son's honest comment was striking "This is surprisingly fun, I thought this idea sucked, but it doesn't, I like it!". NOTE: you have to prove the fun of any idea, you can't discount it until you've played it, so you have to implement it into a prototype first.

3) Adding content (day 2): in this type of game this goal meant implementing the systems to bring in the 2D Animations, VFX and Sounds and importing them, then debugging them until they looked stable enough. At this stage we playtested externally with our family members again. I attempted a change into the visuals that actually changed dramatically the gameplay, because it make the recorded crabs look exactly the same as current crab used by player. My son again stepped in saying "It sucks!!! I hate it now!!!". Clear feedback, and I removed the "feature" which I thought would be good.

4) Polish (day 3): as you can see from our tracking spreadsheet, this way was about polishing the experience, tying a nice bow and preparing it for launch. No new mechanics, only the tutorial (simple prompt images) and fun effects to improve the look & feel. To decide what to polish I sent the previous day build to a friend developer that I respect a lot and asked him for feedback. What he gave me turned into a list of tasks that I implemented right away and those changes improved the overall game tremendously. The only parts that didn't make it into the build were judged by me and Mauro out of scope, with respect to the deadline.

5) Marketing (day 4): at this point we didn't touch the game anymore, we shifted into marketing mode and started to prepare all of the marketing materials needed for the final submission. I used the game engine to generate images for the screenshots and the mock-up of the key art, that Mauro would then improve upon.

b) Our collaboration process

I used the approach "Yes, and..." to let Mauro pitch any idea and I would try to bring it into the game.
It worked well because Mauro was very sensitive to the scope of the game and he wouldn't attempt to create anything too complex.

Personally, because my goal was only to learn how to code in Godot, I let any of his ideas come in and I did my best to implement them without questioning them. 

I tried a few times to push in certain directions, but Mauro's vision was strong and I liked I could trust it.

c) Having a playable build at end of each day.

The game was always playable externally, without major bugs. This allowed me to test it often with people, and getting feedback on what worked and what didn't. Plus I knew that even if things go bad, I could always wrap the latest working build with a nice bow and call it "a game".

What didn't work well / could be improved?

a) Well, our skills in game design are lacking, which is no surprise, since both me and Mauro are animators. Granted we have big passion for games, but being a foodie doesn't make you a great cook. You need to study how to cook.

b) We need to develop an eye to polish a game

c) We need to learn how to create a satisfying meta loop that ties up all the mechanics into a nice ending

d) We need to practice when and how to surprise the player

e) We need to do more game jams

f) Personally, I'd like to improve my shading / VFX skills to improve the visuals and have more visual feedback tools at my disposal to communicate to the player what's happening.

g) Our game wasn't rated often and we failed to create an itch.io page sooner than others, which might explain why we got fewer rates. We'll have to strive to create a nice temp key art for the game we're making already at the end of Day 1 (Proto), to sort of "announce" the game and start to gather followers.

h) Because of the size of the jam, and its culture, we only received sweet and positive feedback, absolutely no constructive negative feedback. On one hand, it was great to be welcomed in such a nice community, on the other hand, I would have appreciated to receive more actionable points that I could actually try to implement in a next jam. This issue is only partially mitigated by the scoring system, that gave us an idea of the real perception of the audience on these main dimensions: creativity, art, sound, narrative and engagement (fun).

The end. :)

Jacopo