Don't worry about walls of text, I always appreciate what you have to say. I appreciate the compliments on the pros, but the cons are where we can learn most from.
> I'm not exactly sure why it would happen, but there were moments where I would see the shards even if I wasn't camouflaged (the instance I specifically remember was in the room where we meet Alex), and even after toggling the camouflage it still wouldn't always register that I was standing on top of the shard spamming the interact button.
I believe this is a glitch that stems from attempting to camouflage or change party members while swimming. I watched the guy who drew our title art accidentally trigger than and he ended up having to reset the game. If I roll out a post-jam version I'll definitely try to fix this.
> Triggering the swim mechanic results in seeing an image of Alex standing on the floor and another of him swimming until the transition was complete - just a weird visual issue.
Unfortunate side effect of how I implemented it. Alex swimming is actually a boat which starts invisible and changes sprites when you access it. Unfortunately the boat sprite appears before you start to get in which is what causes the visual glitch. I did try to fix this but I literally had the guy who made Axial help me through it and even he had this same issue.
> I'm not sure how I feel about the team mechanics: having the characters switch positions automatically when you interact with their corresponding object is certainly preferable to having to dig into the menu and manually switch characters around to get the desired positioning, but then I have to question why the characters need to switch positions at all.
I originally had it so you had to manually switch party members to access different overworld abilities and then introduced automatic switching on the last day after enough complaints. The one party member on the field at a time thing was experimental, and I'm thinking I may just have every party member on the field in the game SITL is prototyping.
> I think it needs some tuning, and some issues may have been due to the compressed nature of the game and constraints of the jam version.
I agree. Less colors means more dramatic changes. In my original idea with six colors, buffing one stat and nerfing another would not be as big of a deal. Factoring in both elements and stat changes makes it a royal pain in the ass to balance, and I've been giving a lot of thought as to what to prioritize. Most players have been valuing elemental types over stat changes so I may try to emphasize that going forward.
> I think it would benefit to have some UI element similar to the one in RATD to help users remember the relationship between the elements. It could be something that can be toggled if not everyone likes it, but even with 3 elements I was having trouble remembering what the weakness/resistance relationships were.
I didn't realize I should've done this until watching Human play RATD. I even played RATD myself during jam time and didn't think to do something similar in SITL. Still kicking myself for that, but as I introduce more colors in the actual game (and even do a post-jam version of SITL) I'll be sure to implement some UI stuff to make the experience a bit easier.
> Another thing about the MC specifically: the only Blue skill available at the start is one that requires the enemy to attack the character - not great if the enemies fail to attack that particular character or don't use a damage-dealing skill.
I was such an idiot for not realizing this. Blue was based off some of my buddies' suggestions to have colors be hyper-specialized including having blue being unable to attack at all. Even then though, I really should've pulled a hail Mary and threw in a standard blue attack. Between Reid only having Counter as blue and Alex having very low attack, blue is kinda worthless in SITL.
> It also seemed like sometimes the weaknesses didn't work properly or didn't do as much damage as I would have expected. Maybe that was me failing to remember the relationships properly, but it could also be due to the skills not getting enough of a boost from the weaknesses.
This could have also been stat buffs and nerfs on top of everything you mentioned. Like I said, pain in the ass to balance.
> I found the combo enemies confusing too: they have an outer color, which I would think would be the part that would take priority since that's what the skill is hitting, but is it actually the inner part that determines the weakness/resistance? It wasn't clear when I was playing.
Each Guardian's weakness matches their current color. For instance, the Yellow Guardian starts blue making it weak to yellow attacks but then turns yellow making it weak to red. I can see why that could be confusing with the names not matching the initial color.
> While nobody seemed to be completely up a creek due to a poor match, it did concern me that I couldn't do anything to shield them from unfavorable matchups or use White damage-dealing skills to get around resistant enemies.
This was another thing I realized long after submitting that pissed me off. I've literally planned to have party members learn differently colored skills as they level up yet we forgot to do it here.
> I liked that there are bonuses for matching a color with the battle environment, but I didn't find it to be helpful, and if I had to switch away from the color due to type matching it made the bonus meaningless.
This I feel is going to be an extremely minor thing compared to the core battle system. I almost see it as a Pokemon ability; helpful in some cases but not paramount to combat.
Thanks again for the detailed feedback. As I've probably mentioned a thousand times, this game's purpose was to prototype all the features we devised and expose their strengths and weaknesses at the current moment. Between this wall of text and all the other feedback I've gotten so far, we could be on a really good track to start streamlining this battle system.