https://ldjam.com/events/ludum-dare/41/seaman-sleuth
Combining the detective game genre with the Metroidvania genre proved to be an extremely difficult task, which most certainly wasn't helped by our lack of experience with either. Through some miracle, however, an actual, playable build of the game was submitted before the deadline. Here are some insights into our development process:
Dialogue
Dialogue was written in a Google Sheets document, alongside notes from the writer to the programmer. The document was then exported to a TSV file, which would be read into a string array once the game was loaded. This made both writing and programming dialogue events a ton easier than the method we used for Ludum Dare 40, which was just copying and pasting paragraphs from a script into string literals in the game's code.
Code
In total, around 1462 lines of code were written for Seaman Sleuth, with over 500 lines dedicated to player movement alone. In the spirit of 72 hour game jams, code quality varied from readable to catastrophic. 26 global variables ended up being used to "save time", which made debugging a nightmare. Additionally, due to some sort of weird stuttering bug with Godot 3.0's physics timestep, most player movement code was written in the render loop instead of the physics loop; this caused a whole bunch of problems with collision checking on the first day that took well over six hours to fix.

Programming the detective parts of the game was stupidly easy in comparison; cursor position was checked against collision shapes drawn over points of interest in an image. When an area was selected, it would just skip to a certain point in dialogue. The same system was also applied to the "interrogation" segment, because it was 5am and creating a normal three option menu was apparently too much effort.
Levels

Levels were designed in Godot's lovely tile editor, which made it easy for non-programmers to design levels; despite this, only two levels were made for the Metroidvania segments. Initially, the game was going to consist of one giant level on a single tilemap, but this resulted in the game running at an unplayable framerate on the HTML5 build. Due to my inexperience with programming, tilemap data ended up just being "swapped out" when loading new areas, without making any changes to the player instance - this is why the player is falling when changing to some scenes.
Time and project management

There were very few breaks whilst programming for some reason, which culminated in horrible burnout for the first two days of the jam. The few breaks that I did take had tremendous impacts on productivity, with a particular six hour bug only being fixed after 15 minutes of doing literally anything that wasn't programming. Looking back at things now, not taking regular breaks probably had the single most negative effect on the game's quality, as many hours that could have been spent on levels, enemies, and polishing were lost to bugs and other inefficiencies from just being tired.
Tasks were also not evenly allocated amongst team members, with the level editor only being introduced to non-programmers around twelve hours before submission. Some features worked on were also cut due to the bottleneck of having only one programmer (and a very inexperienced one at that). An example of this is puzzles - a team member spent an entire day on puzzle designs, only to have them not implemented due to the code for actually running the puzzles in the game being considered low priority and never actually written.
Git was used for version control but non-programmers were not shown how to push their own commits to the repository. This meant that art assets had to be sent over Discord, which didn't impact productivity too much but could have been excruciating for something of a larger scale.
Conclusion
Overall, it is a miracle that this game got anywhere close to being playable before the deadline, considering everything in its way. A lot was learnt about tilemaps, player movement, and other stuff, and a lot was applied from what we learnt from our previous Ludum Dare game, "Smash! Smash! Destroy the West! Jangnanmon!" ( https://ldjam.com/events/ludum-dare/40/smash-smash-destroy-the-west-jangnanmon ), such as making use of the twenty seconds of precious programming time that it takes to add a god damn skip button to the intro dialogue.
Here our our key takeaways from this Ludum Dare:
* Make sure the programmer actually takes breaks
* Don't abuse global variables
* Figure out ways to make level switching more seamless
* Allocate tasks more efficiently to different team members
* Allow for time to polish
* Watch out for scope creep
If you like pain, you can play and vote on our game here:
https://ldjam.com/events/ludum-dare/41/seaman-sleuth