leafygreen

I added a script that would save all enemy positions and added interactable object support to my collider script (which was just looking for any object with Armature in the name and replacing it with the specific tscn file). I generalized how I was loading enemies as well. I took another dive into optimization and all I could find was it was almost all physics related. I'm already using Godot Jolt which gives a bit of improvement, and using spheres for enemy colliders. But the biggest factor was reducing the number physics steps per frame. I still have to test how this is going to affect the raycasts, but it was all move_and_slide's issue.  I also started modeling the gatherer. My thought processes on this one was it wouldn't make any noise, aside from dragging its sack since it has no mouth and it has copious numbers of eyestalks since its purpose is to find food but not for itself. in progress

 Was busy this week so not AS productive. But I managed to do some concept art of the gatherer, the first enemy in the game. I'll be working on that model next week. I fixed an issue with Lea's shooting attacks. Previously I was moving the projectile along a path but that was proving to be unreliable. I swapped to a raycast and moved my attack area to that point (which is honestly just a hacky reuse of the melee attackbox that Sera uses and is a relic of Practice Round. It's a lot more reliable now.  Also, multiple other bug fixes were done. I polished up Sera's interact animation, now she can lift the door midway without restarting the anim all over again using animations in the animation tree. There's a way to do so with just the animplayer but you lose a lot of nice functionality from the tree. I haven't figured out a way to get the entire root motion from the beginning of the animation, but just being able to start halfway into the anim makes things look rea...

 I've been importing the level design from blender using Godot's blender import (which is seriously convenient) and realized I had an issue when it came to making collisions. I'd be clicking and generating for all meshes, and on top of that they'd be the less efficient, over detailed collision meshes. On top of that if I made even a single change to the level...it'd be a huge pain. This week aside from finishing up much of the laboratory assets, I made some tool scripts. One in blender to create a collision mesh from a custom mesh and auto rotate/scale/translate to each prop. Another as a godot editor plugin to auto create all the static objects from those collision objects from blender and assign them proper collision layers. I still need to do some more, as the current plugin doesn't handle interactable objects, just static props, but it gets rid of a lot of tedious work. With that and the combat system almost done, I think I'm ready to start work on actua...

 Added more functionality for puzzles. Also, a ton of bug fixes. Threw in a test level just to see the game feels with an actual environment instead of a block of gray. The camera is still rotatable, I'm planning to allow limited rotation and zoom. 

 I haven't been updating frequently but I have been making a lot of progress. Sera has a new set of animations that is easier for the player to track and time because they're much slower. Some more additions (and countless bug fixes) have been made to the ally system and I think it's almost done. Sera can now interact with objects if they're selected and can open doors - but not close them (this may change later). Since Sera moves much faster than Lea this can be used to the player's advantage. If either character dies it's a game over. Once again, one button for all Sera interactions. I hope that this'll make things easy to control. Its easier to aim with Lea now with accurate visual indicators of whether you've correctly aimed at an enemy or not. I'm still debating if an aim state is even necessary. In general, Lea's going to be slower and have much less health while Sera will be tanky and fast. But Lea will be the only one to have ranged and e...