Wow. What a whirlwind of a gamejam. I made a post on the discord server with some  game design concept art I've made before and did the usual of DMing people asking if they wanted to team up. Originally the team consisted of 2 other programmers, me, and a music/sfx person. One of the programmers left after not feeling particularly into the game mechanics and two consecutive music people left probably because I didn't immediately directly activate/encourage their creative process and sometimes stuff just comes up. 

It was only towards the middle-end when we had the gameplay systems more fleshed out that more attention was given to sound design. 2 days before the deadline Banado recruited another sound person (mizuenalover) and we explained the theme/gameplay of the game. I suggested a specific genre: breakcore with whalesounds. I think it was mizuenalover's first time experimenting with breakcore and I think it turned out alright. The space theme was also great. They also made an unimplemented easter egg sound loop where I was planning to hide some of the game concept art.

Banado floated around the idea of a terminal command line type of game where you could program the machines. The next day (the 2nd day of the gamejam) the other programmer announced that they weren't really feeling it but didn't offer much in terms of specifics citing the direction of the game. I expressed curiosity and found out that it was because the terminal command line idea of gameplay just wasn't very appealing. I also held a similar sentiment and the design decision was made to switch to a drag and drop node (directional flow-network) connection system for programming. Still, the other programmer dropped out.

What we ended up with was a game where you move through the ocean and swallow creatures as you move through different zones like a whale would. You have programmable endosymbionts made of the same parts that are on your side. The objective is to program them to breakdown the microorganisms that you swallow. You could describe what me made as programmable cellular automata combat and reconstruction.

On a technical front we did succeed in implementing this--though not without significant bugs. 

One of the bugs encountered later on in development was a huge slowdown after a ship reached the edge of the gridmap and many bullets would be shot. This had to do with the bullets and ship movement being animated with a tween. If the movement was outside the defined border of the gridmap then there was no code to kill the tween and so those would overwhelm system resources. The game didn't upload correctly so we had to send in multiple support tickets to fix gamebreaking bugs.  One of which was loading/saving friendly ships in the encounter and the game crashing when switching to another scene (after winning/losing) as that technically called the ontreeexit function which would check a reward function that would reference a null list of ships engaged.

It was also an immense frustration to debug the saving and loading system which finally as of build9 has been fixed. You can now save and load ships and logic that you create. Some of it had to do with @export variables being set to something else in the editor. Some of it had to do with file pathing in different scripts being linked to the wrong variable that kept trying to save to the RES:// folder. Some of it had to do with bugged functions that would clear all displayed cards. Some of it was due to a button connected to the wrong signal. This was after duplicating the function that loaded from RES and rewriting it to load from the USER:// folder. We wanted to preserve the functionality of both so that players could tinker with the preset logic (some of which doesn't loop but that's because the nodes were connected well) and preset ships.  

Creating a web export also has some quirks, apparently there is a remapping  function that  adds .remap to .tres files when converting to web export. Though I think the pathing was the biggest issue +the other inspector and button signaling issues.   Banado might have more to add  on that. When you launch the game, you can right click and hit the inspect  option to open the inspector and switch to the console tab.

Through the course of this gamejam I drafted many concept art papers, created pixel art assets, and got more familiar with signals, control nodes, and godot engine in general. I started with the concept art and game design and then joined in with programming simple systems after the midpoint. 

I implemented:

• Animated on-theme start menu with buttons
• Animated settings menu (ran out of time to hookup to audiobus) 
• Music playback
• An email-like message system with tabs and buttons that open and close messages 
• Some achievements that could be placed onmap and triggered to display a sprite
• Distance tracking on the whaleship position which at one point was able to trigger the display of lore/quest related messages (sadly it broke)

Non-exhaustive list of things I learned about:

• Match statements
• Debugging with inspect element
• Signals
• Control nodes
• Progress bars
• Node searching in trees
• @onready drag and drop references
• Load/save file pathing

Our lead programmer banado was vital in bringing me up to speed on which nodes to look to create these systems. He also gave me a short template for how to setup control nodes and the achievement system.

Lessons learned:

• Get music/sound people involved in the creative process from the start 
• People will drop in and out of gamejam projects and that's okay
• It's okay if you overscope, by feeling out the experience you can get a better sense for what is feasible given a specific timeframe
• Talk about how you want to structure the codebase in the early stages of development
• Autoload nodes/scripts (globalvariables) prevent many headaches when changing between scenes 
• Drawing it out is helpful to organize and communicate your vision

Strange bugs:

• In the editor, there is a noticeable pixel offset (10-100pixels below) of where the cursor displays its position and where its position actually is when doing click detection. I think this probably has something to do with the scenes being contained inside viewports.

See the design process and concept art here:  https://banado.itch.io/refactor/devlog/1332715/designing-refactor-deep